Automotive cybersecurity

Introduction

The amount and complexity of components and software that make up E/E (Electrical/Electronic) architectures in vehicles will continue to increase. The automotive industry is constantly changing to adapt to new market requirements, and the security of these environments has become a huge challenge, with the ever-increasing connectivity of vehicles, as well as more powerful and multipurpose ECUs (Electronic Control Units), combined with more mainstream technologies.

Efforts in advancing cybersecurity in the automotive industry have resulted in a number of regulations, standards, and partnerships such as the AUTOSAR consortium^[1]. These efforts have provided common frameworks and security requirements and even aim at establishing an open industry standard for automotive E/E architectures. As a result, they provide valuable content to shift the security left and apply the "security by design" concept to harden these environments from the get-go.

IriusRisk provides the content, support, and flexibility necessary to automate and guide the process of building secure automotive components and software.

The UNECE WP.29 regulation and ISO 21434 standard

IriusRisk provides the UNECE WP.29 library listing risks and mitigations enumerated in Annex 5 of the WP.29 regulation^[2].

This list is one of the main differences between the WP.29 regulation and the ISO 21434 standard^[3]. WP.29 is quite specific in this area providing this list as a baseline in order to assess if a vehicle and its connected services are secure. The standard, on the other hand, goes deep into describing how to do certain cybersecurity activities; including threat and risk assessment and cybersecurity management, whether organizational or at the project level.

The commonality between them, however, is that manufacturers have to demonstrate that they use processes, within an effective CSMS (Cyber Security Management System), that perform threat and risk assessment throughout the vehicle lifecycle.

The relationship between WP.29 specifications and ISO 21434 requirements, and how IriusRisk would help, are reported in the table below. This is based on the mapping provided by the GRVA; the Working Party on Automated/Autonomous and Connected Vehicles of the WP.29^[4]. It shows how the regulation and the standard are overlapping, and adhering to the WP.29 regulation will put your organization in a good place with regard to ISO 21434 compliance.

WP.29 CSMS Specifications	ISO 21434 Requirements	How does IriusRisk help?
(a) The processes used within the manufacturer’s organization to manage cybersecurity.	Clauses 5 and 6: Organizational and project-dependent cybersecurity management.	Good governance and strong cybersecurity culture are required to set up a mature cybersecurity management model. While this is essentially a leadership commitment issue, IriusRisk supports this effort by automating and guiding your security-led approach to compliance and the prioritization of risks that are relevant to your organization. It will ensure effective overall risk management in your cybersecurity program, and continuous development and implementation of best practices and industry standards and policies.
(b) The processes used for the identification of risks to vehicle types. Within these processes, the threats in Annex 5, Part A, and other relevant threats shall be considered.	Clause 15 covers threat analysis and risk assessment.	The full list of threats in Annex 5 of the WP.29 regulation is provided in IriusRisk.
(c) The processes used for the assessment, categorization, and treatment of the risks identified.	Clauses 9 and 15 cover risk assessment activities from defining cybersecurity goals to threat analysis and selection of treatment/mitigation options.	The IriusRisk WP.29 library also provides mitigations. In addition, the IriusRisk platform provides traceability throughout the process and the entire life cycle, as well as the flexibility to set up your own content and goals, e.g., custom ratings or risk acceptance.
(d) The processes in place to verify that the risks identified are appropriately managed.	Clauses 9 and 11 cover the cybersecurity goals, requirements, and validation for items at the vehicle level.	IriusRisk automates the security requirements’ tracking and their validation and resolution.
(e) The processes used for testing the cyber security of a vehicle type.	Clauses 9, 10, 11, and 12, cover the entire life cycle of cybersecurity requirements up to testing and validation during the production phase.	The IriusRisk platform provides the capability to define tests and track progress throughout the requirements life cycle, including via a range of integrations with CI/CD tools, testing frameworks, and ALM (Application Lifecycle Management) tools.
(f) The processes used for ensuring that the risk assessment is kept current.	Clauses 6, 7, and 8 cover the setup and responsibilities for an up-to-date and continuous risk assessment.	IriusRisk provides up-to-date content via a range of libraries that are applicable across a wide range of industries. Its flexible platform and rules engine, as well as the integration with a wide range of tools, will help all stakeholders ensure a continuous and current threat and risk assessment process.
(g) The processes used to monitor for, detect and respond to cyber-attacks, cyber threats, and vulnerabilities on vehicle types and the processes used to assess whether the cyber security measures implemented are still effective in the light of new cyber threats and vulnerabilities that have been identified.	Clauses 7, 8, 11, and 13 cover aspects related to the monitoring, detection, assessment of events, and validation and effectiveness of mitigations and incident response.	IriusRisk does not provide itself the capability to automatically track new vulnerabilities or threats in the wild, or monitor/scan assets, but it does provide the necessary recommendations and relevant mitigations for all known attack patterns. Additionally, its flexibility and multiple external integrations allow it to easily add content and leverage features from 3rd party tools, such as ServiceNow, to achieve this.
(h) The processes used to provide relevant data to support analysis of attempted or successful cyber-attacks.	Clause 8 covers the monitoring and provisioning of data to support analysis.

A reference E/E architecture example in IriusRisk

IriusRisk also provides the IEC 62443 library for the cybersecurity of Industrial Control Systems (ICS). E/E architectures can be considered as a single and centralized Industrial Automation and Control System (IACS), where the IEC 62443 can provide a framework and guiding principles on how to incorporate security into vehicle systems. The IEC 62443 library also provides basic components, such as controllers/ECUs, sensors, actuators, gateways, and a number of dedicated protocols, e.g., communication protocols. Figure 1. presents a reference E/E architecture built in IriusRisk.

The platform will automatically generate the threats and countermeasures associated with the base components and protocols used in the threat model above. Figure 2. shows the threats’ view. The flexibility of IriusRisk also allows the user to add custom threats and controls specific to a given setup or other dedicated modules or technologies, in support of in-vehicle communications, diagnostics, telematics options, etc. The ‘Front-door access’ use case shown in Figure 2., for instance, is a collection of threats that describe potential attacks via allowed wired or wireless interfaces designed to reprogram or service the vehicle ECUs, which is part of a custom library in this case.

Conclusion

In the era of emerging next-generation E/E architectures in vehicles, as well as increasing attack and cyber-threat landscapes in automotive^[5], providing support to the automotive industry, in implementing standards and best practices for secure components and development lifecycle, has become a necessity. Attacks on vehicles can be of great danger to users and is a huge challenge for manufacturers, suppliers, as well as dealers. Threat modeling is a key aspect to ensure new vehicles and external connectivity are properly designed, and protected, i.e., countermeasures are implemented and the vehicle will continue to reliably operate, even when under attack. The IriusRisk platform offers the necessary help, technology, and content for automating the implementation of standards, best practices, and secure design processes.

References

[1] https://www.autosar.org/

[2] https://unece.org/sites/default/files/2021-03/R155e.pdf

[3] https://www.iso.org/obp/ui/#iso:std:iso-sae:21434:ed-1:v1:en

[4] https://unece.org/sites/default/files/2022-09/GRVA-14-06e_0.pdf

[5] https://upstream.auto/2022report/

‍