Keywords

1 Introduction

Cybersecurity plays a vital role in the development of connected cars. Remote hacking of cars and cyber-attacks via system penetration or network based scanning resulted in famous accidents that jeopardize the safety of many souls. In the past, vehicle vulnerability would only arise from malfunction of one or more of the internal car systems, but today, it is not enough to implement safety mechanisms without considerations of security factors from the external environment of the vehicle.

As a result, the automotive industry became aware of such challenges, and started to introduce guidelines for the development of both safety and security-based solutions. Furthermore, the possible integration between the two standards remained a critical research topic in hopes that one day we will have one single process workflow for the implementation of a software solution that is compliant to both Functional Safety as described in the ISO26262, as well as Cyber-Security as described in the SAE J3061 Guide-Book.

Today, a new factor was introduced to the equation by the German Association of the Automotive Industry VDA; which the “Automotive SPICE for Cybersecurity”, giving not only guidelines for technical implementation of such systems, but also a tool for Automotive SPICE assessors to evaluate the development process of the Cybersecurity components (System or Software) versus the expectations of the standards.

In the course of this paper, we will present how the base practices of the new Automotive SPICE processes for Cybersecurity impact the implementation of ISO26262 standard work products.

This paper is organized as follows: [1] Description of the paper background, [2] A detailed Case Study to drive the improvement of functional safety work products compliance to automotive SPICE appendix for Cybersecurity, [3] Observation & findings, [4] Results, and finally [5] Conclusion of the work.

1.1 Scope

This paper addresses the automotive tier 1 suppliers in general and automotive software suppliers who are providing software solutions in the automotive field in specific. Currently, most of the OEMs require suppliers to be certified to Automotive SPICE as a prerequisite for becoming and remaining a supplier in the OEM’s database or being considered for future business. Extending this requirement to include compliance to Automotive SPICE for Cybersecurity is a natural expectation.

1.2 Background and Approaches

The need to integrate both safety and security engineering standard approaches into one practical process has been under study for many years now. In September of the year 2017, Georg Macher, a researcher from Graz University of Technology submitted one of the latest papers on the topic under the title: “Automotive SPICE, Safety and Cybersecurity Integration” in the “International Conference on Computer Safety, Reliability, and Security” – with others [6].

The paper addressed studies, standards and work groups who covered relevant topics such as various safety assessments techniques (e.g.: Failure Mode and effect analysis (FMEA), Fault Tree Analysis (FTA)), cyber-security implementation guiding principles (e.g.: SAE J3061[9]), as well as the different approaches previously used to describe the integration between Safety and Cybersecurity (e.g.: SoQrates Security AK [11], IEC 62443 [12])… etc.

The paper also addressed newly created assessment models back then that aimed at evaluating the functional safety processes inside the automotive industry (e.g.: SS 7740 [13]) and were based on the Automotive SPICE standardized capability levels.

The presented case study was based on a safety critical system scenario (electronic steering system) that is implemented according to the ISO26262 [7] and is subject to cybersecurity threats, moving towards how the implementation of this system can be evaluated by an automotive SPICE assessor. The suggested A-SPICE assessment of the system in question was based on one approach, which assumes that both functional safety and cybersecurity criteria can be appended to A-SPICE process practices as notes, or extra base practices.

That is, if the base practice 1 of “SYS.3 SYSTEM ARCHITECTURAL DESIGN” is speaking about the need to “Define System architectural design”, the additional notes from Functional Safety would speak about the definition of “Technical Safety Concept”, while the note from cybersecurity can ask if there are any traceable cybersecurity requirements in the upstream of this architecture.

Being one of the latest comprehensive papers on the topic, the study did not tackle other assessment approaches that handled Safety aspects as separate – yet complementary - process areas to the existing process areas of Automotive SPICE. In addition, the mapping between automotive SPICE process practices, cybersecurity activities, and safety work products has not been analyzed in the first place.

With the popularity of the VDA Guidelines for the Automotive SPICE 1st Edition (also released in 2017 and known as the A-SPICE blue book), it became evident that Safety aspects are treated as notes or explanations on existing automotive SPICE process practices, up until now (see Fig. 1 Example of Automotive SPICE guideline referral to Safety aspects).

Today, and after the release of the draft Automotive SPICE appendix for Cybersecurity with completely separate processes; the need to re-evaluate the mapping of the new “SEC” process group to safety aspects, and analyze its impact on the implementation of the traditional Functional Safety work products became critical.

Fig. 1.
figure 1

Example of automotive SPICE guideline referral to Safety aspects (SYS.3)

Full size image

1.3 Relationship with the EUROSPI Manifesto

Based on the principle “Use dynamic and adaptable models as needed” from EURO Software Process improvement (EURO SPI) Manifesto [2], which aims to drive organizations improvements for software development processes through applying a combination of process models.

Also, based on the principal “Apply risk management” that enforces the organizations to consider and follow the risk based thinking methodology which is aligned with the global direction of the IATF 16949–2016 requirements that were derived in line with ISO 9001–2015 requirements.

