Page tree

 

Interpretation document/guidance for Regulation on Cyber Security

 

 

United Nations

ECE /TRANS/WP.29/201x/xx

_unlogo

Economic and Social Council

Distr.: General

DD MM YYYY

 

Original: English

Economic Commission for Europe

Inland Transport Committee

World Forum for Harmonization of Vehicle Regulations

xxx session

Geneva, DD–DD MM YYYY

Item XXX of the provisional agenda

Draft new Regulation on software updates

Interpretation document for Regulation on uniform provisions concerning the approval of cyber security

Submitted by the expert from xxx

The text reproduced below was prepared by the experts from xxx


Contents [DH1]

Page

6. Cyber Security Management System (CSMS) Certificate of compliance ................. 4

7. Specifications ....................................................... 5

Annexes

1. Information document ................................................. 8

 


Introduction

 

T he UN Regulation on uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system define s   the relevant processes that should be in place and require s that manufacturers evidence that they have them, they work and that they have been applied to vehicle types. This provides for an evidence-based assessment and audit of whether the requirements are met. [nt2]

 

OICA proposal

The purpose of this document is to help clarify the requirements of the Regulation on uniform provisions concerning the approval of cyber [DH3] security software update processes   and provide information on what may be used to evidence those requirements.

The target audience for this document are for vehicle manufacturers submitting systems for test and for the Technical Services/ Appropriate Authorities assessing those systems.

The outcome should be that this document is able to help harmonise the testing evaluations [nt4] between different Technical Services/ Appropriate Authorities.

The wording used in this document respects the ISO/IEC principles and rules (ISBN 978-92-67-10603-8) :

https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor082   [DH5]

 

Note regarding evidencing the requirements [DH6]
This document is only guidance. It provides information on what information might/would be acceptable for the Technical Services/ Appropriate Authorities and what level of information might be supplied. It is not intended to be exhaustive. The standards referenced are intended as examples, not mandatory. Nevertheless, a coherence-check (see Annex A) has shown that especially the ISO/SAE 21434 DIS can be very supportive in implementing the requirements on the CSMS to the organizations along the supply chain. It should be noted that the clauses of ISO/SAE 21434 DIS referred to may change during later edition of the standard, but it is expecte d that the standard will still be relevant to those requirements [DH7] . Depending on the vehicle type defined by the vehicle manufacturer and the practices and procedures they use alterative and/or equivalent information may be supplied.

 

For all the requirements in the regulation, demonstration that they are met may be achieved via documentation/presentation and/or audit. The format of what documentation is supplied is open but should be agreed between the vehicle manufacturer and Technical Service/ Appropriate Authority prior to testing/audit. A demonstration may be provided through an overview + Diagrams + Experience. Argument that the requirements are met needs to be logical, understandable and convincing. Documents need not necessarily be large documents.

 


 

1. Scope

No guidance included in this document with regards this requirement

2. Definitions

No guidance included in this document with regards this requirement

3. Application for approval

No guidance included in this document with regards this requirement

4. Marking

No guidance included in this document with regards this requirement

5. Approval

5.3. Approval [DH8] Authorities shall not grant any type approval without verifying that the manufacturer has put in place satisfactory arrangements and procedures to manage properly the cyber security aspects as covered by this Regulation.

Explanation of the requirement

In addition to the conditions referred to in paragraph 5.1, the Approval Authority is bound to verify if all the requirements quoted in section 7 of the Regulation have been effectively fulfilled. This includes the Cyber Security Management System referred to in paragraphs 7.2 and 7.3.1.

 

 

 

5.3.1. The Approval Authority and its Technical Services shall ensure, in addition to the criteria laid down in Schedule 2 of the 1958 Agreement that they have:

a)        Competent personnel with appropriate cyber security skills and specific automotive risk assessments knowledge [1] ;

Explanation of the requirement

The requirement would imply that the authority or the service (the organisation) have at their disposal, in a sufficient number, the following categories of personnel:

  • Personnel trained and experienced in application of the Cybersecurity Regulation, as well as of any national or organisation’s rules, standards and procedures necessary for its implementation and application. These may include ISO21434 and ISO27001.
  • Personnel trained and experienced in application of methods of cyber security laboratory testing, such as, pen-, fuzz-, side channel-testing, in relation to cyber security of the vehicle.

The Regulation does not impose any specific contractual relation between the authority/service and the personnel concerned. These might be employment (labour) contracts, services contracts etc.

The number of personnel concerned must be proportionate to the actual workload.

The internal procedures of the organisation should ensure that the tasks under the Regulation are performed or effectively controlled by the personnel having relevant skills.

 

 

b)          Implemented procedures for the uniform evaluation according to this Regulation.

Explanation of the requirement

The organisation should have in place procedures ensuring that evaluation of every vehicle type is conducted according to the same scheme. If necessary, the evaluation may include variants. Application of variants is determined by clear criteria set out and explained in an internal documentation of the organisation.

In case the Approval Authority has designated several Technical Services, it needs to ensure uniformity of evaluation between different Technical Services, notably by arranging systematic meetings where the experience is exchanged.

The organisation should have processes installed for secure storage and transmission of confidential information.

The Technical Services should have processes installed to assure the integrity of the personnel involved in assessments appropriate to the risks involved.

The requirement of the Regulation cannot be discharged by mere establishment of the required processes and procedures. It also requires their effective application, which implies necessity for adequate training and effective control.

 

 

Examples of documents/evidence proving correct implementation

Interpretation documents of the Technical Services

Best practice guidelines of the TAA. These are the consolidated interpretations of the Technical Services.

Minutes of exchange of experience meetings of TAA and Technical Services.

 

5.3.2. Each Contracting Party applying this Regulation shall notify and inform by its Approval Authority other Approval Authorities about the method and criteria taken as a basis by the notifying Authority to assess the appropriateness of the measures taken in accordance with this regulation and in particular with paragraphs 5.1, 7.2 and 7.3.

This information shall be shared only before granting an approval according to this Regulation for the first time and each time the method or criteria for assessment is updated.

This information is intended to be shared for the purposes of collection and analysis of the best practice and in view of ensuring the convergent application of this Regulation by all Approval Authorities applying this Regulation.

Explanation of the requirement

This requirement aims at ensuring a minimum convergence across the Parties in the manner the requirements of paragraphs 5.1, 7.2 and 7.3 are applied. Importantly, the following sub-paragraphs must be interpreted in the manner permitting to achieve this objective. Additionally, the exchange should permit mutual learning and building of a pool of best practices which may be inspiration for further works on the amendment of the Cyber-Security Regulation in the future.

As it can be understood from joint reading of paragraphs 5.3.2 and 5.3.3, information about methods and criteria should contain

  • minimum performance levels that the Approval Authority will require to be met with regard to the specifications provided for under paragraphs 7.2 and 7.3.
  • measures and processes the Approval Authorities/their Technical services will follow when assessing the compliance following an application for a type approval

