What makes cybersecurity so challenging in the autonomous and highly connected environment?

Today, vehicle development can already rely on established standards, regulations and experience – including, for example, UNECE R155/156, ISO21434 and a relatively homogeneous pool of typical cybersecurity controls, i.e. high-level requirements. In short, a kind of basic security is already in place and the standardization of processes is largely sufficient. What makes autonomous vehicles and people movers so special in terms of cybersecurity requirements, is their new use cases and area of operation:

• Monitoring the entire system is significantly more critical than with non-autonomous systems. The driver, who might notice unusual behavior in the vehicle, is no longer part of the system.
• People movers face additional challenges due to their need to integrate into multiple ecosystems. Redundancy becomes the enemy of the core cybersecurity principle of “keep it small and simple”. Examples of such ecosystems include: a backend system operated by the mobility provider for booking management, cloud-based integration with the autonomous driving system of a third-party provider, a connectivity platform for the entertainment system that enables in-vehicle-advertisement and connects with advertising companies, as well as various solutions for maintenance, update management and charging. Each interface brings in third-party providers with increasing demands for data and becomes a potential weak point.
• Compared to autonomous passenger cars, people movers offer one key advantage: They regularly return to its home base at short intervals, where they can not only be recharged, but also maintained or software updates can be carried out. Manual cybersecurity testing could also be performed out here.

On the way to the ideal cybersecurity project setup for autonomous vehicles and people movers

From our experience in cybersecurity projects for autonomous vehicles, such as the HOLON people mover project, we have identified several key factors for effective team composition, the right project architecture and supplier collaboration.

The optimal team composition

The team setup should be a top priority right from the start. Because of the complexitiy of autonomous vehicles and people movers, it’s not enough to have only general cybersecurity experts. It ist crucial to include experts with in-depth vehicle knowledge. Many security measures need to be deeply integrated into the stack of the software-defined vehicle, where core functions are increasingly mapped in software and distributed across multiple electronic control units (ECUs). A solid understanding of systems engineering, including vehicle IT and E/E architecture, is essential to differentiate, for example, between mandatory and non-essential data flows and interfaces. Every access that can be eliminated through holistic system design is one less access point that needs to be secured and monitored. In other words, many cybersecurity systems engineering challenges can be solved in the software architecture – but doing so requires specific know-how.

Security standards and suppliers

The R155 is the primary standard for type approval regarding cybersecurity requirements. The so-called “Vehicle TARA” is a proven method to fullfill R155 and other related standards while also establishing a shared understanding across the entire project team. In typical vehicle projects, suppliers receive security concept specifications from the OEM. However, another approach is to define security responsibilities at the component level and to delegate those directly to the suppliers. This strategy was applied in the HOLON people mover project. By following a “components-off-the-shelf” approach, the project not only ensured cost optimization, but also involved the suppliers more deeply in the security process than usual.

The right architecture for the right level of abstraction

What is the right starting point for integrating security measures into the vehicle without overlooking vulnerabilities or potential attack vectors? In practice, a top-down approach from vehicle level to the function level and then to component level, has proven successful here:

1. In the first step, the existing features and functions – with both functional and non-functional requirements – are identified, along with the function-oriented development paradigm.
2. Functions are broken down step by step to the component level.
3. The necessary cybersecurity “work products” are derived from R155 and ISO21434.
4. These work packages, including their objectives, requirements and control mechanisms, are applied to all functions and components. A structured approach can be used here in accordance with TARA.

Project coordination in practice: How do you align OEMs and suppliers when it comes to cybersecurity?

To bring all relevant stakeholders together and work jointly on a solution, a phase-based model has proven highly effective in practice.

1. During the first request-phase: Components are classified into categories. Basic security requirements are defined for each class (e.g. secure boot, secure update, message authentication, hardware security modules). These basic requirements form the foundation for component design, planning, and quotations.
   
2. At the same time: Detailed protection goals are systematically broken down from the overall connected vehicle down to individual components. These protection goals are the starting point for in-depth cybersecurity alignment with suppliers and help harmonize differing assumptions and risk assessments. At this stage, while the goals are clearly defined, there is still flexibility for suppliers in how they implement them.
   
   What sounds supplier-friendly at first can prove to be a significant challenge, depending on the supplier’s cybersecurity maturity. The traditional approach of strictly implementing detailed OEM requirements is partly replaced. Instead, suppliers are expected to take ownership and show cybersecurity awareness for their own product-responsibilities that were previously handled by OEMs. Cybersecurity competence on the supplier side is now a prerequisite.
   
3. Once a joint implementation strategy has finally been agreed, the residual risks are reassessed across all levels – from component level to the entire connected vehicle. If necessary, additional measures are taken. These may include accepting a higher level of risk, transferring a security measure to another component, or adapting the functionality itself. Depending on the results of this evaluation, several iterations of alignment may be required.
   
4. The agreed-upon status is then subsequently documented as cybersecurity requirements in the component specification, and the implementation is planned incrementally in the implementation roadmap. Whenever dependencies between the control units (ECUs) must be taken into account, strict coordination between the components is essential.
   Many cybersecurity controls are based on cryptographic mechanisms that prevent unauthorized access to protected functions. For authentication and authorization, the appropriate cryptographic key material is required in various forms. Regardless of whether symmetric or asymmetric encryption methods are used, a effective coordination of key material across ECUs, development tools, and IT systems is always necessary.
   
5. Once the appropriate identity, access, and key management processes have been implemented across all involved parties can these functions be reliably used as originally intended. Therefore, the definition and implementation of the corresponding processes and tools across all involved parties is a prerequisite for the successful integration of components with active security functions.
   
6. As soon as the first ECUs with implemented security functions are available, the functional testing of these mechanisms can be carried out in the same way as other functional tests. This means testing whether the implementation of the security functions complies to the specification. A typical security test strategy includes a division of different test steps between suppliers, component and integration test levels, as well as tests with the necessary tools and IT systems.
   
7. These functional tests are complemented by so-called security test, which are designed to determine whether the implemented measures meet the intended protection goals. Potential vulnerabilities can be identified, for example, through penetration testing. These tests require creative thinking, as weaknesses are often uncovered only through unconventional approaches. A well-known example is the early keyless entry systems, which, despite cryptographic protection, could be tricked using a simple signal repeater.
   
8. The final phase focuses on continuous monitoring and what is known as vulnerability management. The main challenge in this phase of collaboration between OEMs and suppliers lies in the relatively long service life (vehicle lifetime) of the vehicles. It is advisable to define a contractually agreed lifetime period for which a security guarantee can be provided.

The team at Cognizant Mobility has been addressing the cybersecurity challenges of complex, connected, and autonomous vehicles for years, combining deep cybersecurity expertise with in-depth vehicle knowledge, from embedded software to cloud IT.