The Auto Cybersecurity Mandates Are Here: We Must Work Together

In my previous blog about UN R155 and ISO/SAE 21434, I explained how the auto industry and its suppliers have been charged with making cybersecurity mandatory in every vehicle. This is a significant challenge as UN R155 and ISO/SAE 21434 are already in effect and will be mandatory for all vehicles from model year 2024 forward. So, let’s delve into some of the issues that automakers and their suppliers face today and will face in the future.

The Sheer Scale Is Staggering

ISO/SAE 21434 mandates that automakers provide a clear, comprehensible and defensible rationale, supported by evidence and documentation, that an item or component achieves a sufficient degree of cybersecurity for the application it is used in. To achieve this, automakers must determine the relevance of cybersecurity to each of these items and components; for the relevant ones, automakers can perform analysis and risk assessment (TARA). From this assessment, they can derive a set of cybersecurity goals and requirements for achieving a verifiable level of security.

Since there are hundreds of components in every vehicle that could potentially present a cybersecurity problem—and given the tight deadlines—this process imposes a formidable challenge, not just for automakers but for their suppliers as well. Modern vehicles increasingly rely on wireless communication to interact with their direct environment and to leverage cloud-based services. This connectivity continues within the vehicle itself, so almost every electronic component inside it should be presumed to be a potential target for hackers.

Security-By-Design and Legacy Components

Ideally, the challenge should be addressed at the first stages of design. “Security-by-design” is also gradually becoming standard practice by many automotive suppliers. However, many of today’s vehicle systems (ECUs) are built using semiconductor and software components that were designed well before the standard was ratified or was even in development. This does not mean they are insecure, but requires that a threat analysis and risk assessment (TARA) is performed for those systems; that state-of-the-art security requirements are derived from that assessment; and that existing documentation is gathered and analyzed to determine if those security requirements can be fulfilled. If existing documentation is sufficient, then additional security activities such as retrospective design reviews or penetration tests must be performed to address the gaps. This can be a costly endeavor, so it must be carefully determined if the evaluation should be carried out, especially for “legacy” components which may be nearing end-of-life. In some cases, a migration to newer components may be a more cost-effective approach.

Ambiguity

Close collaboration and a common understanding between automakers and suppliers is critical. Fortunately, ISO/SAE 21434 provides a basis for this through the vocabulary and the security engineering framework that it defines. Still, it is difficult to answer the simple question “is this product compliant?”. It is difficult to answer because the standard leaves ample room for interpretation. For example, process steps are only broadly defined and requirements are rather generic. Hence, the “compliance question” is judged by customers (automakers and Tier-1 suppliers), based on their interpretation of the standard. Therefore, the question is if a product—and the processes applied during the development and further lifecycle stages—matches that interpretation. It would be beneficial if a second edition of the standard aims at reducing ambiguity.

Components “Out-of-Context”

We have also observed that sourcing procedures of automakers and Tier-1 suppliers typically assume “in-context” components, which are developed to meet a specific set of requirements for a specific use case (i.e., the context). However, most semiconductors are designed as generic, “out-of-context” components, in the sense that they are designed to serve a wide variety of use cases. The variety of use cases in which the components are assumed to be used is based on assumptions of their intended use and prior engagement or commercial agreement with a customer. This mismatch leads to some inefficiencies and challenges.

Inefficiencies may arise if customers insist on the creation of a Cybersecurity/Development Interface Agreement (CIA/DIA), which fits with in-context developments where the supplier and customer work together during development. However, such documents do not add much value for out-of-context developments. Additionally, customers typically have their own templates for the CIA/DIA, which leads to a further increase in effort as multiple documents capturing the same content need to be created for each component, one for each customer. A streamlined process for addressing this redundancy would increase the efficiency of the approach.

Requirements for Semiconductors and Software

Challenges may arise when customers add new and rather specific requirements to their sourcing process when it is based on their interpretation of the standard. Secure coding rules are a good example. The standard contains a generic requirement that cybersecurity criteria not addressed by a programming language should be covered by coding guidelines or by the development environment. The standard provides some hints, but does not provide coding guidelines. Consequently, customers define their own coding rules and often require strict compliance. Some even specify specific tool versions that must be used to check compliance.