In particular, the information should include:

  • the characteristics and the minimum performance criteria that processes referred to in paragraph 7.2.2.2 must meet, including the information on the criteria used to establish if the risks referred to in paragraph 7.2.2.2.(d) are “appropriately managed”
  • the criteria that the approval authority will apply to assess if these processes  ensure that cyber threats and vulnerabilities referred to in paragraph 7.2.2.3. shall be mitigated within a reasonable timeframe, including the information on the conditions for these threats and vulnerabilities to be considered as mitigated and on the understanding of “reasonable time frame”
  • the criteria that the approval authority will apply to assess that the processes meet the requirement referred to in paragraph 7.2.2.4.
  • the criteria that the approval authority will apply to assess if the manufacturer has demonstrated that the CSMS manages dependencies referred to in paragraph 7.2.2.5.;
  • the criteria that the approval authority will apply to assess whether the CSMS certificate to be considered relevant for the vehicle type under approval;
  • for type approvals prior to 1 July 2024, the criteria that the approval authority will apply to assess if cyber security was adequately considered during the development phase of the vehicle type to the effect that it results in an equivalent cybersecurity performance;
  • the criteria that the approval authority will apply to assess whether the manufacturer has taken sufficient measures to identify and manage, for the vehicle type being approved, supplier-related risks, including the required standards for such risk management;
  • the criteria that the approval authority will apply to assess if the vehicle manufacturer has identified the critical elements of the vehicle type, including the definition of “critical elements” that the authority has adopted to this effect;
  • the criteria that the approval authority will apply to assess if the vehicle manufacturer has performed an exhaustive risk assessment for the vehicle type, as required under subparagraph 7.3.3. of the Regulation.
  • the criteria that the approval authority will apply to assess if the vehicle type is protected against risks identified in the vehicle manufacturer’s risk assessment.
  • the criteria that the approval authority will apply to assess if the mitigations applied by the manufacturer are proportionate, including the explanation of the interpretation of the term “proportionate”
  • the criteria that the approval authority will apply to assess if the mitigations referred to in Annex 5, Part B or C, are not relevant, not sufficient for the risk identified or not feasible
  • the criteria that the approval authority will apply to assess if “another mitigation” implemented by the manufacturer pursuant to subparagraph 7.3.4. is “appropriate”;
  • the criteria that the approval authority will apply to assess if the testing performed by the manufacturer to verify the effectiveness of the security measures implemented were “appropriate” and “sufficient”.
  • the criteria that the approval authority will apply to assess if measures put in place by the manufacturer to secure dedicated environments on the vehicle type for the storage and execution of aftermarket software, services, applications or data, are “appropriate” and “proportionate”, including the explanation of the interpretation of the term “proportionate” in this context;
  • the documents that the Approval Authority will require to check if  the vehicle manufacturer has taken the necessary measures referred to in subparagraph 5.1.1.
  • the tests that the Approval Authority or Technical Services will perform and the testing strategy it will apply to verify that that the vehicle manufacturer has implemented the cyber security measures they have documented;
  • the internal procedures that the Approval Authority will apply in the process of assessment under section 5 of the Regulation

It is important to stress that the Approval Authorities of the Parties are implicitly obliged to follow the methods and requirements which are subject to sharing and assessment.

 

 

 

5.3.3.       The information referred to in paragraph 5.3.2 shall be uploaded in English language to the secure internet database established by the United Nations Economic Commission for Europe (DETA) in due time and no later than 14 days before an approval is granted for the first time under the methods and criteria of assessment concerned. The information shall be sufficient to understand what minimum performance levels the Approval Authority adopted for each specific requirement referred to in paragraph 5.3.2 as well as the processes and measures it applies to verify that these minimum performance levels are met. [2]

Explanation of the requirement

Information uploaded must be objectively sufficient to understand the minimal performance levels that an authority adopted to consider that the requirements of the Regulation are complied with. This is of crucial importance, given the high-level nature and the frequent use of general clauses in formulation of these requirements.

Although the obligation to share the information, as referred to in paragraph 5.3.3., is an obligation of result and must always be met by the Approval Authority, the latter should discharge this obligation mindful of the need to avoid putting at risk the cyber security of a vehicle type approved in accordance with this Regulation.

Preferably, the information should be shared with other authorities well in advance (i.e. long before the first assessment conducted under these methods and criteria), so as to permit other authorities to examine them and, if necessary, obtain additional clarification, so as to fully achieve the objectives . However, under no circumstances can an Approval authority grant a type approval based on such methods a criteria within less than 14 days from the moment when the information was shared via DETA.

 

 

Examples of documents/evidence that could be provided

[Document to be prepared, as require in footnote to subparagraph 5.3.3.]

 

5.3.4. Approval Authorities receiving the information referred to in paragraph 5.3.2 may submit comments to the notifying Approval Authority by uploading them to DETA within 14 days after the day of notification.

Explanation of the requirement

Approval Authorities of other Contracting Parties are given the possibility, but are  under no obligation to provide comments on the information shared.

The 14 days time limit applies also in case where the information referred to in line with paragraph 5.3.2. has been shared earlier than 14 days before the approval decision. Ideally, comments of other authorities should be discussed and, if legitimate/useful, taken into account before the methods and criteria shared through DETA are applied for the first time. Therefore, interested approval authorities should react as quickly as possible by transmitting their views to the Approval authority.

 

 

5.3.5. If it is not possible for the granting Approval Authority to take into account the comments received in accordance with paragraph 5.3.4., the Approval Authorities having sent comments and the granting Approval Authority shall seek further clarification in accordance with Schedule 6 to the 1958 Agreement. The relevant subsidiary Working Party of the World Forum for Harmonization of Vehicle Regulations (WP.29) for this Regulation shall agree on a common interpretation of methods and criteria of assessment. That common interpretation shall be implemented and all Approval Authorities shall issue type approvals under this Regulation accordingly.

Explanation of the requirement

Possible comments of Approval Authorities of other Contracting Parties have no suspensive effect on the issuance of a type approval by the Approval Authority. However, if the latter decides not to take the comments on board, the Approval Authorities having made comments and the Approval Authority having issued a decision are bound to initiate a discussion before the GRVA on the methods and criteria submitted and the comments received. Although the obligation to seek further clarification is on both authorities, it is not necessary for the procedure under Schedule 6 to start that both the Authority having submitted information and the Authority having made comments take formal steps to this effect. Under Schedule 6 paragraph 3, the Chair of the GRVA is required to “identify the issues arising from diverging interpretations” of the Cybersecurity Regulation.

The interpretation of the GRVA should be guided by the purpose of the consultation procedure, as specified under paragraph 5.3.2., hence ensuring convergence in the application of the Regulation. Therefore, it should contain elements permitting to clearly establish whether the minimum performance levels and processes applied by the Approval Authority are sufficient/adequate to verify if the requirements of the Regulation have been complied with.  Once the GRVA agrees on the interpretation, this interpretation of the Regulation must be applied by all approval authorities, in all future assessment procedures (for type approvals, modifications and extensions) under the Regulation. This may require updates of the existing methods and criteria by Approval Authorities of certain or all Contracting Parties.

 

 

 

5.3.6. Each Approval Authority granting a type approval pursuant to this Regulation shall notify other Approval Authorities of the approval granted. The type approval together with the supplementing documentation shall be uploaded in English language by the Approval Authority within 14 days after the day of granting the approval to DETA.  

 

Explanation of the requirement

This requirement is distinct from and additional to the requirement of notification based on a standard form included in paragraph 5.2. The type approval must be notified together with supplementing documentation which is not specified in paragraph 5.3.6. The objective of sharing is not explicitly stated in the Regulation, but can be inferred from paragraph 5.3.7. it is to allow the approval authorities to “study” the approvals and possibly address “diverging views” in compliance with, notably, Schedule 6. Therefore, the supplementing documentation should include all elements (including test reports) sufficient to permit the approval authorities to understand if and how the methods and criteria referred to in previous paragraphs have been applied in the context of an individual approval decision.

The information must be uploaded to the DETA database.

The obligation of notification in the first sentence of paragraph 5.3.6. is not dependant on possibility to reconcile the requirement of uploading the information to DETA with its obligations under national law pertaining to security and possible confidentiality of the notified information. In the situation where uploading the information to DETA might conflict with such other obligations, the approval authority must find a way to notify the information in a secure manner.

 

 

Suggestion to the Chair: The WP will take urgent steps to adjust the security level of DETA

 

5.3.7. The Contracting Parties may study the approvals granted based on the information uploaded according to paragraph 5.3.6. In case of any diverging views between Contracting Parties this shall be settled in accordance with Article 10 and Schedule 6 of the 1958 Agreement. The Contracting Parties shall also inform the relevant subsidiary Working Party of the World Forum for Harmonization of Vehicle Regulations (WP.29) of the diverging interpretations within the meaning of Schedule 6 to the 1958 Agreement. The relevant Working Party shall support the settlement of the diverging views and may consult with WP.29 on this if needed.

Explanation of the requirement

In case of “diverging views” regarding the information on the type approval  among the Approval Authorities, reference is made to Article 10 of the Agreement and to Schedule 6. The procedure under Article 10 is reserved for cases, where the dispute the interpretation of the Agreement. By contrast, any dispute arising in the context of the type approval which concerns the application or interpretation of the Regulation (hence also the application of the methods and criteria referred to in paragraph 5.3.3.) must be solved pursuant to Schedule 6, in this case: its paragraph 2.

 

6. Cyber Security Management System (CSMS) Certificate of Compliance