Accordingly, the following solution was suggested to improve the organization's ability to develop Functional Safety work products that are compliant with the new cybersecurity process model extension of A-SPICE for system and software development processes in the project.

2 Case Study Methodology and Scope

A case study has been applied on a certain software project with ASiL critical components and a Cybersecurity deliverable commitment, to determine the impact of releasing the new Automotive SPICE appendix for Cybersecurity on the compliance level of the project ISO26262 work products, such that, the project “Safety Relevant” work products were assessed using A-SPICE version 3.1 and were re-inspected again using the A-SPICE appendix for Cybersecurity to see if they will obtain the same compliance level with the same gaps identified.

First, a sample of Functional Safety work product descriptions were created (templates, guidelines…) to be applied in the selected software project for the purpose of this case study according to ISO26262 mandated list of work products. The ASiL work products delivered by this project were following the provided samples.

Then that project was initially assessed by Automotive SPICE Process assessment model version 3.1 targeting capability level 2 for the VDA scope process areas, and was found compliant (without consideration of the Cybersecurity appendix).

Later, the same project with the same set of Functional Safety work products was re-inspected using the Automotive SPICE appendix for Cybersecurity, to find that there are new gaps introduced on the previously created sample of ASiL work products that we recommend should now to be covered, especially in a project with Cybersecurity requirements.

The study methodology followed in this paper work was based on following steps as per [Fig. 2]:

Fig. 2.
figure 2

Steps of this case study methodology

Full size image

  • Data Collection: In this step:

    • The Functional Safety work products that are mandated by ISO26262 according to different ASiL levels were listed, and their applicability on the Project under the case study has been decided based on the Product ASiL level (refer to Table 1).

    • The applicable ISO26262 work products were developed within the project ASiL activities according to the defined descriptions.

    • The project work products were first assessed against Automotive SPICE version 3.1 (excluding the Cybersecurity appendix), and was found compliant with capability level two (refer to Table 2) in spite of the CS deliverables.

Table 1. List of Functional Safety work products investigated
Full size table
Table 2. CL2 ASPICE Profile for the first assessment of the Project before ASPICE CS appendix Release
Full size table

  • Analysis and Assessment: In this step, the same list of project work products were then re-inspected against Automotive SPICE including the Cybersecurity appendix. and were found compliant yet a new set of gaps were identified.

  • Results consolidation and investigation: In this step, results and obtained data of the inspection from the previous step are consolidated. An investigation was carried out to determine the differences between the work product samples before and after impact of the new Automotive SPICE process group for Cybersecurity (SEC).

  • Conclusion: In this step a final recommendation is given based on application of the new proposed CS practices on the project.

3 Case Study Observations and Results Consolidation

A case study was conducted to study the impact of the BPs, outcomes, and work products of the new Automotive SPICE process group for Cybersecurity on the output work products of ISO26262 as implemented in the previously ASIL assessed software project with Cybersecurity scope.

The case study aimed at recording the observations about the differences between the work products before and after A-SPICE CS scope application in a readable format for researchers.

The following Table 3 demonstrates the project output list of Functional Safety work products investigated mapped to their relevant SEC process areas:

Table 3. List of functional safety work products investigated vs. relevant SEC process areas
Full size table

The below set of illustrations show the suggested improvements to be applied in the future to each of the ISO26262 work products from the study perspective, as a result of applying the new methodology suggested by the ASPICE appendix for CS on the project work products:

3.1 Safety Development Plan (SaDP)

In ISO26262 the safety development plan is a project management activity, which defines the safety activities and work products to be performed in that project.

When comparing it to MAN.7 BP2, it has been shown that the definition of the appropriate practices to manage the cybersecurity risks can be added as a chapter inside the safety development plan.

Also the inputs for the Safety Development Plan (SaDP) will need to take into consideration the Threat Assessment and Remediation Analysis (TARA) analysis for example, instead of the Hazards Analysis and Risk Assessment (HARA) only as before (see Fig. 3).

Fig. 3.
figure 3

Impact on SaDP from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.2 Hazard Analysis and Risk Assessment (HARA)

As shown in Fig. 4 below, the Cybersecurity goals and analysis report can be integrated with the Hazard Analysis and Risk Assessment (HARA) report to meet the criteria for SEC.1 BP1.

Security-Aware Hazard and Risk Analysis Method [SAHARA] has been introduced in this paper [5] before to fulfill such an approach [Combining between both HARA/TARA].

Fig. 4.
figure 4

Impact on Hazard Analysis from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.3 Functional Safety Concept (FSC)

Cybersecurity requirements can be embedded inside the functional safety concept and to be mapped to cybersecurity goals as they both serve the same concept of maintaining the safety and security of the product and those using it (see Fig. 5 below). A traceability record should be maintained as well.

Fig. 5.
figure 5

Impact on FSC from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.4 Technical Safety Concept (TSC)

As stated in SEC.2 BP1, the refinement of cybersecurity requirements is quite similar to the purpose of the refinement of the technical safety requirements in the Technical Safety Concept “TSaC” both can happen in the same document “TSaC”.

