The world has already embraced e-mobility and connected cars. The vehicular communication system (V2X) facilitates autonomous driving, increased safety on the road, energy savings, and enjoyable user experiences. It also poses new challenges and threats to personal safety, security, and privacy.
UNECE WP.29 regulation R155 for CSMS (Cyber Security Management System) is mandatory in the European Union. R155 recommends implementing requirements on the CSMS using standards such as the recently published ISO/SAE 21434. There are other mandatory or recommended standards and best practices for ensuring cyber security for automotive, such as ASPICE.
This paper presents a systematic process and methods for developing an automotive platform and ECUs for meeting regulatory requirements, complying with various automotive security standards, and attaining targeted cybersecurity assurance levels.
The classic V engineering model is followed in this process, and the ASPICE security engineering process and groups are integrated. Work products are prepared as per ISO/SAE 21434 for evidencing and evaluating the critical phases of the CSMS. A variety of cybersecurity activities beyond series production are incorporated to detect and correct newly exposed vulnerabilities. As part of the process model, the integration of the security process with the safety process is outlined to reduce the chance of missing issues early on in development.
Performing a Threat Analysis and Risk Analysis (TARA) is an iterative process and should only end when assets are sufficiently protected against threats to electrical or electronic components. With the process model, iterative TARA can be seamlessly integrated with other process models.
Introduction
Several key trends, including autonomous driving, V2X connectivity, electrification, and shared mobility, are affecting automotive security. UNECE regulations, standards like ISO/SAE 21434, ASPIC, and other existing standards for automotive cybersecurity are regulating and guiding how cars are developed and secured.
The entire value chain, including OEMs, suppliers in all tiers, must follow the regulatory requirements of UNECE R155 and R156. OEMs are legal entities that must register for CSMS and SUMS audits. OEMs must ensure that value chain partners follow and implement cybersecurity practices.
UNECE does not provide detailed guidelines on operational practices. Despite this, it strongly recommends following ISO/SAE 21434 and ISO 27001 for cybersecurity and ISO/CD 24089 for software update engineering. In what ways can cybersecurity engineering activities be integrated into ASPICE-based development cycles? In the following sections, we outline a holistic approach to automotive cybersecurity.
Process overview
Presented below is an integrated process overview diagram for developing a secure automotive ECU. Starting cybersecurity activities for a project requires an established cybersecurity management system (CSMS) per ISO/SAE 21424 clause 05 and a Software Update Management System (SUMS) per ISO/CD 24089. CSMS must define cybersecurity policy, rules, competence management for resources, continuous management, tool management, and processes. The SUMS should also specify the necessary process to ensure traceability, consistency, a unique identifier, interdependence, and compatibility during the software update process.
For the development and production of automotive ECUs, a high-security facility for protecting sensitive data must be established, along with infrastructure and procedures. As part of an organization-level CSMS, this can be handled.
The following sections provide project-specific cybersecurity activities to be performed in tandem with other product development activities to comply with regulatory requirements, meet industry standards for automotive security and achieve targeted cybersecurity assurance levels.
Planning
The project-dependent cybersecurity activity plan and responsibilities must be defined in accordance with clause 06 of ISO/SAE 21434. Control and plan should ensure that the supplier complies with all regulations and standards regarding distributed development. Within the project specific CSMS, cybersecurity cases must be opened to track the work products, updated, reviewed throughout the project, and closed with an assessment report before production is released. The cybersecurity risk management process defined in ASPCE can be considered as part of CSMS. The CSMS must limit activities related to production and operations security. SUMS must be followed for software updates.
Concept Phase
Cybersecurity development starts with the concept phase, where security requirements are elicited, as shown below. The activities must be carried out as per clause 09 of ISO/SAE 21434 and are very similar to SEC.1 process defined in ASPICE. In the concept phase, threat analysis is performed on an item, a component, or a set that implements a function at the vehicle level. It can be performed along with the SYS.1 process, and then the SYS.2 and SYS.3 processes can be followed. The ASPICE SYS.3 process can be used to determine the architecture for cybersecurity system elements based on the system requirements.
Risk assessment for cybersecurity (TARA) can be accomplished through different methods. An E-safety Vehicle Intrusion Protected Applications (EVITA) or STRIDE model can be used to assess security during the concept phase. Modeling and assessment can be performed using the Microsoft thread modeling tool with a custom template tailored to the automotive industry.
Cyber security and functional safety goals can sometimes be contradictory; for example, the cybersecurity goal ensures the service. The safety goal is to shut down a system or function when a dangerous situation is observed. Hence, the interaction between cybersecurity and functional safety is necessary, and risks and mitigation plans identified by TARA and HARA must be reviewed by the joint team and updated accordingly.
Product Development - Design
Clause 10 of ISO/SAE 21434 defines product development for cybersecurity. The process combines activities and scope of ASPICE processes SEC.2 and SEC.3. After completing the concept phase and proceeding with system engineering, the next stage in the development phase is to analyze risks in the system elements. Cybersecurity specification for system element which contains requirements and architecture is the primary input. The process would update, refine system architecture, and identify next-level cybersecurity component specifications. A risk mitigation control selected during the concept phase might introduce new assets that need to be protected. As a result, threat analysis based on STRIDE or a similar method is necessary to identify risks in the developed system.
The picture below represents a standard procedure for identifying risks and developing specifications for next-level cybersecurity components. As product development progresses and software/hardware component specifications are developed, threat analysis may not be necessary, but a vulnerability analysis will be. Likewise, the safety-security synchronization process can be omitted when system abstraction is at the unit level.
Product Development - Verification
The following diagram depicts various verification activities to confirm that the implementation and integration of the components are compliant with the refined cybersecurity requirements and architectural design. The process and actions are very similar to ASPICE SEC.3 process definition. Verification processes for software integration, hardware integration, system integration, and item integration must be followed.
Validation
Cybersecurity validation is ISO/SAE 21434 focuses on the item level, and process objectives are the same as ASPICE SEC.4. A variety of validation activities must be conducted to confirm that the cybersecurity goals and claims have been met. As shown in the figure below, we perform various validation activities as part of the vehicle project.
Production
A cybersecurity case and assessment report must be ready before production begins. The production control plans should be created according to ISO/SAE 21434 clause 12 and include instructions on installing the equipment so that no unauthorized modifications can occur.
Secure Operations
Cybersecurity continues to be a topic even beyond series production. Newly exposed vulnerabilities need to be corrected. Clause 13 of ISO/SAE 21434 is applicable for this stage. Activities include updating the vulnerability database available in the public domain, checking newly discovered vulnerabilities against product functionality/design, and Risk assessment for any design changes or newly discovered vulnerability, if applicable. It is essential to monitor internal and external sources, triage according to defined triggers, and analyze cybersecurity events.
Conclusion
As a result of new regulations, cybersecurity is no longer an option. It is mandatory, like functional safety. A process model for cybersecurity can be established in accordance with various standards and regulatory requirements, integrating seamlessly with other related development activities, helping to avoid redundancy and confusion.
KPIT is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. KPIT is a partner for prototype to production addressing embedded system challenges for hybrid and electric domains. With ready to use software platforms and accelerators for electric vehicle components, e.g., EVCC, CCS, GB/T, CHAdeMO and BMS it helps OEMs and Tier1s reduce time to market. KPIT offers consulting and engineering services to leading OEMs and Tier1 suppliers to define and execute their cybersecurity roadmap and assurance levels. Dedicated global teams across geographies, help clients with solutions around cryptography, vulnerability analysis, cybersecurity solutions, secure platforms, cybersecurity verification, validation technologies, EV charging technologies, and cybersecurity processes.
UNECE WP.29 regulation R155 for CSMS (Cyber Security Management System) is mandatory in the European Union. R155 recommends implementing requirements on the CSMS using standards such as the recently published ISO/SAE 21434. There are other mandatory or recommended standards and best practices for ensuring cyber security for automotive, such as ASPICE.
This paper presents a systematic process and methods for developing an automotive platform and ECUs for meeting regulatory requirements, complying with various automotive security standards, and attaining targeted cybersecurity assurance levels.
The classic V engineering model is followed in this process, and the ASPICE security engineering process and groups are integrated. Work products are prepared as per ISO/SAE 21434 for evidencing and evaluating the critical phases of the CSMS. A variety of cybersecurity activities beyond series production are incorporated to detect and correct newly exposed vulnerabilities. As part of the process model, the integration of the security process with the safety process is outlined to reduce the chance of missing issues early on in development.
Performing a Threat Analysis and Risk Analysis (TARA) is an iterative process and should only end when assets are sufficiently protected against threats to electrical or electronic components. With the process model, iterative TARA can be seamlessly integrated with other process models.
Introduction
Several key trends, including autonomous driving, V2X connectivity, electrification, and shared mobility, are affecting automotive security. UNECE regulations, standards like ISO/SAE 21434, ASPIC, and other existing standards for automotive cybersecurity are regulating and guiding how cars are developed and secured.
The entire value chain, including OEMs, suppliers in all tiers, must follow the regulatory requirements of UNECE R155 and R156. OEMs are legal entities that must register for CSMS and SUMS audits. OEMs must ensure that value chain partners follow and implement cybersecurity practices.
UNECE does not provide detailed guidelines on operational practices. Despite this, it strongly recommends following ISO/SAE 21434 and ISO 27001 for cybersecurity and ISO/CD 24089 for software update engineering. In what ways can cybersecurity engineering activities be integrated into ASPICE-based development cycles? In the following sections, we outline a holistic approach to automotive cybersecurity.
Process overview
Presented below is an integrated process overview diagram for developing a secure automotive ECU. Starting cybersecurity activities for a project requires an established cybersecurity management system (CSMS) per ISO/SAE 21424 clause 05 and a Software Update Management System (SUMS) per ISO/CD 24089. CSMS must define cybersecurity policy, rules, competence management for resources, continuous management, tool management, and processes. The SUMS should also specify the necessary process to ensure traceability, consistency, a unique identifier, interdependence, and compatibility during the software update process.
For the development and production of automotive ECUs, a high-security facility for protecting sensitive data must be established, along with infrastructure and procedures. As part of an organization-level CSMS, this can be handled.
The following sections provide project-specific cybersecurity activities to be performed in tandem with other product development activities to comply with regulatory requirements, meet industry standards for automotive security and achieve targeted cybersecurity assurance levels.
Planning
The project-dependent cybersecurity activity plan and responsibilities must be defined in accordance with clause 06 of ISO/SAE 21434. Control and plan should ensure that the supplier complies with all regulations and standards regarding distributed development. Within the project specific CSMS, cybersecurity cases must be opened to track the work products, updated, reviewed throughout the project, and closed with an assessment report before production is released. The cybersecurity risk management process defined in ASPCE can be considered as part of CSMS. The CSMS must limit activities related to production and operations security. SUMS must be followed for software updates.
Concept Phase
Cybersecurity development starts with the concept phase, where security requirements are elicited, as shown below. The activities must be carried out as per clause 09 of ISO/SAE 21434 and are very similar to SEC.1 process defined in ASPICE. In the concept phase, threat analysis is performed on an item, a component, or a set that implements a function at the vehicle level. It can be performed along with the SYS.1 process, and then the SYS.2 and SYS.3 processes can be followed. The ASPICE SYS.3 process can be used to determine the architecture for cybersecurity system elements based on the system requirements.
Risk assessment for cybersecurity (TARA) can be accomplished through different methods. An E-safety Vehicle Intrusion Protected Applications (EVITA) or STRIDE model can be used to assess security during the concept phase. Modeling and assessment can be performed using the Microsoft thread modeling tool with a custom template tailored to the automotive industry.
Cyber security and functional safety goals can sometimes be contradictory; for example, the cybersecurity goal ensures the service. The safety goal is to shut down a system or function when a dangerous situation is observed. Hence, the interaction between cybersecurity and functional safety is necessary, and risks and mitigation plans identified by TARA and HARA must be reviewed by the joint team and updated accordingly.
Product Development - Design
Clause 10 of ISO/SAE 21434 defines product development for cybersecurity. The process combines activities and scope of ASPICE processes SEC.2 and SEC.3. After completing the concept phase and proceeding with system engineering, the next stage in the development phase is to analyze risks in the system elements. Cybersecurity specification for system element which contains requirements and architecture is the primary input. The process would update, refine system architecture, and identify next-level cybersecurity component specifications. A risk mitigation control selected during the concept phase might introduce new assets that need to be protected. As a result, threat analysis based on STRIDE or a similar method is necessary to identify risks in the developed system.
The picture below represents a standard procedure for identifying risks and developing specifications for next-level cybersecurity components. As product development progresses and software/hardware component specifications are developed, threat analysis may not be necessary, but a vulnerability analysis will be. Likewise, the safety-security synchronization process can be omitted when system abstraction is at the unit level.
Product Development - Verification
The following diagram depicts various verification activities to confirm that the implementation and integration of the components are compliant with the refined cybersecurity requirements and architectural design. The process and actions are very similar to ASPICE SEC.3 process definition. Verification processes for software integration, hardware integration, system integration, and item integration must be followed.
Validation
Cybersecurity validation is ISO/SAE 21434 focuses on the item level, and process objectives are the same as ASPICE SEC.4. A variety of validation activities must be conducted to confirm that the cybersecurity goals and claims have been met. As shown in the figure below, we perform various validation activities as part of the vehicle project.
Production
A cybersecurity case and assessment report must be ready before production begins. The production control plans should be created according to ISO/SAE 21434 clause 12 and include instructions on installing the equipment so that no unauthorized modifications can occur.
Secure Operations
Cybersecurity continues to be a topic even beyond series production. Newly exposed vulnerabilities need to be corrected. Clause 13 of ISO/SAE 21434 is applicable for this stage. Activities include updating the vulnerability database available in the public domain, checking newly discovered vulnerabilities against product functionality/design, and Risk assessment for any design changes or newly discovered vulnerability, if applicable. It is essential to monitor internal and external sources, triage according to defined triggers, and analyze cybersecurity events.
Conclusion
As a result of new regulations, cybersecurity is no longer an option. It is mandatory, like functional safety. A process model for cybersecurity can be established in accordance with various standards and regulatory requirements, integrating seamlessly with other related development activities, helping to avoid redundancy and confusion.
KPIT is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. KPIT is a partner for prototype to production addressing embedded system challenges for hybrid and electric domains. With ready to use software platforms and accelerators for electric vehicle components, e.g., EVCC, CCS, GB/T, CHAdeMO and BMS it helps OEMs and Tier1s reduce time to market. KPIT offers consulting and engineering services to leading OEMs and Tier1 suppliers to define and execute their cybersecurity roadmap and assurance levels. Dedicated global teams across geographies, help clients with solutions around cryptography, vulnerability analysis, cybersecurity solutions, secure platforms, cybersecurity verification, validation technologies, EV charging technologies, and cybersecurity processes.