No guidance included in this document with regards this requirement

7. Specifications

7.1. General specifications

7.1.1. The requirements of this Regulation shall not restrict provisions or requirements of other UN Regulations.

 

Explanation of the requirement

The requirements of this Regulation shall not restrict provisions or requirements of other UN Regulations as well as national or regional legislations as described in points 1.3 and 1.4 of the scope of this Regulation.

This is a reminder that the   requirement s of this regulation shall not be in contradiction to other UN Regulations.   There is no requirement for the vehicle manufacturer to provide any evidence here . Compliance to other UN Regulations will be evidenced at the time of type approval of those Regulations. [DH9]

 

 

7.2. Requirements for the Cyber Security Management System

7.2.1. For the assessment the Approval Authority or its Technical Service shall verify that the vehicle manufacturer has a Cyber Security Management System in place and shall verify its compliance with this Regulation.

 

Explanation of the requirement

The intention of this requirement is that the Technical Service or Approval Authority shall verify that:

- The vehicle manufacturer has a CSMS

- The presented CSMS complies to the requirements listed below in this regulation

 

For this requirement the focus is on the manufacturer’s processes and assessing if they are in place, in order to get an overview of the capability of the manufacturer to fulfil the requirements of the CSMS.

 

The follow clarifications should be noted:

-           The CSMS may be a part of the organization’s Quality Management System or be independent of it

-           If the CSMS is part of the organization’s QMS it should be clearly identifiable.

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434 may be used as the basis for evidencing and evaluating the CSMS. Clauses 5. “Overall cybersecurity management”, 6. “Project dependent cybersecurity management”, and 7. “Continuous cybersecurity activities” could be used to evaluate the CSMS in general.

-           ISO 18045, ISO 15408, ISO 27000 series, ISO 31000 series may be applicable to relevant parts of the CSMS

 

 

 

7.2.2. The Cyber Security Management System shall cover the following aspects:

 

7.2.2.1. The vehicle manufacturer shall demonstrate to an Approval Authority or Technical Service that their Cyber Security Management System applies to the following phases:

- Development phase;

- Production phase;

-   Post-production phase.

 

Explanation of the requirement

The intention of this requirement is that the cybersecurity management system should be able to demonstrate how a manufacturer will handle cybersecurity during the operational life of vehicles produced under a vehicle type. This includes evidencing that there are procedures and processes implemented to cover the three phases. The different phases of the lifecycle may have specific activities to be performed in each of them.

 

7.2.2.1 describes the different phases of the vehicle type to be considered in the CSMS and 7.2.2.2 applies to all these phases if not stated otherwise. The phases also apply to 7.2.2.4.

 

The CSMS may include active and/or reactive processes or procedures covering the end of support for a vehicle type and how this is implemented or triggered. It may include the possibility to disconnect non-mandatory functions/systems and under what conditions this might happen.

 

The operational life (use phase) of an individual vehicle will commence during the production phase of the vehicle type. It will end during either the production phase or post-production phase of the vehicle type.

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434 can be used as the basis for evidencing and evaluating the required phases of the CSMS. Clauses 9. “Concept Phase”, 10. “Product Development”, and 11. “Cybersecurity validation” could be used to evaluate the Development phase of the CSMS. Clause 12. “Production” could be used to evaluate the Production phase of the CSMS. Clauses 7. “Continuous cybersecurity activities”, 13. “Operations and maintenance”, and 14. “Decommissioning” could be used to evaluate the Post-production phase of the CSMS.

-           Other standards that may be applicable to 7.2.2 and its sub-requirements include: ISO 18045, ISO 15408, ISO 27000 series, ISO 31000 series

 

 

7.2.2.2. The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management System ensure security is adequately considered, including risks and mitigations listed in Annex 5. This shall include:

 

a)   The processes used within the manufacturer’s organization to manage cyber security;

 

Explanation of the requirement

The aim of this requirement is to ensure that the organization has processes to manage the implementation of the CSMS. Its scope is limited to processes that are relevant for the cyber security of the vehicle types and not other aspects of the organization. For example, the scope of this requirement is not intended to cover the entire Information Security Management System of an organization.

 

The following could be used to show the range of activities performed by the manufacturer to manage the cyber security of the development, production and post-production phases of a vehicle type:

-           Organizational structure used to address Cybersecurity

-           Roles and Responsibilities regarding cybersecurity management incl. accountability

 

 

Examples of documents/evidence that could be provided

 

-           ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on [RQ-05-01], [RQ-05-02]. [RQ-05-07], [RQ-05-08].

-           BSI PAS 1885 could be used to help evidence this requirement. National certification schemes, like the UK Cyber Essentials, could be used to evidence a manufacturer’s organizational processes.

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. Your policies [DH10] Policies and p P [DH11] rocesses are absent or incomplete.
  2. Policies and p P [DH12] rocesses are not applied universally or consistently. 
  3. People often or routinely circumvent policies and p p rocesses to achieve business objectives.
  4. Your o rganisation’s The vehicle manufacturer’s [DH13] security governance and risk management approach has no bearing on your  its policies and p p rocesses.
  5. System security is totally reliant on users' careful and consistent application of manual security processes.
  6. Policies and p P [DH14] rocesses have not been reviewed in response to major changes (e.g. technology or regulatory framework), or within a suitable period.
  7. Policies and p P [DH15] rocesses are not readily available to staff, too detailed to remember, or too hard to understand.

 

The requirement may be considered fulfilled if all the following statements are true

  1. You  The vehicle [DH16] manufacturer fully document s your its overarching security governance and risk management approach, technical security practice and specific regulatory compliance. Cyber security is integrated and embedded throughout these policies and processes and key performance indicators are reported to your its executive management.
  2. Your o rganisation’s The vehicle manufacturer’s [DH17] policies and processes are developed to be practical, usable and appropriate for your  its policies and   technologies.
  3. Policies and p P [DH18] rocesses that rely on user behaviour are practical, appropriate and achievable. 
  4. You  The vehicle [DH19] manufacturer review and update reviews and updates policies and processes at suitably regular intervals to ensure they remain relevant. This is in addition to reviews following a major cyber security incident.
  5. Any changes to the essential function or the threat it faces triggers a review of policies and processes. 
  6. Your The vehicle manufacturer’s [DH20] systems are designed so that they remain secure even when user security policies and processes are not always followed. For such claim a justification should be provided.

 

 

 

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.

 

Explanation of the requirement

The aim of this requirement is for a manufacturer to demonstrate the processes and procedures they use to identify risks to vehicle types.

 

Processes implemented should consider all probable sources of risk. This shall include risks identified Annex 5 of the Cyber Security Regulation e.g. risks arising from connected services or dependencies external to the vehicle.

 

Sources for risk identification may be stated. These may include:

-           Vulnerability/ Threats sharing platforms

-           Lessons learned regarding risks and vulnerabilities

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

ISO/SAE 21434, especially based on [RQ-08-01], [RQ-08-02], [RQ-08-08], [RQ-08-09].

The processes may consider:

-           Identification the relevance of a system to cybersecurity

-           Description of the overall system with respect to

  • Definition of the system/function
  • Boundaries and interactions with other systems
  • Architecture
  • Environment of operation of the system (context, constraints and assumptions)

-           Identification of assets

-           Identification of threats

-           Identification of vulnerabilities

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. Risk identification is not based on a clearly defined set of assumptions.
  2. Risk identification for vehicle types are a "one-off" activity (or not done at all).
  3. Vehicle types are assessed in isolation, without consideration of dependencies and interactions with other systems. (e.g. interactions between IT and OT environments).

 

 

The requirement may be considered fulfilled if all the following statements are true

  1. Your   The vehicle manufacturer’s [DH21] organisational process ensures that security risks to vehicle types are identified, analysed, prioritised, and managed.
  2. Your   The vehicle manufacturer’s [DH22] approach to risk is focused on the possibility of adverse impact to your its vehicle types, leading to a detailed understanding of how such impact might arise as a consequence of possible attacker actions and the security properties of your its networks and systems.
  3. Your   The vehicle manufacturer’s [DH23] risk identification is based on a clearly understood set of assumptions, informed by an up-to-date understanding of security threats to your its vehicle types and your its sector.
  4. Your   The vehicle manufacturer’s [DH24] risk identification is informed by an understanding of the vulnerabilities in your its vehicle types.
  5. Your   The vehicle manufacturer [DH25] perform performs detailed threat analysis and understand how this applies to your its organisation in the context of the threat to your its vehicle types and your its sector.

 