This imposes a few challenges, especially for semiconductors and general-purpose software. First, different customers may have different requirements, which conflicts with the objective to develop generic components that can serve multiple customers and use cases (to achieve economies of scale). Second, the sourcing process for out-of-context components typically happens after their development project has ended and taking custom requirements into account that late in the process may not be feasible, or be cost prohibitive.

Hence, a defined set of coding guidelines and other generic requirements for semiconductors and software will be highly desirable; ideally, available guidelines shall be reused wherever possible. A good starting point is MISRA C, which has been in use for many years and is the de facto standard for developing automotive software in C where safety and security are essential.

Common Threat Scenarios, Attack Feasibility Rating and Assurance Levels

Another challenge is the lack of a common baseline for threat scenarios and attack feasibility rating. While R155 provides a list of generic threats at the vehicle level, nothing is specified for semiconductors. This makes it difficult to reach an agreement with customers on what attack types should be considered in scope for a certain product.

It’s also challenging to agree on risk ratings and, more specifically, on the feasibility of attacks. Annex G of ISO/SAE 21434 provides guidelines for three different rating approaches: attack potential-based, CVSS-based and attack vector-based. Although useful, these guidelines aren’t very consistent - different approaches may result in entirely different ratings for the same attack. Consensus in the industry on which approach to choose for semiconductors and software would help. Perhaps even more important is that stakeholders understand that such ratings—although they can help to prioritize issues—are certainly not perfect, as there is always a “margin of error”. Therefore, such ratings should not be used as a hard metric in business processes or legal agreements, ignoring the need for expert judgment.

Similarly, there is no consensus yet on assurance levels. Annex E of the standard describes Cybersecurity Assurance Levels (CALs) that can be used to specify and communicate a set of assurance requirements in terms of levels of rigor needed to provide confidence that the protection of a component is adequately developed and verified. These guidelines are also not very specific, so it is not surprising that few organizations refer to them today. However, having a well-defined assurance level would provide a useful metric for gaining confidence that products meet their security requirements and can be trusted for their security capabilities.

There are initiatives to address these gaps. For example, Target Attack Feasibility (TAF) and Cybersecurity Assurance Levels (CAL) are topics being addressed by ISO/SAE PWI 8475. Furthermore, Auto-ISAC is working on an Auto Threat Matrix inspired by MITRE ATT&CK that can possibly be used as the foundation for common automotive threat models for vehicles and their components. Lastly, there are several initiatives when it comes to cost-effective approaches providing assurance that products meet their security objectives. One of these is SESIP, a new certification scheme that was created to address the need for a common, optimized approach for evaluating the security of connected devices within the evolving IoT ecosystem.

Knowledge Shared Is Knowledge Squared

It’s not only about requirements and metrics. Today, many companies have central competence teams with extensive knowledge about UN R155 and ISO/SAE 21434. However, this expertise must be transferred to other teams as well, from design and development through product management, account managers, field support engineers, quality assurance, purchasing and others. Security is a team sport, and everyone involved must have at least a basic level of security knowledge to be able to do the right thing within their area of responsibilities. Without that, there is a clear and present danger of ending up with a “check box” approach to compliance. And it’s well known that this approach does not lead to effective security and resiliency.

Long-Term Security Support

UN R155 requires that security is managed throughout the entire product lifecycle. Generally speaking, this means that the threat landscape must be monitored for new threats and that vulnerabilities and incidents are managed when they occur. The big challenge here is that the lifetime of vehicles and their components can easily be 20+ years. ISO/SAE 21434 is a little more forgiving and allows ending cybersecurity support before the end-of-life of a product. This push for long-term cybersecurity support is a necessary step. However, such support does not come for free; and paid service models may be unavoidable as recurring investments will be needed. For example, the recurring investment needed for retaining knowledge, tools, IT equipment and lab environments.

Collaboration Is Key

By this point, I hope it has become apparent that collaboration is the only way the auto industry and its suppliers can meet the broad mandates of UN R155 and ISO/SAE 21434 within the narrow timeframe in which they must accomplish it. This means that, in practice, direct engagement between customers and suppliers is essential. As described in my previous blog, Auto-ISAC (Automotive Information Sharing and Analysis Center) is the key platform for connecting cybersecurity experts in the automotive industry. This provides an excellent opportunity to align on some of the common challenges, through exchanging experience and best practices. An open dialog throughout the industry can dramatically reduce the time required to provide secure solutions. And time is not on our side.