The allocation of the cybersecurity related requirements to system / software layers is then essential, as stated in SEC.2 BP2 (see Fig. 6):

Fig. 6.
figure 6

Impact on TSC from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.5 Safety Test Strategy

The project test strategy (System or Software) should include all test methods that will be applied on a certain solution or product.

Since most ASiL projects already have a safety test strategy (as indicated by ISO26262) which guides the working team on the needed activities to verify and validate certain safety requirements, another extension can be added for cybersecurity related tests as shown in SEC.3 BP1 and SEC.4 BP1.

The purpose of this will be to include in one place an explanation for the overall strategy of testing, with all its aspects (Safety/Security) for the given solution – see Fig. 7.

Fig. 7.
figure 7

Impact on Safety Test Strategy from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.6 Safety Design Analysis (SDA)

ISO26262 Safety Design Analysis (SDA) shall take the Cybersecurity Vulnerability Report (CSVR) into consideration while analyzing Cybersecurity components of the solution (e.g.: network based scans) in order to check if further safety mechanisms need to be implemented (see Fig. 8 below).

  • Functional Safety manager shall participate in the analysis of the defined Cybersecurity controls to be able to advise if more controls need to be implemented.

  • A few activities should be added to the solution architecture (system/ software) to ensure compliance to A-SPICE for Cybersecurity (e.g.: Vulnerability analysis report).

  • A-SPICE guideline shall refer to the need of system vulnerabilities analysis.

Fig. 8.
figure 8

Impact on SDA from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.7 Safety Verification Report (SVR)

The purpose of Safety Verification Report (SVR) as defined in ISO26262 is to ensure that all requirements defined in the Technical Safety Concept (TSaC) are consistent and have been verified on both system and software levels.

In order to align with A-SPICE for Cybersecurity, the SVR shall consider the practices SEC.3 BP6 and SEC.4 BP5 coming from Cybersecurity testing processes.

That is, the test results coming from the verification of cybersecurity related requirements shall be embedded also within the same SVR of the project.

By this integration of verification reports, we will not only ensure that safety related requirements are consistent and covered but also that cybersecurity requirements have been verified as well and are in line with the overall solution goals (refer to Fig. 9 below).

Fig. 9.
figure 9

Impact on SVR from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.8 Safety Case (SaC)

In the end of an ASiL project, the safety case is the sum of all deliverables of the safety process, we can add to it the related cybersecurity deliverables to present a cybersecurity compliant product as well (see Fig. 10 below).

Fig. 10.
figure 10

Impact on the Safety Case from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

3.9 Software Tools Qualifications Report (SWTQR)

As stated in MAN.7 BP1: Properties of assets should be defined. On the other hand, in ISO26262 we are talking about a tools qualification activity. Both serve the same concept “ Qualification and Characterization “ and can be embedded in one Work Product also (Fig. 11 below).

Fig. 11.
figure 11

Impact on SWTQR from SPICE for CS BP’s & outcomes, plus suggested improvements

Full size image

4 Study Results

The case study and inspection done above has shown that multiple ISO26262 Work Products and activities are impacted by the newly published Automotive SPICE® for Cybersecurity in the same environment, given the same inputs, and development circumstances.

The before and after evaluations of our safety critical project show that new gaps have been identified on each output work product of the ISO26262 in light of the new release of Automotive SPICE appendix for Cybersecurity.

Whether these new gaps will certainly impact the project overall compliance (capability level) to Automotive SPICE or not is a topic that needs to be further addressed and studied once the Automotive SPICE appendix for Cybersecurity has been officially released into a final edition, with a clear clarification in the VDA guidelines about the relation between its goals, practices, and outcomes and those of the original PAM v3.1 for Automotive SPICE.

5 Conclusion and Recommendations for Future Work

Cybersecurity has become a serious concern in the automotive domain in recent years due to the increasing integration of computers and connectivity in modern vehicles.

In this paper, we share our experience of applying the guidance in the newly published Automotive SPICE® for Cybersecurity in the light of the currently established ISO26262 work products.

The case study introduces an evaluation and extra guidance on how to expand the implementation of the already-existing ISO26262 activities and work products to comply with the cybersecurity practices, outcomes, or work products as essential inputs for ASiL Projects to be in line with Automotive SPICE®.

Each work product of them needs to include extra activities/inputs in order to fulfill the cybersecurity goals of a certain solution and comply with the new Automotive SPICE appendix for cybersecurity.

This imposes a conclusion of the following:

  • Functional Safety work products are impacted by the newly released standard appendix of Automotive SPICE for Cybersecurity.

  • The possibility to expand the ISO26262 activities within a project to embrace both safety and security aspects in the long run.

  • The practices for safety and security development can be smoothly integrated underneath the umbrella of Automotive SPICE.

  • A Software project with Functional Safety components and Cybersecurity constraints needs to integrate a unified solution to facilitate safe and secure communication within the whole system with minimal overhead.

We believe that these experiences and suggestions need to be shared with the automotive safety and security community to push forward automotive cybersecurity and to improve the standard in the long run.