c) The processes used for the assessment , categorization and treatment of the risks identified;

 

Explanation of the requirement

The aim of this requirement is that the manufacturer demonstrates the processes and rules they use to assess, categorize and treat risks identified.

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434, especially based on [RQ-08-11], [RQ-08-04]. [RQ-08-06], [RQ-08-10], [RQ-08-12], [RQ-09-07 ], [RQ-05-06], [RQ-09-08].

-           BSI PAS 11285 may be applicable for the consideration of safety and security.

 

The processes may consider:

-           Assessing the associated impact related to the risks identified in requirement 7.2.2.2 b)

-           Identification of potential attack paths related to risks identified in requirement 7.2.2.2 b)

-           Determination of feasibility/likelihood of attack for every attack paths identified above

-           Calculation and categorization of risks

-           Treatment options of those identified and categorized risks

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. Risk assessment outputs are too complex or unwieldy to be consumed by decision-makers and are not effectively communicated in a clear and timely manner.
  2. Security requirements and mitigation techniques are arbitrary or are applied from a control catalogue without consideration of how they contribute to the security of vehicle types.
  3. Only certain domains or types of asset are documented and understood. Dependencies between assets are not understood (such as the dependencies between IT and OT).
  4. Inventories of assets relevant to vehicle types are incomplete, non-existent, or inadequately detailed.
  5. Asset inventories are neglected and out of date.
  6. Systems are assessed in isolation, without consideration of dependencies and interactions with other systems (e.g. interactions between IT and OT environments).
  7. Risk assessments are not based on a clearly defined set of assumptions.
  8. Risk assessments for vehicle types are a "one-off" activity (or not done at all). [DH26]

 

 

The requirement may be considered fulfilled if all the following statements are true

  1. The output from your   the vehicle manufacturer’s [DH27] risk management process is a clear set of security requirements that will address the risks in line with your its organisational approach to security.
  2. All assets relevant to the secure operation of your its [DH28] vehicle types are identified and inventoried (at a suitable level of detail).
  3. The inventory is kept up-to-date.
  4. Dependencies on supporting infrastructure are recognised and recorded.
  5. You have   The vehicle manufacturer has [DH29] prioritised assets according to their importance to the operation of your its vehicle types.
  6. Your   The vehicle manufacturer’s [DH30] risk identification is based on a clearly understood set of assumptions, informed by an up-to-date understanding of security threats to your its vehicle types and your its sector.
  7. Your   The vehicle manufacturer’s [DH31] risk identification is informed by an understanding of the vulnerabilities in your its vehicle types. [DH32]

 

 

d)   The processes in place to verify that the risks identified are appropriately managed ;

 

Explanation of the requirement

The aim of this requirement is that the manufacturer demonstrates the processes and rules they use to decide how to manage the risks. This can include the decision criteria for risk treatment, e.g. the process for selecting what controls to implement and when to accept a risk.

 

The results of the process for risks identification and assessment should feed into selecting the appropriate treatment category options to address those risks.  The outcome of this process should be that the residual risk (risks remaining after treatment) is within the manufacturer’s stated tolerance of risks (i.e. within stated acceptable limits).

 

Controls Mitigations identified in Chapter Annex 5 and Annex C of the Cyber Security Recommendation Regulation may be included shall be considered in the processes. [DH33] [DH34]

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on [RQ-09-09].

-           ISO 31000 may be applicable if adapted for product related risks

 

The processes may consider:

-           Appropriate and proportional risk treatment methodologies

-           Treatment of critical elements (with safety and environment) to ensure the risks to them are appropriately mitigated and proportionately based on the safety or environmental goal of dependent vehicle systems

-           Ensuring the residual risk remains within acceptable limits for components or the overall vehicle type

-           Detailing any cases where the organization would accept justification for non-adherence to their stated risk tolerance

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. The security elements of projects or programmes are solely dependent on the completion of a risk management assessment without any regard to the outcomes.
  2. There is no systemic process in place to ensure that identified security risks are managed effectively.
  3. Risks remain unresolved on a register for prolonged periods of time awaiting senior decision-making or resource allocation to resolve.

 

 

The requirement may be considered fulfilled if all the following statements are true

  1. Significant conclusions reached in the course of your   the vehicle manufacturer’s [DH35] risk management process are communicated to key security decision-makers and accountable individuals.
  2. The effectiveness of your   the vehicle manufacturer’s [DH36] risk management process is reviewed periodically, and improvements made as required.

 

 

 

e)   The processes used for testing the cyber security of a vehicle type;

 

Explanation of the requirement

The aim of this requirement is to ensure the manufacturer has appropriate capabilities and processes for testing the vehicle type throughout its development and production phases.

 

Testing processes in the production phase may be different to the ones used during the development phase.

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on [RQ-09-10], [RQ-10-01]. [RQ-11-01], [RQ-11-02], [RQ-12-01].

-           BSI PAS 11825 may be utilised for considering the interaction of safety and security and processes for evidencing security outcomes are met

 

The processes may consider:

Development Phase:

-           Organization specific rules for testing during development

-           Processes for creation and execution of test strategies

-           Processes for cybersecurity testing planning

-           Processes for cybersecurity system design testing

-           Processes for cybersecurity software unit testing

-           Processes for cybersecurity hardware testing

-           Processes for cybersecurity integration testing

-           Processes for documentation of the results of testing

-           Processes for handling vulnerabilities identified during testing

-           Justification and requirements for cybersecurity tests, like Functional (requirement-based, positive and negative) testing, Interface testing, Penetration testing, Vulnerability scanning, Fuzz testing but not limited to the same

Production Phase:

-          Processes for testing to ensure the produced system has the cybersecurity requirements, controls and capabilities outlined in the production plan

-          Processes for testing to ensure the produced item meets the cybersecurity specifications which are in accordance with the system in the development phase

-          Processes for testing to assure that cybersecurity controls and configuration as cybersecurity specifications are enabled in the produced item

-          Processes for documenting the test results and findings handling

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. A particular product or service is seen as a "silver bullet" and vendor claims are taken at face value.
  2. Assurance methods are applied without appreciation of their strengths and limitations, such as the risks of penetration testing in operational environments.
  3. Assurance is assumed because there have been no known problems to date.

 

 

The requirement may be considered fulfilled if all the following statements are true

  1. You   The vehicle manufacturer [DH37] validate validates that the security measures in place to protect systems are effective and remain effective until the end-of-life of all vehicles under the vehicle types for which they are needed.
  2. You   The vehicle manufacturer [DH38] understand understands the assurance methods available to you it and choose chooses appropriate methods to gain confidence in the security of vehicle types.
  3. Your   The vehicle manufacturer’s [DH39] confidence in the security as it relates to your its technology, people, and processes can be justified to, and verified by, a third party.
  4. Security deficiencies uncovered by assurance activities are assessed, prioritised and remedied when necessary in a timely and effective way.
  5. The methods used for assurance are reviewed to ensure they are working as intended and remain the most appropriate method to use.

 

 

f)   The processes used for ensuring that the risk assessment is kept current ;

 

Explanation of the requirement

The aim of this requirement is to ensure the risk assessment is kept current. This should include processes to identify if the risks to a vehicle type have changed and how this will be considered within the risk assessment.

 

Sources for risk identification may be stated. These may include:

-           Vulnerability/ Threats sharing platforms

-           Lessons learned regarding risks and vulnerabilities

-           Conferences

 

It is noted that requirements 7.2.2.2 parts f) to h) may have overlaps in terms of the processes used and therefore the same evidence may be applicable to demonstrating that these requirements are met.

 

 

Examples of documents/evidence that could be provided

ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on [RQ-11-03], [RQ-06-08]. [RQ-07-05], [RQ-07-06].

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. No processes are in place which require the risk assessment to be updated.

 

 

