As new security vulnerabilities are discovered in automotive electronics, who is responsible for protecting my car? ISO/SAE 21434 may have an answer.
In COVID-19 times, gathering a few friends in a circle and playing “hot potato” may sound like a dream. For car manufacturers and the automotive electronics supply chain, handling the cybersecurity hot potato is not quite a nightmare but certainly not a fun game. Companies like Volkswagen, Fiat, and Ford have much expertise in managing a complex supply chain and post-sale support. Most car owners have gone through the experience of being informed that their car required a special maintenance session. In most cases, the culprit is safety. Not long ago, I had to update (free of charge) the roof lighting in my one-year-old car because a fire hazard in certain humidity conditions had been identified. While at the garage, some software also got updated to provide new features, I was told. Nobody mentioned anything about bug fixes, of course. Fully-fledged recalls are rare but still more frequent than the industry would wish for.
With the proliferation of advanced driver-assistance systems (ADAS) and connected autonomous vehicles (CAVs), complex electronics are involved in – and increasingly in charge of – ever more critical driving functions and private information management. You might have heard this from me already: there is no safety without security. Neither there is privacy. Unlike safety issues, mostly due to human errors, security issues often originate from abuse and misuse of hardware and software components. Security researchers and hackers are some of the most creative people. One of the consequences is that new vulnerabilities are discovered frequently, raising the challenges of supply chain management and post-sales support to a whole new level. Who in the supply chain is responsible for keeping cars protected?
Original equipment manufacturers (OEMs) have two main directions to address the cybersecurity hot potato challenge. The first is to move hardware and software development as much as possible in house. The second is to distribute cybersecurity activities across the supply chain using a strict and standard approach. The ISO/SAE 21434 “Road vehicles – Cybersecurity engineering” standard can come in handy.
Cybersecurity lifecycle. Source: Hyundai Motor Group
As electronics become key to differentiation and semiconductors reportedly enable 80% of vehicle innovation, OEMs have plenty of reasons, beyond cybersecurity, to take the in-house path. Tesla has invested significantly in software development for a while. True to the statement that “people who are really serious about software should make their own hardware,” in 2019, Elon Musk himself presented Tesla’s first full-self driving chip developed in house.
At DVCon Europe 2020, Matthias Traub, head of E/E-Architecture and Platforms at the Volkswagen Group, which includes Audi, Seat, Skoda, and numerous other brands, delivered a very interesting keynote. Automotive architectures are not flexible. Tens of electronic control units (ECUs) function mostly independently. Each ECU has its own software stack, making suppliers running in the hundreds. In January 2020, the Volkswagen Group established an independent organization expected to employ 5000 software engineers by the end of the year. Taking the in-house path simplifies the supply chain, but no organization can do everything on its own.
ISO/SAE 21434 allows sharing the pain of newly discovered vulnerabilities across the supply chain. The standard covers the entire life cycle of automotive electronics, including the operation and maintenance phase, and identifies continuous cybersecurity activities. Monitoring of newly discovered vulnerabilities, threats, and proposed mitigation is the first step. When the information collected is relevant to an item or component (under development or already on the road), this is considered a cybersecurity event. An assessment process is required to determine the event’s criticality. The vulnerability may have to be analyzed, to identify its root cause, and properly managed. For example, in some cases, the additional risk could be deemed acceptable, while a remedial action might have to be implemented in others. Any update or change in hardware or software has to be managed according to the standard’s requirement. When in the operation and maintenance phase, a cybersecurity event can rise to the level of incident. The draft standard includes a note stating that “the organization can define the criteria for invoking incident response.” There are requirements dedicated to this special scenario.
The OEM will not have all the expertise, tools, and platforms to implement these requirements. Luckily, ISO/SAE 21434 considers that cybersecurity activities may have to be distributed across the supply chain. Customers and suppliers must have formalized agreements that clarify how responsibilities, decisions, and information are shared. Customers must also evaluate the supplier’s capabilities to implement a standard-compliant process during development and, crucially, to support post-development activities, such as assessing a newly discovered vulnerability’s criticality. It is worth noting that a Tier1 can be a supplier for an OEM and a customer for a Tier2 supplier.
Avoiding incidents is always preferable (and much cheaper). ISO/SAE 21434 has plenty of requirements and recommendations to shape processes and foster an organizational culture that integrate cybersecurity from the concept phase. While hardware security is still in its infancy, the electronic design automation (EDA) industry already offers numerous relevant solutions. Formal methods and hardware model checking support the detection of weaknesses and vulnerabilities during the pre-silicon development phase of semiconductor IPs and system-on-chip (SoC) devices.
However, security is an arms race. It is impossible to reduce the risk to zero. Suppliers of integrated circuits (ICs) and semiconductor IPs must analyze newly discovered vulnerabilities efficiently. They need to maintain and enhance the hardware development environment for post-silicon analysis. This is crucial to determine the root cause of a security issue and identify remedial actions. OneSpin has unique design analysis technology that can be targeted at specific design functions. It can also be used to carry out a rigorous, exhaustive “what-if” analysis to develop – and fully validate – hardware and software remediations.
I invite you to take a look at the trust and security glossary, download the white paper Trust Assurance and Security Verification of Semiconductor IPs and ICs, and join the LinkedIn group ISO/SAE 21434 Automotive Cybersecurity. And of course, don’t miss the next 6 Minutes of Security blog post!
 |
 |
 |
 |
 |
 |
Leave a Reply