The requirement may be considered fulfilled if all the following statements are true

  1. You   The vehicle manufacturer [DH40] conduct conducts risk assessments when significant events potentially affect vehicle types, such as replacing a system or a change in the cyber security threat.
  2. Your   The vehicle manufacturer’s [DH41] risk assessments are dynamic and updated in the light of relevant changes which may include technical changes to vehicle types, change of use and new threat information.

 

 

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;

 

Explanation of the requirement

The aim of this requirement is to ensure that the manufacturer has processes to monitor for cyber-attacks, threats or vulnerability to vehicles that the manufacturer has had type approved, i.e. are in the post-production or production phase, and that they have established processes that would permit them to respond in an appropriate and timely manner.

 

It is noted that requirements 7.2.2.2 parts f) to i) may have overlaps in terms of the processes used and therefore the same evidence may be applicable to demonstrating that these requirements are met.

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on [RQ-07-01], [RQ-07-02]. [RQ-07-03], [RQ-07-04], [RQ-07-05], [RQ-15-04], [RQ-15-05], [RC-15-03], [RQ-13-01], [RQ-13-02], [RQ-13-03].

The following could be used to evidence the processes used:

-           Cybersecurity monitoring processes for post-production vehicles. This may include processes that will collect information that may or may not be pertinent to the manufacturer’s vehicle/system

-           Cybersecurity information assessment processes. These will be processes for the identification of the relevance of the information collected with respect to the system/vehicle of the manufacturer

-           Processes for risk determination/assessment for the relevant information

-           Incident response procedures for both vehicles already registered and yet to be registered of the vehicle types covered by the CSMS, which may include evidence of procedures for:

  • Interaction with authorities
  • Identified or stated triggers that would lead to an escalation or action
  • Determining what response options might be implemented for which condition
  • Handling any dependencies and interactions with suppliers

-           Evidence that the response procedures would work, for example through exercising and verification that planning assumptions remain valid under test.

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. Your organisation   The vehicle manufacturer [DH42] has no sources of threat intelligence.
  2. You   The vehicle manufacturer [DH43] do does not apply updates in a timely way, after receiving them.
  3. You   The vehicle manufacturer [DH44] do does do not evaluate the usefulness of your its threat intelligence or share feedback with providers, authorised aftermarket service providers or other users
  4. There are no staff who perform a monitoring function.
  5. Monitoring staff do not have the correct specialist skills.
  6. Monitoring staff are not capable of reporting against governance requirements.
  7. Security alerts relating to vehicle types are not prioritised.

 

 

The requirement may be considered fulfilled if all the following statements are true

  1. Data relating to the security and operation of vehicle types is collected.
  2. Alerts from third parties are investigated, and action taken.
  3. Some logging datasets can be easily queried with search tools to aid investigations.
  4. The resolution of alerts to an asset or system is performed regularly.
  5. Security alerts relating to vehicle types are prioritised.
  6. Your organisation   The vehicle manufacturer [DH45] uses threat intelligence services which are relevant to your its business needs, or specific threats in your sector
  7. You   The vehicle manufacturer [DH46] apply applies updates in a timely way.
  8. You   The vehicle manufacturer [DH47] know knows  how effective your its threat intelligence is (e.g. by tracking how threat intelligence helps you it identify security problems).
  9. Monitoring staff have appropriate investigative skills and a basic understanding of the data they need to work with.
  10. Monitoring staff can report to other parts of the organisation (e.g. security directors, resilience managers).

 

 

 

h)   The processes used to provide relevant data to support analysis of attempted or successful cyber-attacks;

 

Explanation of the requirement

The intention of this requirement is to ensure that a process has been established to provide the data required for analysis and associated responsibilities for handling the data and analysis.

 

ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on [RQ-07-03].

 

 

Examples of documents/evidence that could be provided

The following could be used to evidence the processes used:

- Procedure for implementing Security Incident Response Team activities (incidents)

- Field monitoring (obtaining information on incidents and vulnerabilities)

- Procedure when an incident occurs (including an overview of what information is passed to the analyst in what steps)

- Procedure when a vulnerability is discovered (including an overview of what information is passed to the analyst in what steps)

 

 

 

7.2.2.3. The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management System will ensure that, based on categorization referred to in paragraph 7.2.2.2 (c) and 7.2.2.2 (g), cyber threats and vulnerabilities which require a response from the vehicle manufacturer shall be mitigated within a reasonable timeframe.

 

Explanation of the requirement

The intention of this requirement is to ensure that after the identified risks have been classified, a process has been established to determine the response time limit based on the classification results.

 

It is necessary to set the response deadline by processes such as triage and explain the monitoring process to see if it is executed within the deadline.

 

The timeframes provided by the manufacturers should be able to be justified and explained. There may be a set of timeframes covering different possible situations. This should include timeframes for deciding and implementing possible reactions or responses.

 

 

Examples of documents/evidence that could be provided

The following could be used to evidence the processes used:

Procedure for implementing SIRT activities (incidents)

  • Field monitoring (obtaining information on incidents and vulnerabilities)
  • Procedure when an incident occurs
  • Procedures for discovering vulnerabilities

 

 

 

7.2.2.4. The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management System will ensure that the monitoring referred to in paragraph 7.2.2.2 (g) shall be continual. This shall:

(a) Include vehicles after first registration in the monitoring;

(b) Include the capability to analyse and detect cyber threats, vulnerabilities and cyber-attacks from vehicle data and vehicle logs . This capability shall respect paragraph 1.3. and the privacy rights of car owners or drivers, particularly with respect to consent.

 

Explanation of the requirement

The intention of this requirement is to ensure that a process for analysis is established using the information on monitoring acquired in accordance with 7.3.7. [DH48]

 

ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on 7.3 “Cybersecurity Monitoring”, 7.4 “Cybersecurity event assessment”, 7.5 “Vulnerability analysis.

 

 

Examples of documents/evidence that could be provided

The following could be used to evidence the processes used:

Procedure for implementing SIRT activities (incidents)

-Field monitoring (obtaining information on incidents and vulnerabilities)

-Procedure when an incident occurs

-Procedures for discovering vulnerabilities

 

 

 

 

7.2.2.5. The vehicle manufacturer shall be required to demonstrate how their Cyber Security Management System will manage dependencies that may exist with contracted suppliers, service providers or manufacturer’s sub-organizations in regards of the requirements of paragraph 7.2.2.2.

 

Explanation of the requirement

The intention of this requirement is to ensure that it can be shown that risks from suppliers are able to be known and can be managed within the processes described in the CSMS. The steps taken should be proportionate to the risks from what is supplied.

 

The final implementation of the processes may be incorporated into bilateral agreement between the vehicle manufacturer and their suppliers.

 

Within the CSMS there may be processes to:

-           identify risks associated with parts, components, systems or services provided by suppliers

-           manage risks to the vehicle coming from service providers providing connectivity functions or services that a vehicle may rely on, this may include for example cloud providers, telecom providers, internet providers and authorised aftermarket service providers

-           ensure contracted suppliers and/or service providers are able to evidence how they have managed risks associated with them. The processes may include consideration of validation or testing requirements that may be used to evidence that risks are appropriately managed

-           delegate relevant requirements to relevant departments or sub-organisations of the manufacturer, in order to manage risks identified

 

It is noted that it is possible to put requirements on Tier1 suppliers and to require they cascade it to Tier 2 suppliers. However, it may be difficult for a manufacturer to cascade requirements further down in the supply chain (especially legally binding requirements).

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434 can be used as the basis for evidencing and evaluating as required, especially based on [RQ-06-09], [RQ-15-03], [RC-15-02].

 

The following could be used to evidence the processes used:

-           Contractual agreements in place or evidence of such agreements

-           Evidenced arguments for how their processes will ensure suppliers / service providers will be considered in the risk assessment process

-           Procedures/Methods of sharing information on risk between suppliers and manufacturers

-           Existing solutions / contracts like ISMS (Information Security Management System) regulation can be used for evidence

 

 

The requirement should be considered unfulfilled if one of the following statements is true

  1. Relevant contracts with suppliers and service providers do not have cyber security requirements.

 

 

The requirement may be considered fulfilled if all the following statements are true

  1. The vehicle manufacturer has a deep understanding of its supply chain, including sub-contractors and the wider risks it faces. The vehicle manufacturer considers factors such as supplier’s partnerships, competitors, nationality and other organisations with which they sub-contract. This informs its risk assessment and procurement processes.
  2. The vehicle manufacturer’s approach to supply chain risk management considers the risks to its vehicle types arising from supply chain subversion by capable and well-resourced attackers.   
  3. The vehicle manufacturer has confidence that information shared with suppliers that is essential to the operation of your vehicle types is appropriately protected from sophisticated attacks.
  4. The vehicle manufacturer can clearly express the security needs it places on suppliers in ways that are mutually understood and are laid in contracts. There is a clear and documented shared-responsibility model.  
  5. All network connections and data sharing with third parties is managed effectively and proportionately.
  6. When appropriate, the vehicle manufacturer’s incident management process and that of its suppliers provide mutual support in the resolution of incidents.

 

 

7.3. Requirements for vehicle types

7.3.1. The manufacturer shall have a valid Certificate of Compliance for the Cyber Security Management System relevant to the vehicle type being approved.

 

However, for type approvals prior to 1 July 2024, if the vehicle manufacturer can demonstrate that the vehicle type could not be developed in compliance with the CSMS, then the vehicle manufacturer shall demonstrate that cyber security was adequately considered during the development phase of the vehicle type concerned.

 

Explanation of the requirement

The intention of this requirement is to ensure that there is a valid Certificate of Compliance for CSMS to enable type approval to be given for any new vehicle type and that it is appropriate to the vehicle type.

 

The following clarification should be noted:

-           "relevant to the vehicle type being approved." means the CSMS should be applicable to the vehicle type being approved

 

 

Examples of documents/evidence that could be provided

The following could be used to evidence the validity of the CSMS certificate:

-           The Certificate of Compliance for CSMS to demonstrate it is still valid

-           Confirmation that the CSMS is appropriately applied to the vehicle type and any information required to provide assurance.

 

 

7.3.2. The vehicle manufacturer shall identify and manage, for the vehicle type being approved, supplier-related risks

 

Explanation of the requirement

This requirement specifically references gaining sufficient information from the supply chain and is linked to 7.2.2.5. The intention of this requirement is to ensure that information presented (together with that from the manufacturer) is sufficient to allow an assessment to be conducted of the requirements 7.3.3 to 7.3.6.

 

The following clarification should be noted:

-           "supplier-related risks" -  The aim is that it can be shown that risks from suppliers are able to be known and can be managed. It is accepted that it is difficult to cascade requirements down in the supply chain beyond Tier 2 suppliers and ensure they are legally binding

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434

 

The following could be used to evidence the processes used:

-           Evidence in the form of contract sections with suppliers that deal with the requirements of this regulation

 

 

 

7.3.3 The vehicle manufacturer shall identify the critical elements of the vehicle type and perform an exhaustive risk assessment for the vehicle type and shall treat/manage the identified risks appropriately. The risk assessment shall consider the individual elements of the vehicle type and their interactions. The risk assessment shall further consider interactions with any external systems. While assessing the risks, the vehicle manufacturer shall consider the risks related to all the threats referred to in Annex 5, Part A, as well as any other relevant risk.

 

 

Explanation of the requirement

The intention of this requirement is that the vehicle manufacturers shall identify the critical elements of a vehicle type with respect to cyber security and provide justification for how risks related to them are managed.

 

The manufacturer should be able to provide justification for why they have identified elements of a vehicle type as critical (or not).

 

The following clarifications should be noted

-           Critical elements may be elements contributing to vehicle safety, environment protection or theft protection. They could be parts which provide connectivity. They may also be parts of the vehicle architecture which are critical for sharing information or cyber security (e.g. gateways could be also considered critical)

 

The intention of this requirement is to ensure that risks shall be appropriately processed / managed by considering all threats including Annex5_PartA and judging the necessity of countermeasures based on the results of risk analysis and risk evaluation.

 

The intention of this requirement is to allow the vehicle manufacturer to demonstrate the application of the relevant process in requirements 7.2.2.2 and 7.2.2.4 of the CSMS to the vehicle type.

 

The approval authority or technical service shall refer to Annex 5 of the Cyber Security Regulation to aid their assessment of the manufacturer’s risk assessment.

 

The consideration of risks should consider the requirements of 7.3.4 and the requirement for proportionate mitigations.

 

The consideration of the threats and mitigations of Annex 5 within a risk assessment may lead to ratings like “not relevant” or “negligible risks”.

 

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434 describes the way to define the concept. This also includes the consideration of critical elements based on risk treatment decisions. The results are documented in Cybersecurity goals and Cybersecurity concept. If further describes exhaustive risk assessment in clause 8 “Risk assessment methods”. This is documented in Threat analysis and risk assessment.

-           ETSI TS 103 645 may be used for demonstrating the security of Internet of Things elements of a vehicle.

-           BSI PAS 1885 may be used

 

The following could be used to evidence this requirement:

-           The vehicle type claimed

-           An explanation of why elements within the vehicle type are critical

-           What security measures are implemented, including information on how they work

-           Information on any security measures should permit the Technical Service/ Approval Authority to both be assured that they do what the manufacturer intends and that vehicles in production will use the same measure as presented to the TS/AA for the vehicle type. Confidentiality of specifics and how these are handled should be agreed and recorded.

 

 

 

7.3.4. The vehicle manufacturer shall protect the vehicle type against risks identified in the vehicle manufacturer’s risk assessment. Proportionate mitigations shall be implemented to protect the vehicle type. The mitigations implemented shall include all mitigations referred to in Annex 5, Part B and C which are relevant for the risks identified. However, if a mitigation referred to in Annex 5, Part B or C, is not relevant or not sufficient for the risk identified, the vehicle manufacturer shall ensure that another appropriate mitigation is implemented.

 

In particular, for type approvals prior to 1 July 2024, the vehicle manufacturer shall ensure that another appropriate mitigation is implemented if a mitigation measure referred to in Annex 5, Part B or C is technically not feasible. The respective assessment of the technical feasibility shall be provided by the manufacturer to the approval authority.

 

Explanation of the requirement

The intention of this requirement is to ensure that vehicle manufacturers implement appropriate mitigation measures in accordance with the results of their risk assessment.

 

The manufacturer should provide reasoned arguments and evidence for the mitigations they have implemented in the design of the vehicle type and why they are sufficient. This may include any assumptions made, for example about external systems that interact with the vehicle.

 

The following clarifications should be noted:

-           The design decisions of the manufacturer should be linked to the risk assessment and risk management strategy. The manufacturer should be able to justify the strategy implemented 

-           The term “proportionate” should be considered when choosing whether to implement a mitigation and what mitigation should be implemented. If the risk is negligible then it may be argued that a mitigation would not be necessary.

-           Protection from identified risks means to mitigate the risk.

 

The technical mitigations from Annex 5, Parts B+C shall be considered wherever applicable to the risks to be mitigated. The Manufacturer may present a rationale not only for a listed mitigation from Annex 5 being “not relevant or not sufficient”, but also may present a rationale, that another mitigation other than the ones listed in Annex 5 is appropriate to the respective risk. That rationale may be substantiated by a risk assessment and risk rating showing the appropriateness of the alternative mitigation. This is to allow the adoption of new or improved defensive technologies.

 

 

Examples of documents/evidence that could be provided

[ The following could be used to evidence the processes used:

Evidence that mitigation measures were introduced according to the necessity of measures, this includes:

the reason, if mitigation measures other than Annex 5 Part B and C are applied

the reason, if mitigation measures are determined to be unnecessary [DH49] ] [DH50]

 

 

The following standards may be applicable:

-           ISO/SAE 21434 describes the identification of risk and the deduced Cybersecurity goals and concept based on the identified risks. The results are documented in [WP-09-04] Cybersecurity goals and [WP-09-07] Cybersecurity concept.

-           PAS 11825 and other standards regarding claims, arguments and evidence may be used to justify the design decisions of the manufacturer

 

 

Discussion on chapter 7 paused here

 

7.3 .5. The vehicle manufacturer shall put in place appropriate and proportionate measures to secure dedicated environments on the vehicle type (if provided) for the storage and execution of aftermarket software, services, applications or data.

 

Explanation of the requirement

The following clarifications should be noted:

-             "appropriate and proportionate measures" requires that the manufacturer is able to justify how  risks associated with any dedicated environment, as defined in their risk assessment, are managed

-             Dedicated environments can be on the vehicle. If the vehicle interacts with servers or services located off the vehicle (for example in the cloud) then the risks to the vehicle originating from them, with respect to their cyber security, should be considered

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           ISO/SAE 21434 describes on a process base steps to make conclusion for the architecture. This aspect is to be considered in  [WP-08-03] Threat scenarios.

 

The following could be used to evidence this requirement:

-           A description of the dedicated environment

-           What security measures are implemented, including information on how they work

-           Information on any security measures should permit the TS/AA to both be assured that they do what the manufacturer intends and that vehicles in production will use the same measure as presented to the TS/AA for the vehicle type. Confidentiality of specifics and how these are handled should be agreed and recorded.

-           Annex es   A and B   5 of the cyber security Regulation   [DH51] Resolution   Annexes B and C of the cyber security recommendation may be referred to.

 

 

 

7.3. 6. The vehicle manufacturer shall perform , prior to type approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented.

 

Explanation of the requirement

The test results should be valid at time of type approval. The Technical Service may perform security tests to confirm the results.

 

The following clarifications should be noted:

-           The aim of any security measures will be to reduce the risks. Testing should support justification for the security measures implemented

 

 

Examples of documents/evidence that could be provided

The following standards may be applicable:

-           Manufacturers may describe the verification and validation measure implemented in accordance with ISO/SAE 21434 in form of [WP-09-08] Verification report of cybersecurity concept, [ WP- 10-03] Verification report for the refined cybersecurity specification, [WP -11-02] Validation report.

 

The following could be used to evidence this requirement:

-           What is tested and why (e.g. what measures of success for the test look like)

-           Methodology used and why (e.g. this may include notes on the extent and effort contained within the testing)

-           Who has performed the tests and why (e.g. in-house, a supplier or an external organization and any relevant information regarding their qualification/experience)

-           Confirmation of its successful outcome (pass/fail criteria of the test)

 

 

 

7.3.7. The vehicle manufacturer shall implement measures for the vehicle type to:

(a) detect and prevent cyber-attacks against vehicles of the vehicle type;

(b) support the monitoring capability of the vehicle manufacturer with regards to detecting threats, vulnerabilities and cyber-attacks relevant to the vehicle type;

(c) provide data forensic capability to enable analysis of attempted or successful cyber-attacks.

 

Explanation of the requirement

The intention of this requirement is to ensure that the outline of the technology mounted on a vehicle in response to a cyber attack on the vehicle will be described.

 

(a): Attack prevention measures for vehicles are applied.

(b): The results of defense by vehicle manufacturer's preventive measures and monitoring results are recorded.

(c): The vehicle manufacturer should be able to read the recorded results and use them for analysis.

In any case, the outline of the technology shall be explained. [DH52]

 

 

ISO/SAE 21434 is considering the monitoring in [WP-07-01] List of sources for cybersecurity monitoring] , the analysis is documented in  8WP-07-04] Vulnerability analysis.

Any [KFZ-J53] measure with regard to this clause may be implemented on the vehicle type or in its environment, e.g. the backend, the mobile network : “for the vehicle type” .

Measures to prevent cyber-attacks may be delivered asynchronously, i.e. after the actual event of the cyber-attack and its analysis and in form of a ( delayed ) response . Th is clause neither require s to analyse or   respond “ in real - time” n or “in wire - speed” nor “automated” .

The d ata f orensic capability may deliver data from a restricted time frame of observation.

 

 

Examples of documents/evidence that could be provided

Data forensic capability may deliver log data, diagnostic error codes.

-           Data forensic capability may be a circular buffer of persisting log data. [DH54]

 

 

 

7.3.8. Cryptographic modules used for the purpose of this Regulation shall be in line with consensus standards. If the cryptographic modules used are not in line with consensus standards, then the vehicle manufacturer shall justify their use.

 

Explanation of the requirement

The intent of this requirement is to ensure:

Regarding the points where encryption measures are taken based on the results of risk analysis and risk assessment,

(1) explain whether it complies with the consensus standard, and

(2) if it does not, explain the rational reason. [DH55]

 

 

 

7.4. Reporting provisions

 

7.4.1. The vehicle manufacturer shall report at least once a year, or more frequently if relevant, to the Approval Authority or the Technical Service the outcome of their monitoring activities, as defined in paragraph 7.2.2.2.(g)), this shall include relevant information on new cyber-attacks. The vehicle manufacturer shall also report and confirm to the Approval Authority or the Technical Service that the cyber security mitigations implemented for their vehicle types are still effective and any additional actions taken.

 

Explanation of the requirement

The main purpose of this requirement is to confirm that the vehicle manufacturer runs CSMS related to the monitoring activities, as defined in paragraph 7.2.2.2.(g) properly after Development Phase.  The manufacturer shall at least annually report to the Type Approval Authority who granted the type approval or the Technical Service who verified the compliance of its CSMS with this Regulation. [DH56]

 

-           ISO/SAE 21434 defines [WP-07-02] Results from the triage of cybersecurity information and [WP - 07-04] Vulnerability Analysis. Both can be used as the baseline for the required reporting.

 

 

 

7.4.2 The Approval Authority or the Technical Service shall verify the provided information and, if necessary, require the vehicle manufacturer to remedy any detected ineffectiveness.

 

If the reporting or response is not sufficient the Approval Authority may decide to withdraw the CSMS in compliance with paragraph 6.8.

 

No guidance included in this document with regards this requirement

 

 

8. Modification and extension of the vehicle type

No guidance included in this document with regards this requirement [DH57]

Not included in this document as it is assumed guidance is not needed here for testing

Explanation of the requirement

 

 


 

Examples of documents [DH58] /evidence that could be provided

The following table gives some examples for modifications of E/E architectures and the potential impact on the vehicle type with regard to this regulation:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

9. Conformity of production

No guidance included in this document with regards this requirement

10. Penalties for non-conformity of production

No guidance included in this document with regards this requirement

11. Names and addresses of Technical Services responsible for conducting approval test, and of type approval authorities

No guidance included in this document with regards this requirement


Annex 1

Information document

The following information, if applicable, shall be supplied in triplicate and include a list of contents. Any drawings shall be supplied in appropriate scale and in sufficient detail on size A4 or on a folder of A4 format. Photographs, if any, shall show sufficient detail.

1. Make (trade name of manufacturer):

2. Type and general commercial description(s):

3. Means of identification of type, if marked on the vehicle:

4. Location of that marking:

5. Category(ies) of vehicle:

6. Name and address of manufacturer/ manufacturer's representative:

7. Name(s) and Address(es) of assembly plant(s):

8. Photograph(s) and/or drawing(s) of a representative vehicle:

9. Cyber Security

9.1. General construction characteristics of the vehicle type, including:

(a) The vehicle systems which are relevant to the cyber security of the vehicle type;

(b) The components of those systems that are relevant to cyber security;

(c) The interactions of those systems with other systems within the vehicle type and external interfaces.

 

Explanation of the requirement

-            

 

 

Examples of documents/evidence that could be provided

Shall be a written description of the E/E architecture

 

 

9.2. Schematic representation of the vehicle type

 

Explanation of the requirement

-            

 

Examples of documents/evidence that could be provided

Note: Shall be a schematic of the E/E architecture – e.g. circuit diagram

 

 

9.3. The number of the Certificate of Compliance for CSMS:

9.4. Documents for the vehicle type to be approved describing the outcome of its risk assessment and the identified risks:              

9.5 Documents for the vehicle type to be approved describing the mitigations that have been implemented on the systems listed, or to the vehicle type, and how they address the stated risks:              

9.6. Documents for the vehicle type to be approved describing protection of dedicated environments for aftermarket software, services, applications or data:              

9.7. Documents for the vehicle type to be approved describing what tests have been used to verify the cyber security of the vehicle type and its systems and the outcome of those tests:              

9.8. Description of the consideration of the supply chain with respect to cyber security:

 

 

Annex 2

Communication form

No guidance included in this document with regards this annex

 

Annex 3

Arrangement of approval mark

No guidance included in this document with regards this annex

Annex 4

Model of Certificate of Compliance for CSMS

No guidance included in this document with regards this annex


Annex A  

Link Result of coherence-check   [DH59] with ISO/SAE 21434 DIS (E)  

Sub-Category

Clauses from ISO/SAE 21434 D IS

7.2.1 For the assessment the Approval Authority or its Technical Service shall verify that the vehicle manufacturer has a Cyber Security Management System in place and shall verify its compliance with this Regulation.

Verify that a Cybersecurity Management System is in place

Not applicable

7.2.2.1 The vehicle manufacturer shall demonstrate to an Approval Authority or Technical Service that their Cyber Security Management System applies to the following phases:

Development phase;

Production phase;

Post-production phase.

Development phase

Clauses 9, 10,11

Production phase

Clause 12

Post-production phase

Clauses 7, 13, 14

7.2.2.2 (a) The processes used within the manufacturer’s organization to manage cyber security

Organization-wide cyber security policy

[RQ-05-01 ], [RQ-05-03]

Management of cyber security relevant processes

[RQ-05-02] , [RQ-05-09]

(a3) Establishment and Maintenance of cyber security culture and awareness

[RQ-05-07] . [RQ-05-08]

7.2.2.2 (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.

(b1) Process for identifying cyber security risks to vehicle types established across development, production, and post-production

 

[RQ-08-01] . [RQ-08-02] , [RQ-08-03], [RQ-08-08], [RQ-08-09], The threats in Annex 5 of the UNECE document, part 5 a re out of scope of ISO/SAE 21434

7.2.2.2 (c) The processes used for the assessment, categorization and treatment of the risks identified

(c1) Is a process established to assess and categorize cyber security risks for vehicle types across development, production and post-production?

[RQ-08-11] , [RQ-08-04], [RQ-08-06] , [RQ-08-10]

(c2) Is a process established to treat cyber security risks for vehicle types across development, production and post-production?

[RQ-08-12] , [RQ-09-07], [RQ-05-06], [RQ-09-08]

7.2.2.2 (d) The processes in place to verify that the risks identified are appropriately managed

(d1) Is a process established to verify appropriateness of risk management?

[RQ-09-09]

(e) The processes used for testing the cyber security of a vehicle type

(e1) Is a process established to specify cyber security requirements?

[RQ-09-10] , [RQ-10-01]

(e2) Is a process established to validate the cyber security requirements of the item during development phase?

[RQ-11-01] , [RQ-11-02]

(e3) Is a process established to validate the cyber security requirements of the item during production phase?

[RQ-12-01]

7.2.2.2 (f) The processes used for ensuring that the risk assessment is kept current

(f1) Is a process established to keep the cyber security risk assessment current?

[RQ-11-03] , [RQ-06-08], [RQ-07-05] , [RQ-07-06]

7.2.2.2 (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

(g1) Is a process established to monitor for cyber security information?

[RQ-07-01]  

(g2) Is a process established to detect cyber security events?

[RQ-07-02]

(g3) Is a process established to assess cyber security events and analyze cyber security vulnerabilities?

[RQ-07-03] , [RQ-07-04]

(g4) Is a process established to manage identified cyber security vulnerabilities?

[RQ-07-05] , [RQ-15-04], [RQ-15-05], [RC-15-03]

(g5) Is a process established to respond on cyber security incidents?

[RQ-13-01] , [RQ-13-02], [RQ-13-03]

(g6) Is a process established to validate effectiveness of the response?

[RQ-11-01], [RQ11-03] , [RQ-11-04]

(h) The processes used to provide relevant data to support analysis of attempted or successful cyber-attacks.

Is a process given to provide relevant data to sup port analysis?

[RQ-07-03]

7.2.2.3 The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management System will ensure that, based on categorization referred to in point 7.2.2.2 (c) and 7.2.2.2 (g), cyber threats and vulnerabilities which require a response from the vehicle manufacturer shall be mitigated within a reasonable timeframe.

Mitigation within reasonable timeframe

No timeframe defined by ISO/SAE 21434 DIS (E)

7.2.2.4 The vehicle manufacturer shall demonstrate that the processes used within their Cyber Security Management System will ensure that the monitoring referred to in point 7.2.2.2 (g) shall be continual. This shall:

Include vehicles after first registration in the monitoring;

Include the capability to analyse and detect cyber threats, vulnerabilities and cyber-attacks from vehicle data and vehicle logs. This capability shall respect paragraph 1.3. and the privacy rights of car owners or drivers, particularly with respect to consent.

Monitoring after first registration

Clause 7.3 Cybersecurity Monitoring”

Capability to analyse and detect cyber threats, vulnerabilities and cyber-attacks from vehicle data and vehicle logs

Not explicitly mentioned in ISO/SAE 21434 DIS (E), but could be seen as Cybersecurity Information.  

Respecting privacy rights of car owners or drivers, particularly with respect to consent

Out of scope of ISO/SAE 21434 , so n ot applicable

7.2.2.5 The vehicle manufacturer shall be required to demonstrate how their Cyber Security Management System will manage dependencies that may exist with contracted suppliers, service providers or manufacturer’s sub-organizations in regards of the requirements of paragraph 7.2.2.2.

Dependencies that may exist with contracted suppliers

[RQ-06-09], [RQ-15-03], [RC-15-02]

Dependencies that may exist with contracted service providers

[RQ-06-09], [RQ-15-03], [RC-15-02]

Dependencies that may exist with manufacturer’s sub-organizations

[RQ-06-09], [RQ-15-03], [RC-15-02]

 

 

 

 

 

 

 


  [1] E.g. ISO 26262-2018, ISO/PAS 21448, ISO/SAE 21434

[2] Guidance for the detailed information (e.g. method, criteria, performance level) to be uploaded and the format shall be given in the interpretation document which is under preparation by the TF on CS/OTA for the 7th session of GRVA.


[DH1] Needs to be updated once document is complete

[nt2] I think that the nature of the Regulation should be briefed as a starter.

[DH3] OICA proposal

[nt4] To have a coherency with “ Explanation of the requirement ” for (b) of 5.3.1

[DH5] OICA proposal

[DH6] Note: content of this document may need to be reviewed if the resolution document is withdrawn to keep any content that is appropriate for this document.

[DH7] Text added to address action ahID-11

[DH8] Suggested text from Small Drafting Group

[DH9] OICA proposal

 

[DH10] ACTION ahID-9

[DH11] OICA proposal

[DH12] OICA proposal

[DH13] ACTION ahID-9

[DH14] OICA proposal

[DH15] OICA proposal

[DH16] ACTION ahID-9

[DH17] ACTION ahID-9

[DH18] OICA proposal

[DH19] ACTION ahID-9

[DH20] ACTION ahID-9

[DH21] ACTION ahID-9

[DH22] ACTION ahID-9

[DH23] ACTION ahID-9

[DH24] ACTION ahID-9

[DH25] ACTION ahID-9

[DH26] Completion of ACTION ahID-8

[DH27] ACTION ahID-9

[DH28] ACTION ahID-9

 

[DH29] ACTION ahID-9

[DH30] ACTION ahID-9

[DH31] ACTION ahID-9

[DH32] Completion of ACTION ahID-08

[DH33] ACTION: edit all references to the recommendation to be reviewed to see if they are now referred to in the regulation

[DH34] Suggested amended text

[DH35] ACTION ahID-9

[DH36] ACTION ahID-9

[DH37] ACTION ahID-9

[DH38] ACTION ahID-9

[DH39] ACTION ahID-9

[DH40] ACTION ahID-9

[DH41] ACTION ahID-9

[DH42] ACTION ahID-9

[DH43] ACTION ahID-9

[DH44] ACTION ahID-9

[DH45] ACTION ahID-9

[DH46] ACTION ahID-9

[DH47] ACTION ahID-9

[DH48] Updated suggestion from JPN

[DH49] JPN suggestion to use just this text

[DH50] May not be necessary as repeats lines above

Awaiting formal response from JPN before deleting

[DH51] Chair: updated text

[DH52] JPN suggestion to use just this text

[KFZ-J53] Comments from OICA

[DH54] OICA proposal

[DH55] JPN suggestion to use just this text

[DH56] JPN suggestion

[DH57] OICA suggestion for adding diagram

[DH58] OICA suggested addition following ahID meeting

[DH59] OICA proposal