@ansvar/eu-regulations-mcp 0.1.0 → 0.2.1

package/data/seed/un-r155.json

@@ -0,0 +1,166 @@
+{
+  "id": "UN_R155",
+  "full_name": "UN Regulation No. 155 - Cyber security and cyber security management system",
+  "celex_id": "42021X0387",
+  "effective_date": "2021-01-22",
+  "eur_lex_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:42021X0387",
+  "articles": [
+    {
+      "number": "1",
+      "title": "Scope",
+      "text": "1.1.\n\n1.1.\n\nThis Regulation applies to vehicles, with regard to cybersecurity, of the Categories M and N.\n                     This Regulation also applies to vehicles of Category O if fitted with at least one electronic control unit.\n\nThis Regulation applies to vehicles, with regard to cybersecurity, of the Categories M and N.\n\nThis Regulation also applies to vehicles of Category O if fitted with at least one electronic control unit.\n\n1.2.\n\n1.2.\n\nThis Regulation also applies to vehicles of the Categories L6 and L7 if equipped with automated driving functionalities from level 3 onwards, as defined in the ‘Reference document with definitions of Automated Driving under WP.29 and the General Principles for developing a UN Regulation on automated vehicles’ (ECE/TRANS/WP.29/1140).\n\nThis Regulation also applies to vehicles of the Categories L6 and L7 if equipped with automated driving functionalities from level 3 onwards, as defined in the ‘Reference document with definitions of Automated Driving under WP.29 and the General Principles for developing a UN Regulation on automated vehicles’ (ECE/TRANS/WP.29/1140).\n\n1.3.\n\n1.3.\n\nThis Regulation is without prejudice to other UN Regulations, regional or national legislations governing the access by authorized parties to the vehicle, its data, functions and resources, and conditions of such access. It is also without prejudice to the application of national and regional legislation on privacy and the protection of natural persons with regard to the processing of their personal data.\n\nThis Regulation is without prejudice to other UN Regulations, regional or national legislations governing the access by authorized parties to the vehicle, its data, functions and resources, and conditions of such access. It is also without prejudice to the application of national and regional legislation on privacy and the protection of natural persons with regard to the processing of their personal data.\n\n1.4.\n\n1.4.\n\nThis Regulation is without prejudice to other UN Regulations, national or regional legislation governing the development and installation/system integration of replacement parts and components, physical and digital, with regards to cybersecurity.\n\nThis Regulation is without prejudice to other UN Regulations, national or regional legislation governing the development and installation/system integration of replacement parts and components, physical and digital, with regards to cybersecurity."
+    },
+    {
+      "number": "2",
+      "title": "Definitions",
+      "text": "For the purpose of this Regulation the following definitions shall apply:\n\n2.1.\n\n2.1.\n\n‘Vehicle type’ means vehicles which do not differ in at least the following essential respects:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The manufacturer’s designation of the vehicle type;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Essential aspects of the electric/electronic architecture and external interfaces with respect to cybersecurity.\n\n‘Vehicle type’ means vehicles which do not differ in at least the following essential respects:\n\n(a)\n\n(a)\n\nThe manufacturer’s designation of the vehicle type;\n\nThe manufacturer’s designation of the vehicle type;\n\n(b)\n\n(b)\n\nEssential aspects of the electric/electronic architecture and external interfaces with respect to cybersecurity.\n\nEssential aspects of the electric/electronic architecture and external interfaces with respect to cybersecurity.\n\n2.2.\n\n2.2.\n\n‘Cybersecurity’ means the condition in which road vehicles and their functions are protected from cyber threats to electrical or electronic components.\n\n‘Cybersecurity’ means the condition in which road vehicles and their functions are protected from cyber threats to electrical or electronic components.\n\n2.3.\n\n2.3.\n\n‘Cybersecurity Management System (CSMS)’ means a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks.\n\n‘Cybersecurity Management System (CSMS)’ means a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks.\n\n2.4.\n\n2.4.\n\n‘System’ means a set of components and/or sub-systems that implements a function or functions.\n\n‘System’ means a set of components and/or sub-systems that implements a function or functions.\n\n2.5.\n\n2.5.\n\n‘Development phase’ means the period before a vehicle type is type approved.\n\n‘Development phase’ means the period before a vehicle type is type approved.\n\n2.6.\n\n2.6.\n\n‘Production phase’ refers to the duration of production of a vehicle type.\n\n‘Production phase’ refers to the duration of production of a vehicle type.\n\n2.7.\n\n2.7.\n\n‘Post-production phase’ refers to the period in which a vehicle type is no longer produced until the end-of-life of all vehicles under the vehicle type. Vehicles incorporating a specific vehicle type will be operational during this phase but will no longer be produced. The phase ends when there are no longer any operational vehicles of a specific vehicle type.\n\n‘Post-production phase’ refers to the period in which a vehicle type is no longer produced until the end-of-life of all vehicles under the vehicle type. Vehicles incorporating a specific vehicle type will be operational during this phase but will no longer be produced. The phase ends when there are no longer any operational vehicles of a specific vehicle type.\n\n2.8.\n\n2.8.\n\n‘Mitigation’ means a measure that is reducing risk.\n\n‘Mitigation’ means a measure that is reducing risk.\n\n2.9.\n\n2.9.\n\n‘Risk’ means the potential that a given threat will exploit vulnerabilities of a vehicle and thereby cause harm to the organization or to an individual.\n\n‘Risk’ means the potential that a given threat will exploit vulnerabilities of a vehicle and thereby cause harm to the organization or to an individual.\n\n2.10.\n\n2.10.\n\n‘Risk Assessment’ means the overall process of finding, recognizing and describing risks (risk identification), to comprehend the nature of risk and to determine the level of risk (risk analysis), and of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable (risk evaluation).\n\n‘Risk Assessment’ means the overall process of finding, recognizing and describing risks (risk identification), to comprehend the nature of risk and to determine the level of risk (risk analysis), and of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable (risk evaluation).\n\n2.11.\n\n2.11.\n\n‘Risk Management’ means coordinated activities to direct and control an organization with regard to risk.\n\n‘Risk Management’ means coordinated activities to direct and control an organization with regard to risk.\n\n2.12.\n\n2.12.\n\n‘Threat’ means a potential cause of an unwanted incident, which may result in harm to a system, organization or individual.\n\n‘Threat’ means a potential cause of an unwanted incident, which may result in harm to a system, organization or individual.\n\n2.13.\n\n2.13.\n\n‘Vulnerability’ means a weakness of an asset or mitigation that can be exploited by one or more threats.\n\n‘Vulnerability’ means a weakness of an asset or mitigation that can be exploited by one or more threats."
+    },
+    {
+      "number": "3",
+      "title": "Application for approval",
+      "text": "3.1.\n\n3.1.\n\nThe application for approval of a vehicle type with regard to cybersecurity shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\nThe application for approval of a vehicle type with regard to cybersecurity shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\n3.2.\n\n3.2.\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particulars:\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particulars:\n\n3.2.1.\n\n3.2.1.\n\nA description of the vehicle type with regard to the items specified in Annex 1 to this Regulation.\n\nA description of the vehicle type with regard to the items specified in Annex 1 to this Regulation.\n\n3.2.2.\n\n3.2.2.\n\nIn cases where information is shown to be covered by intellectual property rights or to constitute specific know-how of the manufacturer or of their suppliers, the manufacturer or their suppliers shall make available sufficient information to enable the checks referred to in this Regulation to be made properly. Such information shall be treated on a confidential basis.\n\nIn cases where information is shown to be covered by intellectual property rights or to constitute specific know-how of the manufacturer or of their suppliers, the manufacturer or their suppliers shall make available sufficient information to enable the checks referred to in this Regulation to be made properly. Such information shall be treated on a confidential basis.\n\n3.2.3.\n\n3.2.3.\n\nThe Certificate of Compliance for CSMS according to paragraph 6 of this Regulation.\n\nThe Certificate of Compliance for CSMS according to paragraph 6 of this Regulation.\n\n3.3.\n\n3.3.\n\nDocumentation shall be made available in two parts:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The formal documentation package for the approval, containing the material specified in Annex 1 which shall be supplied to the Approval Authority or its Technical Service at the time of submission of the type approval application. This documentation package shall be used by the Approval Authority or its Technical Service as the basic reference for the approval process. The Approval Authority or its Technical Service shall ensure that this documentation package remains available for at least 10 years counted from the time when production of the vehicle type is definitively discontinued.\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Additional material relevant to the requirements of this regulation may be retained by the manufacturer, but made open for inspection at the time of type approval. The manufacturer shall ensure that any material made open for inspection at the time of type approval remains available for at least a period of 10 years counted from the time when production of the vehicle type is definitively discontinued.\n\nDocumentation shall be made available in two parts:\n\n(a)\n\n(a)\n\nThe formal documentation package for the approval, containing the material specified in Annex 1 which shall be supplied to the Approval Authority or its Technical Service at the time of submission of the type approval application. This documentation package shall be used by the Approval Authority or its Technical Service as the basic reference for the approval process. The Approval Authority or its Technical Service shall ensure that this documentation package remains available for at least 10 years counted from the time when production of the vehicle type is definitively discontinued.\n\nThe formal documentation package for the approval, containing the material specified in Annex 1 which shall be supplied to the Approval Authority or its Technical Service at the time of submission of the type approval application. This documentation package shall be used by the Approval Authority or its Technical Service as the basic reference for the approval process. The Approval Authority or its Technical Service shall ensure that this documentation package remains available for at least 10 years counted from the time when production of the vehicle type is definitively discontinued.\n\n(b)\n\n(b)\n\nAdditional material relevant to the requirements of this regulation may be retained by the manufacturer, but made open for inspection at the time of type approval. The manufacturer shall ensure that any material made open for inspection at the time of type approval remains available for at least a period of 10 years counted from the time when production of the vehicle type is definitively discontinued.\n\nAdditional material relevant to the requirements of this regulation may be retained by the manufacturer, but made open for inspection at the time of type approval. The manufacturer shall ensure that any material made open for inspection at the time of type approval remains available for at least a period of 10 years counted from the time when production of the vehicle type is definitively discontinued."
+    },
+    {
+      "number": "4",
+      "title": "Markings",
+      "text": "4.1.\n\n4.1.\n\nThere shall be affixed, conspicuously and in a readily accessible place specified on the approval form, to every vehicle conforming to a vehicle type approved under this Regulation an international approval mark consisting of:\n\nThere shall be affixed, conspicuously and in a readily accessible place specified on the approval form, to every vehicle conforming to a vehicle type approved under this Regulation an international approval mark consisting of:\n\n4.1.1.\n\n4.1.1.\n\nA circle surrounding the Letter ‘E’ followed by the distinguishing number of the country which has granted approval.\n\nA circle surrounding the Letter ‘E’ followed by the distinguishing number of the country which has granted approval.\n\n4.1.2.\n\n4.1.2.\n\nThe number of this Regulation, followed by the letter ‘R’, a dash and the approval number to the right of the circle described in paragraph 4.1.1 above.\n\nThe number of this Regulation, followed by the letter ‘R’, a dash and the approval number to the right of the circle described in paragraph 4.1.1 above.\n\n4.2.\n\n4.2.\n\nIf the vehicle conforms to a vehicle type approved under one or more other Regulations annexed to the Agreement in the country which has granted approval under this Regulation, the symbol prescribed in paragraph 4.1.1 above need not be repeated; in this case the Regulation and approval numbers and the additional symbols of all the Regulations under which approval has been granted in the country which has granted approval under this Regulation shall be placed in vertical columns to the right of the symbol prescribed in paragraph 4.1.1 above.\n\nIf the vehicle conforms to a vehicle type approved under one or more other Regulations annexed to the Agreement in the country which has granted approval under this Regulation, the symbol prescribed in paragraph 4.1.1 above need not be repeated; in this case the Regulation and approval numbers and the additional symbols of all the Regulations under which approval has been granted in the country which has granted approval under this Regulation shall be placed in vertical columns to the right of the symbol prescribed in paragraph 4.1.1 above.\n\n4.3.\n\n4.3.\n\nThe approval mark shall be clearly legible and shall be indelible.\n\nThe approval mark shall be clearly legible and shall be indelible.\n\n4.4.\n\n4.4.\n\nThe approval mark shall be placed on or close to the vehicle data plate affixed by the Manufacturer.\n\nThe approval mark shall be placed on or close to the vehicle data plate affixed by the Manufacturer.\n\n4.5.\n\n4.5."
+    },
+    {
+      "number": "5",
+      "title": "Approval",
+      "text": "5.1.\n\n5.1.\n\nApproval Authorities shall grant, as appropriate, type approval with regard to cybersecurity, only to such vehicle types that satisfy the requirements of this Regulation.\n\nApproval Authorities shall grant, as appropriate, type approval with regard to cybersecurity, only to such vehicle types that satisfy the requirements of this Regulation.\n\n5.1.1.\n\n5.1.1.\n\nThe Approval Authority or the Technical Service shall verify by means of document checks that the vehicle manufacturer has taken the necessary measures relevant for the vehicle type to:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 Collect and verify the information required under this Regulation through the supply chain so as to demonstrate that supplier-related risks are identified and are managed;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Document risks assessment (conducted during development phase or retrospectively), test results and mitigations applied to the vehicle type, including design information supporting the risk assessment;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 Implement appropriate cybersecurity measures in the design of the vehicle type;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (d)\n                              \n                              \n                                 Detect and respond to possible cybersecurity attacks;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (e)\n                              \n                              \n                                 Log data to support the detection of cyberattacks and provide data forensic capability to enable analysis of attempted or successful cyberattacks.\n\nThe Approval Authority or the Technical Service shall verify by means of document checks that the vehicle manufacturer has taken the necessary measures relevant for the vehicle type to:\n\n(a)\n\n(a)\n\nCollect and verify the information required under this Regulation through the supply chain so as to demonstrate that supplier-related risks are identified and are managed;\n\nCollect and verify the information required under this Regulation through the supply chain so as to demonstrate that supplier-related risks are identified and are managed;\n\n(b)\n\n(b)\n\nDocument risks assessment (conducted during development phase or retrospectively), test results and mitigations applied to the vehicle type, including design information supporting the risk assessment;\n\nDocument risks assessment (conducted during development phase or retrospectively), test results and mitigations applied to the vehicle type, including design information supporting the risk assessment;\n\n(c)\n\n(c)\n\nImplement appropriate cybersecurity measures in the design of the vehicle type;\n\nImplement appropriate cybersecurity measures in the design of the vehicle type;\n\n(d)\n\n(d)\n\nDetect and respond to possible cybersecurity attacks;\n\nDetect and respond to possible cybersecurity attacks;\n\n(e)\n\n(e)\n\nLog data to support the detection of cyberattacks and provide data forensic capability to enable analysis of attempted or successful cyberattacks.\n\nLog data to support the detection of cyberattacks and provide data forensic capability to enable analysis of attempted or successful cyberattacks.\n\n5.1.2.\n\n5.1.2.\n\nThe Approval Authority or the Technical Service shall verify by testing of a vehicle of the vehicle type that the vehicle manufacturer has implemented the cybersecurity measures they have documented. Tests shall be performed by the Approval Authority or the Technical Service itself or in collaboration with the vehicle manufacturer by sampling. Sampling shall be focused but not limited to risks that are assessed as high during the risk assessment.\n\nThe Approval Authority or the Technical Service shall verify by testing of a vehicle of the vehicle type that the vehicle manufacturer has implemented the cybersecurity measures they have documented. Tests shall be performed by the Approval Authority or the Technical Service itself or in collaboration with the vehicle manufacturer by sampling. Sampling shall be focused but not limited to risks that are assessed as high during the risk assessment.\n\n5.1.3.\n\n5.1.3.\n\nThe Approval Authority or Technical Service shall refuse to grant the type approval with regard to cybersecurity where the vehicle manufacturer has not fulfilled one or more of the requirements referred to in paragraph 7.3, notably:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The vehicle manufacturer did not perform the exhaustive risk assessment referred to in paragraph 7.3.3; including where the manufacturer did not consider all the risks related to threats referred to in Annex 5, Part A;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 The vehicle manufacturer did not protect the vehicle type against risks identified in the vehicle manufacturer’s risk assessment or proportionate mitigations were not implemented as required by paragraph 7;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 The vehicle manufacturer did not 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;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (d)\n                              \n                              \n                                 The vehicle manufacturer did not perform, prior to the approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented.\n\nThe Approval Authority or Technical Service shall refuse to grant the type approval with regard to cybersecurity where the vehicle manufacturer has not fulfilled one or more of the requirements referred to in paragraph 7.3, notably:\n\n(a)\n\n(a)\n\nThe vehicle manufacturer did not perform the exhaustive risk assessment referred to in paragraph 7.3.3; including where the manufacturer did not consider all the risks related to threats referred to in Annex 5, Part A;\n\nThe vehicle manufacturer did not perform the exhaustive risk assessment referred to in paragraph 7.3.3; including where the manufacturer did not consider all the risks related to threats referred to in Annex 5, Part A;\n\n(b)\n\n(b)\n\nThe vehicle manufacturer did not protect the vehicle type against risks identified in the vehicle manufacturer’s risk assessment or proportionate mitigations were not implemented as required by paragraph 7;\n\nThe vehicle manufacturer did not protect the vehicle type against risks identified in the vehicle manufacturer’s risk assessment or proportionate mitigations were not implemented as required by paragraph 7;\n\n(c)\n\n(c)\n\nThe vehicle manufacturer did not 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;\n\nThe vehicle manufacturer did not 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;\n\n(d)\n\n(d)\n\nThe vehicle manufacturer did not perform, prior to the approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented.\n\nThe vehicle manufacturer did not perform, prior to the approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented.\n\n5.1.4.\n\n5.1.4.\n\nThe assessing Approval Authority shall also refuse to grant the type approval with regard to cybersecurity where the Approval Authority or Technical Service has not received sufficient information from the vehicle manufacturer to assess the cybersecurity of the vehicle type.\n\nThe assessing Approval Authority shall also refuse to grant the type approval with regard to cybersecurity where the Approval Authority or Technical Service has not received sufficient information from the vehicle manufacturer to assess the cybersecurity of the vehicle type.\n\n5.2.\n\n5.2.\n\nNotice of approval or of extension or refusal of approval of a vehicle type pursuant to this Regulation shall be communicated to the Parties to the 1958 Agreement which apply this Regulation, by means of a form conforming to the model in Annex 2 to this Regulation.\n\nNotice of approval or of extension or refusal of approval of a vehicle type pursuant to this Regulation shall be communicated to the Parties to the 1958 Agreement which apply this Regulation, by means of a form conforming to the model in Annex 2 to this Regulation.\n\n5.3.\n\n5.3.\n\nApproval Authorities shall not grant any type approval without verifying that the manufacturer has put in place satisfactory arrangements and procedures to manage properly the cybersecurity aspects as covered by this Regulation.\n\nApproval Authorities shall not grant any type approval without verifying that the manufacturer has put in place satisfactory arrangements and procedures to manage properly the cybersecurity aspects as covered by this Regulation.\n\n5.3.1.\n\n5.3.1.\n\nThe 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:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 Competent personnel with appropriate cybersecurity skills and specific automotive risk assessments knowledge (1);\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Implemented procedures for the uniform evaluation according to this Regulation.\n\nThe 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:\n\n(a)\n\n(a)\n\nCompetent personnel with appropriate cybersecurity skills and specific automotive risk assessments knowledge (1);\n\nCompetent personnel with appropriate cybersecurity skills and specific automotive risk assessments knowledge (1);\n\n(b)\n\n(b)\n\nImplemented procedures for the uniform evaluation according to this Regulation.\n\nImplemented procedures for the uniform evaluation according to this Regulation.\n\n5.3.2.\n\n5.3.2.\n\nEach Contracting Party applying this Regulation shall notify and inform by its Approval Authority other Approval Authorities of the Contracting Parties applying this UN Regulation 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.\n                     This information shall be shared (a) only before granting an approval according to this Regulation for the first time; and (b) each time the method or criteria for assessment is updated.\n                     This information is intended to be shared for the purposes of collection and analysis of the best practices and in view of ensuring the convergent application of this Regulation by all Approval Authorities applying this Regulation.\n\nEach Contracting Party applying this Regulation shall notify and inform by its Approval Authority other Approval Authorities of the Contracting Parties applying this UN Regulation 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.\n\nThis information shall be shared (a) only before granting an approval according to this Regulation for the first time; and (b) each time the method or criteria for assessment is updated.\n\nThis information is intended to be shared for the purposes of collection and analysis of the best practices and in view of ensuring the convergent application of this Regulation by all Approval Authorities applying this Regulation.\n\n5.3.3.\n\n5.3.3.\n\nThe information referred to in paragraph 5.3.2 shall be uploaded in English language to the secure internet database ‘DETA’ (2), established by the United Nations Economic Commission for Europe, 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 (3).\n\nThe information referred to in paragraph 5.3.2 shall be uploaded in English language to the secure internet database ‘DETA’ (2), established by the United Nations Economic Commission for Europe, 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 (3).\n\n5.3.4.\n\n5.3.4.\n\nApproval 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.\n\nApproval 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.\n\n5.3.5.\n\n5.3.5.\n\nIf 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 (4) 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 (5). That common interpretation shall be implemented and all Approval Authorities shall issue type approvals under this Regulation accordingly.\n\nIf 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 (4) 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 (5). That common interpretation shall be implemented and all Approval Authorities shall issue type approvals under this Regulation accordingly.\n\n5.3.6.\n\n5.3.6.\n\nEach 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 (6).\n\nEach 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 (6).\n\n5.3.7.\n\n5.3.7.\n\nThe 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.\n\nThe 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.\n\n5.4.\n\n5.4.\n\nFor the purpose of paragraph 7.2 of this Regulation, the manufacturer shall ensure that the cybersecurity aspects covered by this Regulation are implemented.\n\nFor the purpose of paragraph 7.2 of this Regulation, the manufacturer shall ensure that the cybersecurity aspects covered by this Regulation are implemented."
+    },
+    {
+      "number": "6",
+      "title": "Certificate of Compliance for Cybersecurity Management System",
+      "text": "6.1.\n\n6.1.\n\nContracting Parties shall appoint an Approval Authority to carry out the assessment of the manufacturer and to issue a Certificate of Compliance for CSMS.\n\nContracting Parties shall appoint an Approval Authority to carry out the assessment of the manufacturer and to issue a Certificate of Compliance for CSMS.\n\n6.2.\n\n6.2.\n\nAn application for a Certificate of Compliance for Cybersecurity Management System shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\nAn application for a Certificate of Compliance for Cybersecurity Management System shall be submitted by the vehicle manufacturer or by their duly accredited representative.\n\n6.3.\n\n6.3.\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particular:\n\nIt shall be accompanied by the undermentioned documents in triplicate, and by the following particular:\n\n6.3.1.\n\n6.3.1.\n\nDocuments describing the Cybersecurity Management System.\n\nDocuments describing the Cybersecurity Management System.\n\n6.3.2.\n\n6.3.2.\n\nA signed declaration using the model as defined in Appendix 1 to Annex 1.\n\nA signed declaration using the model as defined in Appendix 1 to Annex 1.\n\n6.4.\n\n6.4.\n\nIn the context of the assessment, the manufacturer shall declare using the model as defined in Appendix 1 to Annex 1 and demonstrate to the satisfaction of the Approval Authority or its Technical Service that they have the necessary processes to comply with all the requirements for cybersecurity according to this Regulation.\n\nIn the context of the assessment, the manufacturer shall declare using the model as defined in Appendix 1 to Annex 1 and demonstrate to the satisfaction of the Approval Authority or its Technical Service that they have the necessary processes to comply with all the requirements for cybersecurity according to this Regulation.\n\n6.5.\n\n6.5.\n\nWhen this assessment has been satisfactorily completed and in receipt of a signed declaration from the manufacturer according to the model as defined in Appendix 1 to Annex 1, a certificate named Certificate of Compliance for CSMS as described in Annex 4 to this Regulation (hereinafter the Certificate of Compliance for CSMS) shall be granted to the manufacturer.\n\nWhen this assessment has been satisfactorily completed and in receipt of a signed declaration from the manufacturer according to the model as defined in Appendix 1 to Annex 1, a certificate named Certificate of Compliance for CSMS as described in Annex 4 to this Regulation (hereinafter the Certificate of Compliance for CSMS) shall be granted to the manufacturer.\n\n6.6.\n\n6.6.\n\nThe Approval Authority or its Technical Service shall use the model set out in Annex 4 to this Regulation for the Certificate of Compliance for CSMS.\n\nThe Approval Authority or its Technical Service shall use the model set out in Annex 4 to this Regulation for the Certificate of Compliance for CSMS.\n\n6.7.\n\n6.7.\n\nThe Certificate of Compliance for CSMS shall remain valid for a maximum of three years from the date of deliverance of the certificate unless it is withdrawn.\n\nThe Certificate of Compliance for CSMS shall remain valid for a maximum of three years from the date of deliverance of the certificate unless it is withdrawn.\n\n6.8.\n\n6.8.\n\nThe Approval Authority which has granted the Certificate of Compliance for CSMS may at any time verify that the requirements for it continue to be met. The Approval Authority shall withdraw the Certificate of Compliance for CSMS if the requirements laid down in this Regulation are no longer met.\n\nThe Approval Authority which has granted the Certificate of Compliance for CSMS may at any time verify that the requirements for it continue to be met. The Approval Authority shall withdraw the Certificate of Compliance for CSMS if the requirements laid down in this Regulation are no longer met.\n\n6.9.\n\n6.9.\n\nThe manufacturer shall inform the Approval Authority or its Technical Service of any change that will affect the relevance of the Certificate of Compliance for CSMS. After consultation with the manufacturer, the Approval Authority or its Technical Service shall decide whether new checks are necessary.\n\nThe manufacturer shall inform the Approval Authority or its Technical Service of any change that will affect the relevance of the Certificate of Compliance for CSMS. After consultation with the manufacturer, the Approval Authority or its Technical Service shall decide whether new checks are necessary.\n\n6.10.\n\n6.10.\n\nIn due time, permitting the Approval Authority to complete its assessment before the end of the period of validity of the Certificate of Compliance for CSMS, the manufacturer shall apply for a new or for the extension of the existing Certificate of Compliance for CSMS. The Approval Authority shall, subject to a positive assessment, issue a new Certificate of Compliance for CSMS or extend its validity for a further period of three years. The Approval Authority shall verify that the CSMS continue to comply with the requirements of this Regulation. The Approval Authority shall issue a new certificate in cases where changes have been brought to the attention of the Approval Authority or its Technical Service and the changes have been positively re-assessed.\n\nIn due time, permitting the Approval Authority to complete its assessment before the end of the period of validity of the Certificate of Compliance for CSMS, the manufacturer shall apply for a new or for the extension of the existing Certificate of Compliance for CSMS. The Approval Authority shall, subject to a positive assessment, issue a new Certificate of Compliance for CSMS or extend its validity for a further period of three years. The Approval Authority shall verify that the CSMS continue to comply with the requirements of this Regulation. The Approval Authority shall issue a new certificate in cases where changes have been brought to the attention of the Approval Authority or its Technical Service and the changes have been positively re-assessed.\n\n6.11.\n\n6.11.\n\nThe expiry or withdrawal of the manufacturer’s Certificate of Compliance for CSMS shall be considered, with regard to the vehicle types to which the CSMS concerned was relevant, as modification of approval, as referred to in paragraph 8, which may include the withdrawal of the approval if the conditions for granting the approval are not met anymore.\n\nThe expiry or withdrawal of the manufacturer’s Certificate of Compliance for CSMS shall be considered, with regard to the vehicle types to which the CSMS concerned was relevant, as modification of approval, as referred to in paragraph 8, which may include the withdrawal of the approval if the conditions for granting the approval are not met anymore."
+    },
+    {
+      "number": "7",
+      "title": "Specifications",
+      "text": "7.1.\n\n7.1.\n\nGeneral specifications\n\nGeneral specifications\n\n7.1.1.\n\n7.1.1.\n\nThe requirements of this Regulation shall not restrict provisions or requirements of other UN Regulations.\n\nThe requirements of this Regulation shall not restrict provisions or requirements of other UN Regulations.\n\n7.2.\n\n7.2.\n\nRequirements for the Cybersecurity Management System\n\nRequirements for the Cybersecurity Management System\n\n7.2.1.\n\n7.2.1.\n\nFor the assessment the Approval Authority or its Technical Service shall verify that the vehicle manufacturer has a Cybersecurity Management System in place and shall verify its compliance with this Regulation.\n\nFor the assessment the Approval Authority or its Technical Service shall verify that the vehicle manufacturer has a Cybersecurity Management System in place and shall verify its compliance with this Regulation.\n\n7.2.2.\n\n7.2.2.\n\nThe Cybersecurity Management System shall cover the following aspects:\n\nThe Cybersecurity Management System shall cover the following aspects:\n\n7.2.2.1.\n\n7.2.2.1.\n\nThe vehicle manufacturer shall demonstrate to an Approval Authority or Technical Service that their Cybersecurity Management System applies to the following phases:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 Development phase;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Production phase;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 Post-production phase.\n\nThe vehicle manufacturer shall demonstrate to an Approval Authority or Technical Service that their Cybersecurity Management System applies to the following phases:\n\n(a)\n\n(a)\n\nDevelopment phase;\n\nDevelopment phase;\n\n(b)\n\n(b)\n\nProduction phase;\n\nProduction phase;\n\n(c)\n\n(c)\n\nPost-production phase.\n\nPost-production phase.\n\n7.2.2.2.\n\n7.2.2.2.\n\nThe vehicle manufacturer shall demonstrate that the processes used within their Cybersecurity Management System ensure security is adequately considered, including risks and mitigations listed in Annex 5. This shall include:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 The processes used within the manufacturer’s organization to manage cybersecurity;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 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;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 The processes used for the assessment, categorization and treatment of the risks identified;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (d)\n                              \n                              \n                                 The processes in place to verify that the risks identified are appropriately managed;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (e)\n                              \n                              \n                                 The processes used for testing the cybersecurity of a vehicle type;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (f)\n                              \n                              \n                                 The processes used for ensuring that the risk assessment is kept current;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (g)\n                              \n                              \n                                 The processes used to monitor for, detect and respond to cyberattacks, cyber threats and vulnerabilities on vehicle types and the processes used to assess whether the cybersecurity measures implemented are still effective in the light of new cyber threats and vulnerabilities that have been identified.\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (h)\n                              \n                              \n                                 The processes used to provide relevant data to support analysis of attempted or successful cyberattacks.\n\nThe vehicle manufacturer shall demonstrate that the processes used within their Cybersecurity Management System ensure security is adequately considered, including risks and mitigations listed in Annex 5. This shall include:\n\n(a)\n\n(a)\n\nThe processes used within the manufacturer’s organization to manage cybersecurity;\n\nThe processes used within the manufacturer’s organization to manage cybersecurity;\n\n(b)\n\n(b)\n\nThe 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;\n\nThe 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;\n\n(c)\n\n(c)\n\nThe processes used for the assessment, categorization and treatment of the risks identified;\n\nThe processes used for the assessment, categorization and treatment of the risks identified;\n\n(d)\n\n(d)\n\nThe processes in place to verify that the risks identified are appropriately managed;\n\nThe processes in place to verify that the risks identified are appropriately managed;\n\n(e)\n\n(e)\n\nThe processes used for testing the cybersecurity of a vehicle type;\n\nThe processes used for testing the cybersecurity of a vehicle type;\n\n(f)\n\n(f)\n\nThe processes used for ensuring that the risk assessment is kept current;\n\nThe processes used for ensuring that the risk assessment is kept current;\n\n(g)\n\n(g)\n\nThe processes used to monitor for, detect and respond to cyberattacks, cyber threats and vulnerabilities on vehicle types and the processes used to assess whether the cybersecurity measures implemented are still effective in the light of new cyber threats and vulnerabilities that have been identified.\n\nThe processes used to monitor for, detect and respond to cyberattacks, cyber threats and vulnerabilities on vehicle types and the processes used to assess whether the cybersecurity measures implemented are still effective in the light of new cyber threats and vulnerabilities that have been identified.\n\n(h)\n\n(h)\n\nThe processes used to provide relevant data to support analysis of attempted or successful cyberattacks.\n\nThe processes used to provide relevant data to support analysis of attempted or successful cyberattacks.\n\n7.2.2.3.\n\n7.2.2.3.\n\nThe vehicle manufacturer shall demonstrate that the processes used within their Cybersecurity 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.\n\nThe vehicle manufacturer shall demonstrate that the processes used within their Cybersecurity 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.\n\n7.2.2.4.\n\n7.2.2.4.\n\nThe vehicle manufacturer shall demonstrate that the processes used within their Cybersecurity Management System will ensure that the monitoring referred to in paragraph 7.2.2.2(g) shall be continual. This shall:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 Include vehicles after first registration in the monitoring;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Include the capability to analyse and detect cyber threats, vulnerabilities and cyberattacks 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.\n\nThe vehicle manufacturer shall demonstrate that the processes used within their Cybersecurity Management System will ensure that the monitoring referred to in paragraph 7.2.2.2(g) shall be continual. This shall:\n\n(a)\n\n(a)\n\nInclude vehicles after first registration in the monitoring;\n\nInclude vehicles after first registration in the monitoring;\n\n(b)\n\n(b)\n\nInclude the capability to analyse and detect cyber threats, vulnerabilities and cyberattacks 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.\n\nInclude the capability to analyse and detect cyber threats, vulnerabilities and cyberattacks 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.\n\n7.2.2.5.\n\n7.2.2.5.\n\nThe vehicle manufacturer shall be required to demonstrate how their Cybersecurity 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.\n\nThe vehicle manufacturer shall be required to demonstrate how their Cybersecurity 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.\n\n7.3.\n\n7.3.\n\nRequirements for vehicle types\n\nRequirements for vehicle types\n\n7.3.1.\n\n7.3.1.\n\nThe manufacturer shall have a valid Certificate of Compliance for the Cybersecurity Management System relevant to the vehicle type being approved.\n                     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 cybersecurity was adequately considered during the development phase of the vehicle type concerned.\n\nThe manufacturer shall have a valid Certificate of Compliance for the Cybersecurity Management System relevant to the vehicle type being approved.\n\nHowever, 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 cybersecurity was adequately considered during the development phase of the vehicle type concerned.\n\n7.3.2.\n\n7.3.2.\n\nThe vehicle manufacturer shall identify and manage, for the vehicle type being approved, supplier-related risks.\n\nThe vehicle manufacturer shall identify and manage, for the vehicle type being approved, supplier-related risks.\n\n7.3.3.\n\n7.3.3.\n\nThe 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.\n\nThe 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.\n\n7.3.4.\n\n7.3.4.\n\nThe 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.\n                     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.\n\nThe 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.\n\nIn 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.\n\n7.3.5.\n\n7.3.5.\n\nThe 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.\n\nThe 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.\n\n7.3.6.\n\n7.3.6.\n\nThe vehicle manufacturer shall perform, prior to type approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented.\n\nThe vehicle manufacturer shall perform, prior to type approval, appropriate and sufficient testing to verify the effectiveness of the security measures implemented.\n\n7.3.7.\n\n7.3.7.\n\nThe vehicle manufacturer shall implement measures for the vehicle type to:\n                     \n                        \n                        \n                        \n                           \n                              \n                                 (a)\n                              \n                              \n                                 Detect and prevent cyberattacks against vehicles of the vehicle type;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (b)\n                              \n                              \n                                 Support the monitoring capability of the vehicle manufacturer with regards to detecting threats, vulnerabilities and cyberattacks relevant to the vehicle type;\n                              \n                           \n                        \n                     \n                     \n                        \n                        \n                        \n                           \n                              \n                                 (c)\n                              \n                              \n                                 Provide data forensic capability to enable analysis of attempted or successful cyberattacks.\n\nThe vehicle manufacturer shall implement measures for the vehicle type to:\n\n(a)\n\n(a)\n\nDetect and prevent cyberattacks against vehicles of the vehicle type;\n\nDetect and prevent cyberattacks against vehicles of the vehicle type;\n\n(b)\n\n(b)\n\nSupport the monitoring capability of the vehicle manufacturer with regards to detecting threats, vulnerabilities and cyberattacks relevant to the vehicle type;\n\nSupport the monitoring capability of the vehicle manufacturer with regards to detecting threats, vulnerabilities and cyberattacks relevant to the vehicle type;\n\n(c)\n\n(c)\n\nProvide data forensic capability to enable analysis of attempted or successful cyberattacks.\n\nProvide data forensic capability to enable analysis of attempted or successful cyberattacks.\n\n7.3.8.\n\n7.3.8.\n\nCryptographic 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.\n\nCryptographic 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.\n\n7.4.\n\n7.4.\n\nReporting provisions\n\nReporting provisions\n\n7.4.1.\n\n7.4.1.\n\nThe 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 cyberattacks. The vehicle manufacturer shall also report and confirm to the Approval Authority or the Technical Service that the cybersecurity mitigations implemented for their vehicle types are still effective and any additional actions taken.\n\nThe 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 cyberattacks. The vehicle manufacturer shall also report and confirm to the Approval Authority or the Technical Service that the cybersecurity mitigations implemented for their vehicle types are still effective and any additional actions taken.\n\n7.4.2.\n\n7.4.2.\n\nThe Approval Authority or the Technical Service shall verify the provided information and, if necessary, require the vehicle manufacturer to remedy any detected ineffectiveness.\n                     If the reporting or response is not sufficient the Approval Authority may decide to withdraw the CSMS in compliance with paragraph 6.8.\n\nThe Approval Authority or the Technical Service shall verify the provided information and, if necessary, require the vehicle manufacturer to remedy any detected ineffectiveness.\n\nIf the reporting or response is not sufficient the Approval Authority may decide to withdraw the CSMS in compliance with paragraph 6.8."
+    },
+    {
+      "number": "8",
+      "title": "Modification of vehicle type and extension of type approval",
+      "text": "8.1.\n\n8.1.\n\nEvery modification of the vehicle type which affects its technical performance with respect to cybersecurity and/or documentation required in this Regulation shall be notified to the approval authority which approved the vehicle type. The Approval Authority may then either:\n\nEvery modification of the vehicle type which affects its technical performance with respect to cybersecurity and/or documentation required in this Regulation shall be notified to the approval authority which approved the vehicle type. The Approval Authority may then either:\n\n8.1.1.\n\n8.1.1.\n\nConsider that the modifications made still comply with the requirements and documentation of existing type approval; or\n\nConsider that the modifications made still comply with the requirements and documentation of existing type approval; or\n\n8.1.2.\n\n8.1.2.\n\nProceed to necessary complementary assessment pursuant to paragraph 5, and require, where relevant, a further test report from the Technical Service responsible for conducting the tests.\n\nProceed to necessary complementary assessment pursuant to paragraph 5, and require, where relevant, a further test report from the Technical Service responsible for conducting the tests.\n\n8.1.3.\n\n8.1.3.\n\nConfirmation or extension or refusal of approval, specifying the alterations, shall be communicated by means of a communication form conforming to the model in Annex 2 to this Regulation. The Approval Authority issuing the extension of approval shall assign a series number for such an extension and inform there of the other Parties to the 1958 Agreement applying this Regulation by means of a communication form conforming to the model in Annex 2 to this Regulation.\n\nConfirmation or extension or refusal of approval, specifying the alterations, shall be communicated by means of a communication form conforming to the model in Annex 2 to this Regulation. The Approval Authority issuing the extension of approval shall assign a series number for such an extension and inform there of the other Parties to the 1958 Agreement applying this Regulation by means of a communication form conforming to the model in Annex 2 to this Regulation."
+    },
+    {
+      "number": "9",
+      "title": "Conformity of production",
+      "text": "9.1.\n\n9.1.\n\nThe Conformity of Production Procedures shall comply with those set out in the 1958 Agreement, Schedule 1 (E/ECE/TRANS/505/Rev.3) with the following requirements:\n\nThe Conformity of Production Procedures shall comply with those set out in the 1958 Agreement, Schedule 1 (E/ECE/TRANS/505/Rev.3) with the following requirements:\n\n9.1.1.\n\n9.1.1.\n\nThe holder of the approval shall ensure that results of the conformity of production tests are recorded and that the annexed documents remain available for a period determined in agreement with the Approval Authority or its Technical Service. This period shall not exceed 10 years counted from the time when production is definitively discontinued;\n\nThe holder of the approval shall ensure that results of the conformity of production tests are recorded and that the annexed documents remain available for a period determined in agreement with the Approval Authority or its Technical Service. This period shall not exceed 10 years counted from the time when production is definitively discontinued;\n\n9.1.2.\n\n9.1.2.\n\nThe Approval Authority which has granted type approval may at any time verify the conformity control methods applied in each production facility. The normal frequency of these verifications shall be once every three years.\n\nThe Approval Authority which has granted type approval may at any time verify the conformity control methods applied in each production facility. The normal frequency of these verifications shall be once every three years."
+    },
+    {
+      "number": "10",
+      "title": "Penalties for non-conformity of production",
+      "text": "10.1.\n\n10.1.\n\nThe approval granted in respect of a vehicle type pursuant to this Regulation may be withdrawn if the requirements laid down in this Regulation are not complied with or if sample vehicles fail to comply with the requirements of this Regulation.\n\nThe approval granted in respect of a vehicle type pursuant to this Regulation may be withdrawn if the requirements laid down in this Regulation are not complied with or if sample vehicles fail to comply with the requirements of this Regulation.\n\n10.2.\n\n10.2.\n\nIf an Approval Authority withdraws an approval it has previously granted, it shall forthwith so notify the Contracting Parties applying this Regulation, by means of a communication form conforming to the model in Annex 2 to this Regulation.\n\nIf an Approval Authority withdraws an approval it has previously granted, it shall forthwith so notify the Contracting Parties applying this Regulation, by means of a communication form conforming to the model in Annex 2 to this Regulation."
+    },
+    {
+      "number": "11",
+      "title": "Production definitively discontinued",
+      "text": "11.1.\n\n11.1.\n\nIf the holder of the approval completely ceases to manufacture a type of vehicle approved in accordance with this Regulation, he shall so inform the authority which granted the approval. Upon receiving the relevant communication that authority shall inform thereof the other Contracting Parties to the Agreement applying this Regulation by means of a copy of the approval form bearing at the end, in large letters, the signed and dated annotation ‘PRODUCTION DISCONTINUED’.\n\nIf the holder of the approval completely ceases to manufacture a type of vehicle approved in accordance with this Regulation, he shall so inform the authority which granted the approval. Upon receiving the relevant communication that authority shall inform thereof the other Contracting Parties to the Agreement applying this Regulation by means of a copy of the approval form bearing at the end, in large letters, the signed and dated annotation ‘PRODUCTION DISCONTINUED’."
+    },
+    {
+      "number": "12",
+      "title": "Names and addresses of Technical Services responsible for conducting approval tests, and of Type Approval Authorities",
+      "text": "12.1.\n\n12.1.\n\nThe Contracting Parties to the Agreement which apply this Regulation shall communicate to the United Nations Secretariat the names and addresses of the Technical Services responsible for conducting approval tests and of the Type Approval Authorities which grant approval and to which forms certifying approval or extension or refusal or withdrawal of approval, issued in other countries, are to be sent.\n\nThe Contracting Parties to the Agreement which apply this Regulation shall communicate to the United Nations Secretariat the names and addresses of the Technical Services responsible for conducting approval tests and of the Type Approval Authorities which grant approval and to which forms certifying approval or extension or refusal or withdrawal of approval, issued in other countries, are to be sent.\n\n(1)  E.g. ISO 26262-2018, ISO/PAS 21448, ISO/SAE 21434.\n\n(2)  https://www.unece.org/trans/main/wp29/datasharing.html\n\n(3)  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 Task Force on Cybersecurity and Over-the-Air issues for the seventh session of GRVA.\n\n(4)  The Working Party on Automated/Autonomous and Connected Vehicles (GRVA).\n\n(5)  This interpretation shall be reflected in the interpretation document referred to in the footnote to paragraph 5.3.3.\n\n(6)  Further information on the minimum requirements for the documentation package will be developed by GRVA during its seventh session."
+    },
+    {
+      "number": "Annex 1",
+      "title": "Information document",
+      "text": "Information document\n\nThe 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.\n\n1.\n\nMake (trade name of manufacturer): …\n\nMake (trade name of manufacturer): …\n\n2.\n\nType and general commercial description(s): …\n\nType and general commercial description(s): …\n\n3.\n\nMeans of identification of type, if marked on the vehicle: …\n\nMeans of identification of type, if marked on the vehicle: …\n\n4.\n\nLocation of that marking: …\n\nLocation of that marking: …\n\n5.\n\nCategory(ies) of vehicle: …\n\nCategory(ies) of vehicle: …\n\n6.\n\nName and address of manufacturer/manufacturer’s representative: …\n\nName and address of manufacturer/manufacturer’s representative: …\n\n7.\n\nName(s) and Address(es) of assembly plant(s): …\n\nName(s) and Address(es) of assembly plant(s): …\n\n8.\n\nPhotograph(s) and/or drawing(s) of a representative vehicle: …\n\nPhotograph(s) and/or drawing(s) of a representative vehicle: …\n\n9.\n\nCybersecurity\n\nCybersecurity\n\n9.1.\n\nGeneral construction characteristics of the vehicle type, including:\n\n(a)\n\n(a)\n\nThe vehicle systems which are relevant to the cybersecurity of the vehicle type;\n\nThe vehicle systems which are relevant to the cybersecurity of the vehicle type;\n\n(b)\n\n(b)\n\nThe components of those systems that are relevant to cybersecurity;\n\nThe components of those systems that are relevant to cybersecurity;\n\n(c)\n\n(c)\n\nThe interactions of those systems with other systems within the vehicle type and external interfaces.\n\nThe interactions of those systems with other systems within the vehicle type and external interfaces.\n\n9.2.\n\nSchematic representation of the vehicle type\n\nSchematic representation of the vehicle type\n\n9.3.\n\nThe number of the Certificate of Compliance for CSMS: …\n\nThe number of the Certificate of Compliance for CSMS: …\n\n9.4.\n\nDocuments for the vehicle type to be approved describing the outcome of its risk assessment and the identified risks: …\n\nDocuments for the vehicle type to be approved describing the outcome of its risk assessment and the identified risks: …\n\n9.5.\n\nDocuments 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: …\n\nDocuments 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: …\n\n9.6.\n\nDocuments for the vehicle type to be approved describing protection of dedicated environments for aftermarket software, services, applications or data: …\n\nDocuments for the vehicle type to be approved describing protection of dedicated environments for aftermarket software, services, applications or data: …\n\n9.7.\n\nDocuments for the vehicle type to be approved describing what tests have been used to verify the cybersecurity of the vehicle type and its systems and the outcome of those tests: …\n\nDocuments for the vehicle type to be approved describing what tests have been used to verify the cybersecurity of the vehicle type and its systems and the outcome of those tests: …\n\n9.8.\n\nDescription of the consideration of the supply chain with respect to cybersecurity: …\n\nDescription of the consideration of the supply chain with respect to cybersecurity: …",
+      "chapter": "Annexes"
+    },
+    {
+      "number": "Annex 2",
+      "title": "Communication",
+      "text": "Communication\n\n(Maximum format: A4 (210 × 297 mm))\n\n(1)\n\nIssued by:\n\nIssued by:\n\nName of administration:\n                        …\n                        …\n                        …\n\nName of administration:\n\nConcerning (2):\n\nConcerning (2):\n\nApproval granted\n                        Approval extended\n                        Approval withdrawn with effect from dd/mm/yyyy\n                        Approval refused\n                        Production definitively discontinued\n\nApproval granted\n\nApproval extended\n\nApproval withdrawn with effect from dd/mm/yyyy\n\nApproval refused\n\nProduction definitively discontinued\n\nof a vehicle type, pursuant to UN Regulation No 155\n\nApproval No: …\n\nExtension No: …\n\nReason for extension: …\n\n1.\n\nMake (trade name of manufacturer): …\n\nMake (trade name of manufacturer): …\n\n2.\n\nType and general commercial description(s) …\n\nType and general commercial description(s) …\n\n3.\n\nMeans of identification of type, if marked on the vehicle: …\n\nMeans of identification of type, if marked on the vehicle: …\n\n3.1.\n\nLocation of that marking: …\n\nLocation of that marking: …\n\n4.\n\nCategory(ies) of vehicle: …\n\nCategory(ies) of vehicle: …\n\n5.\n\nName and address of manufacturer / manufacturer’s representative: …\n\nName and address of manufacturer / manufacturer’s representative: …\n\n6.\n\nName(s) and Address(es) of the production plant(s) …\n\nName(s) and Address(es) of the production plant(s) …\n\n7.\n\nNumber of the certificate of compliance for cybersecurity management system: …\n\nNumber of the certificate of compliance for cybersecurity management system: …\n\n8.\n\nTechnical Service responsible for carrying out the tests: …\n\nTechnical Service responsible for carrying out the tests: …\n\n9.\n\nDate of test report: …\n\nDate of test report: …\n\n10.\n\nNumber of test report: …\n\nNumber of test report: …\n\n11.\n\nRemarks: (if any). …\n\nRemarks: (if any). …\n\n12.\n\nPlace: …\n\nPlace: …\n\n13.\n\nDate: …\n\nDate: …\n\n14.\n\nSignature: …\n\nSignature: …\n\n15.\n\nThe index to the information package lodged with the Approval Authority, which may be obtained on request is attached:\n\nThe index to the information package lodged with the Approval Authority, which may be obtained on request is attached:\n\n(1)  Distinguishing number of the country which has granted/extended/refused/withdrawn approval (see approval provisions in the Regulation).\n\n(2)  Strike out what does not apply.",
+      "chapter": "Annexes"
+    },
+    {
+      "number": "Annex 3",
+      "title": "Arrangements of the approval mark",
+      "text": "Arrangement of approval mark\n\nMODEL A\n\n(See paragraph 4.2 of this Regulation)\n\na = 8 mm min.\n\nThe above approval mark affixed to a vehicle shows that the road vehicle type concerned has been approved in the Netherlands (E 4), pursuant to Regulation No 155, and under the approval number 001234. The first two digits of the approval number indicate that the approval was granted in accordance with the requirements of this Regulation in its original form (00).",
+      "chapter": "Annexes"
+    },
+    {
+      "number": "Annex 4",
+      "title": "Certificate of Compliance for CSMS",
+      "text": "Model of Certificate of Compliance for CSMS\n\nCertificate of Compliance for Cybersecurity Management System\n\nwith UN Regulation No 155\n\nCertificate Number [Reference number]\n\nReference number\n\n[……. Approval Authority]\n\nApproval Authority\n\nCertifies that\n\nManufacturer: …\n\nAddress of the manufacturer: …\n\ncomplies with the provisions of paragraph 7.2 of Regulation No 155\n\nChecks have been performed on: …\n\nby (name and address of the Approval Authority or Technical Service): …\n\nNumber of report: …\n\nThe certificate is valid until […………………………………………………Date]\n\nDate\n\nDone at […………………………………………………Place]\n\nPlace\n\nOn […………………………………………………Date]\n\nDate\n\n[…………………………………………………Signature]\n\nSignature\n\nAttachments: description of the Cybersecurity Management System by the manufacturer.",
+      "chapter": "Annexes"
+    },
+    {
+      "number": "Annex 5",
+      "title": "List of threats and corresponding mitigations",
+      "text": "List of threats and corresponding mitigations\n\n1.\n\nThis annex consists of three parts. Part A of this annex describes the baseline for threats, vulnerabilities and attack methods. Part B of this annex describes mitigations to the threats which are intended for vehicle types. Part C describes mitigations to the threats which are intended for areas outside of vehicles, e.g. on IT back-ends.\n\nThis annex consists of three parts. Part A of this annex describes the baseline for threats, vulnerabilities and attack methods. Part B of this annex describes mitigations to the threats which are intended for vehicle types. Part C describes mitigations to the threats which are intended for areas outside of vehicles, e.g. on IT back-ends.\n\n2.\n\nPart A, Part B, and Part C shall be considered for risk assessment and mitigations to be implemented by vehicle manufacturers.\n\nPart A, Part B, and Part C shall be considered for risk assessment and mitigations to be implemented by vehicle manufacturers.\n\n3.\n\nThe high-level vulnerability and its corresponding examples have been indexed in Part A. The same indexing has been referenced in the tables in Parts B and C to link each of the attack/vulnerability with a list of corresponding mitigation measures.\n\nThe high-level vulnerability and its corresponding examples have been indexed in Part A. The same indexing has been referenced in the tables in Parts B and C to link each of the attack/vulnerability with a list of corresponding mitigation measures.\n\n4.\n\nThe threat analysis shall also consider possible attack impacts. These may help ascertain the severity of a risk and identify additional risks. Possible attack impacts may include:\n\n(a)\n\n(a)\n\nSafe operation of vehicle affected;\n\nSafe operation of vehicle affected;\n\n(b)\n\n(b)\n\nVehicle functions stop working;\n\nVehicle functions stop working;\n\n(c)\n\n(c)\n\nSoftware modified, performance altered;\n\nSoftware modified, performance altered;\n\n(d)\n\n(d)\n\nSoftware altered but no operational effects;\n\nSoftware altered but no operational effects;\n\n(e)\n\n(e)\n\nData integrity breach;\n\nData integrity breach;\n\n(f)\n\n(f)\n\nData confidentiality breach;\n\nData confidentiality breach;\n\n(g)\n\n(g)\n\nLoss of data availability;\n\nLoss of data availability;\n\n(h)\n\n(h)\n\nOther, including criminality.\n\nOther, including criminality.\n\nPart A. Vulnerability or attack method related to the threats\n\n1.\n\n1.\n\nHigh-level descriptions of threats and relating vulnerability or attack method are listed in Table A1.\n                        \n                           Table A1\n                        \n                        \n                           List of vulnerability or attack method related to the threats\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    High-level and sub-level descriptions of vulnerability/ threat\n                                 \n                                 \n                                    Example of vulnerability or attack method\n                                 \n                              \n                              \n                                 \n                                    \n                                       \n                                       \n                                       \n                                          \n                                             \n                                                4.3.1.\n                                             \n                                             \n                                                Threats regarding back-end servers related to vehicles in the field\n                                             \n                                          \n                                       \n                                    \n                                 \n                                 \n                                    1\n                                 \n                                 \n                                    Back-end servers used as a means to attack a vehicle or extract data\n                                 \n                                 \n                                    1.1\n                                 \n                                 \n                                    Abuse of privileges by staff (insider attack)\n                                 \n                              \n                              \n                                 \n                                    1.2\n                                 \n                                 \n                                    Unauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n                                 \n                              \n                              \n                                 \n                                    1.3\n                                 \n                                 \n                                    Unauthorized physical access to the server (conducted by for example USB sticks or other media connecting to the server)\n                                 \n                              \n                              \n                                 \n                                    2\n                                 \n                                 \n                                    Services from back-end server being disrupted, affecting the operation of a vehicle\n                                 \n                                 \n                                    2.1\n                                 \n                                 \n                                    Attack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on\n                                 \n                              \n                              \n                                 \n                                    3\n                                 \n                                 \n                                    Vehicle related data held on back-end servers being lost or compromised (‘data breach’)\n                                 \n                                 \n                                    3.1\n                                 \n                                 \n                                    Abuse of privileges by staff (insider attack)\n                                 \n                              \n                              \n                                 \n                                    3.2\n                                 \n                                 \n                                    Loss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers\n                                 \n                              \n                              \n                                 \n                                    3.3\n                                 \n                                 \n                                    Unauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n                                 \n                              \n                              \n                                 \n                                    3.4\n                                 \n                                 \n                                    Unauthorized physical access to the server (conducted for example by USB sticks or other media connecting to the server)\n                                 \n                              \n                              \n                                 \n                                    3.5\n                                 \n                                 \n                                    Information breach by unintended sharing of data (e.g. admin errors)\n                                 \n                              \n                              \n                                 \n                                    \n                                       \n                                       \n                                       \n                                          \n                                             \n                                                4.3.2.\n                                             \n                                             \n                                                Threats to vehicles regarding their communication channels\n                                             \n                                          \n                                       \n                                    \n                                 \n                                 \n                                    4\n                                 \n                                 \n                                    Spoofing of messages or data received by the vehicle\n                                 \n                                 \n                                    4.1\n                                 \n                                 \n                                    Spoofing of messages by impersonation (e.g. 802.11p V2X during platooning, GNSS messages, etc.)\n                                 \n                              \n                              \n                                 \n                                    4.2\n                                 \n                                 \n                                    Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road)\n                                 \n                              \n                              \n                                 \n                                    5\n                                 \n                                 \n                                    Communication channels used to conduct unauthorized manipulation, deletion or other amendments to vehicle held code/data\n                                 \n                                 \n                                    5.1\n                                 \n                                 \n                                    Communications channels permit code injection, for example tampered software binary might be injected into the communication stream\n                                 \n                              \n                              \n                                 \n                                    5.2\n                                 \n                                 \n                                    Communications channels permit manipulate of vehicle held data/code\n                                 \n                              \n                              \n                                 \n                                    5.3\n                                 \n                                 \n                                    Communications channels permit overwrite of vehicle held data/code\n                                 \n                              \n                              \n                                 \n                                    5.4\n                                 \n                                 \n                                    Communications channels permit erasure of vehicle held data/code\n                                 \n                              \n                              \n                                 \n                                    5.5\n                                 \n                                 \n                                    Communications channels permit introduction of data/code to the vehicle (write data code)\n                                 \n                              \n                              \n                                 \n                                    6\n                                 \n                                 \n                                    Communication channels permit untrusted/unreliable messages to be accepted or are vulnerable to session hijacking/replay attacks\n                                 \n                                 \n                                    6.1\n                                 \n                                 \n                                    Accepting information from an unreliable or untrusted source\n                                 \n                              \n                              \n                                 \n                                    6.2\n                                 \n                                 \n                                    Man in the middle attack/ session hijacking\n                                 \n                              \n                              \n                                 \n                                    6.3\n                                 \n                                 \n                                    Replay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway\n                                 \n                              \n                              \n                                 \n                                    7\n                                 \n                                 \n                                    Information can be readily disclosed. For example, through eavesdropping on communications or through allowing unauthorized access to sensitive files or folders\n                                 \n                                 \n                                    7.1\n                                 \n                                 \n                                    Interception of information / interfering radiations / monitoring communications\n                                 \n                              \n                              \n                                 \n                                    7.2\n                                 \n                                 \n                                    Gaining unauthorized access to files or data\n                                 \n                              \n                              \n                                 \n                                    8\n                                 \n                                 \n                                    Denial of service attacks via communication channels to disrupt vehicle functions\n                                 \n                                 \n                                    8.1\n                                 \n                                 \n                                    Sending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner\n                                 \n                              \n                              \n                                 \n                                    8.2\n                                 \n                                 \n                                    Black hole attack, in order to disrupt communication between vehicles the attacker is able to block messages between the vehicles\n                                 \n                              \n                              \n                                 \n                                    9\n                                 \n                                 \n                                    An unprivileged user is able to gain privileged access to vehicle systems\n                                 \n                                 \n                                    9.1\n                                 \n                                 \n                                    An unprivileged user is able to gain privileged access, for example root access\n                                 \n                              \n                              \n                                 \n                                    10\n                                 \n                                 \n                                    Viruses embedded in communication media are able to infect vehicle systems\n                                 \n                                 \n                                    10.1\n                                 \n                                 \n                                    Virus embedded in communication media infects vehicle systems\n                                 \n                              \n                              \n                                 \n                                    11\n                                 \n                                 \n                                    Messages received by the vehicle (for example X2V or diagnostic messages), or transmitted within it, contain malicious content\n                                 \n                                 \n                                    11.1\n                                 \n                                 \n                                    Malicious internal (e.g. CAN) messages\n                                 \n                              \n                              \n                                 \n                                    11.2\n                                 \n                                 \n                                    Malicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)\n                                 \n                              \n                              \n                                 \n                                    11.3\n                                 \n                                 \n                                    Malicious diagnostic messages\n                                 \n                              \n                              \n                                 \n                                    11.4\n                                 \n                                 \n                                    Malicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)\n                                 \n                              \n                              \n                                 \n                                    \n                                       \n                                       \n                                       \n                                          \n                                             \n                                                4.3.3.\n                                             \n                                             \n                                                Threats to vehicles regarding their update procedures\n                                             \n                                          \n                                       \n                                    \n                                 \n                                 \n                                    12\n                                 \n                                 \n                                    Misuse or compromise of update procedures\n                                 \n                                 \n                                    12.1\n                                 \n                                 \n                                    Compromise of over the air software update procedures. This includes fabricating the system update program or firmware\n                                 \n                              \n                              \n                                 \n                                    12.2\n                                 \n                                 \n                                    Compromise of local/physical software update procedures. This includes fabricating the system update program or firmware\n                                 \n                              \n                              \n                                 \n                                    12.3\n                                 \n                                 \n                                    The software is manipulated before the update process (and is therefore corrupted), although the update process is intact\n                                 \n                              \n                              \n                                 \n                                    12.4\n                                 \n                                 \n                                    Compromise of cryptographic keys of the software provider to allow invalid update\n                                 \n                              \n                              \n                                 \n                                    13\n                                 \n                                 \n                                    It is possible to deny legitimate updates\n                                 \n                                 \n                                    13.1\n                                 \n                                 \n                                    Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features\n                                 \n                              \n                              \n                                 \n                                    \n                                       \n                                       \n                                       \n                                          \n                                             \n                                                4.3.4.\n                                             \n                                             \n                                                Threats to vehicles regarding unintended human actions facilitating a cyberattack\n                                             \n                                          \n                                       \n                                    \n                                 \n                                 \n                                    15\n                                 \n                                 \n                                    Legitimate actors are able to take actions that would unwittingly facilitate a cyberattack\n                                 \n                                 \n                                    15.1\n                                 \n                                 \n                                    Innocent victim (e.g. owner, operator or maintenance engineer) being tricked into taking an action to unintentionally load malware or enable an attack\n                                 \n                              \n                              \n                                 \n                                    15.2\n                                 \n                                 \n                                    Defined security procedures are not followed\n                                 \n                              \n                              \n                                 \n                                    \n                                       \n                                       \n                                       \n                                          \n                                             \n                                                4.3.5.\n                                             \n                                             \n                                                Threats to vehicles regarding their external connectivity and connections\n                                             \n                                          \n                                       \n                                    \n                                 \n                                 \n                                    16\n                                 \n                                 \n                                    Manipulation of the connectivity of vehicle functions enables a cyberattack, this can include telematics; systems that permit remote operations; and systems using short range wireless communications\n                                 \n                                 \n                                    16.1\n                                 \n                                 \n                                    Manipulation of functions designed to remotely operate systems, such as remote key, immobilizer, and charging pile\n                                 \n                              \n                              \n                                 \n                                    16.2\n                                 \n                                 \n                                    Manipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)\n                                 \n                              \n                              \n                                 \n                                    16.3\n                                 \n                                 \n                                    Interference with short range wireless systems or sensors\n                                 \n                              \n                              \n                                 \n                                    17\n                                 \n                                 \n                                    Hosted 3rd party software, e.g. entertainment applications, used as a means to attack vehicle systems\n                                 \n                                 \n                                    17.1\n                                 \n                                 \n                                    Corrupted applications, or those with poor software security, used as a method to attack vehicle systems\n                                 \n                              \n                              \n                                 \n                                    18\n                                 \n                                 \n                                    Devices connected to external interfaces e.g. USB ports, OBD port, used as a means to attack vehicle systems\n                                 \n                                 \n                                    18.1\n                                 \n                                 \n                                    External interfaces such as USB or other ports used as a point of attack, for example through code injection\n                                 \n                              \n                              \n                                 \n                                    18.2\n                                 \n                                 \n                                    Media infected with a virus connected to a vehicle system\n                                 \n                              \n                              \n                                 \n                                    18.3\n                                 \n                                 \n                                    Diagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)\n                                 \n                              \n                              \n                                 \n                                    \n                                       \n                                       \n                                       \n                                          \n                                             \n                                                4.3.6.\n                                             \n                                             \n                                                Threats to vehicle data/code\n                                             \n                                          \n                                       \n                                    \n                                 \n                                 \n                                    19\n                                 \n                                 \n                                    Extraction of vehicle data/code\n                                 \n                                 \n                                    19.1\n                                 \n                                 \n                                    Extraction of copyright or proprietary software from vehicle systems (product piracy)\n                                 \n                              \n                              \n                                 \n                                    19.2\n                                 \n                                 \n                                    Unauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.\n                                 \n                              \n                              \n                                 \n                                    19.3\n                                 \n                                 \n                                    Extraction of cryptographic keys\n                                 \n                              \n                              \n                                 \n                                    20\n                                 \n                                 \n                                    Manipulation of vehicle data/code\n                                 \n                                 \n                                    20.1\n                                 \n                                 \n                                    Illegal/unauthorized changes to vehicle’s electronic ID\n                                 \n                              \n                              \n                                 \n                                    20.2\n                                 \n                                 \n                                    Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend\n                                 \n                              \n                              \n                                 \n                                    20.3\n                                 \n                                 \n                                    Action to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)\n                                 \n                              \n                              \n                                 \n                                    20.4\n                                 \n                                 \n                                    Data manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)\n                                 \n                              \n                              \n                                 \n                                    20.5\n                                 \n                                 \n                                    Unauthorized changes to system diagnostic data\n                                 \n                              \n                              \n                                 \n                                    21\n                                 \n                                 \n                                    Erasure of data/code\n                                 \n                                 \n                                    21.1\n                                 \n                                 \n                                    Unauthorized deletion/manipulation of system event logs\n                                 \n                              \n                              \n                                 \n                                    22\n                                 \n                                 \n                                    Introduction of malware\n                                 \n                                 \n                                    22.2\n                                 \n                                 \n                                    Introduce malicious software or malicious software activity\n                                 \n                              \n                              \n                                 \n                                    23\n                                 \n                                 \n                                    Introduction of new software or overwrite existing software\n                                 \n                                 \n                                    23.1\n                                 \n                                 \n                                    Fabrication of software of the vehicle control system or information system\n                                 \n                              \n                              \n                                 \n                                    24\n                                 \n                                 \n                                    Disruption of systems or operations\n                                 \n                                 \n                                    24.1\n                                 \n                                 \n                                    Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging\n                                 \n                              \n                              \n                                 \n                                    25\n                                 \n                                 \n                                    Manipulation of vehicle parameters\n                                 \n                                 \n                                    25.1\n                                 \n                                 \n                                    Unauthorized access of falsify the configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.\n                                 \n                              \n                              \n                                 \n                                    25.2\n                                 \n                                 \n                                    Unauthorized access of falsify the charging parameters, such as charging voltage, charging power, battery temperature, etc.\n                                 \n                              \n                              \n                                 \n                                    \n                                       \n                                       \n                                       \n                                          \n                                             \n                                                4.3.7.\n                                             \n                                             \n                                                Potential vulnerabilities that could be exploited if not sufficiently protected or hardened\n                                             \n                                          \n                                       \n                                    \n                                 \n                                 \n                                    26\n                                 \n                                 \n                                    Cryptographic technologies can be compromised or are insufficiently applied\n                                 \n                                 \n                                    26.1\n                                 \n                                 \n                                    Combination of short encryption keys and long period of validity enables attacker to break encryption\n                                 \n                              \n                              \n                                 \n                                    26.2\n                                 \n                                 \n                                    Insufficient use of cryptographic algorithms to protect sensitive systems\n                                 \n                              \n                              \n                                 \n                                    26.3\n                                 \n                                 \n                                    Using already or soon to be deprecated cryptographic algorithms\n                                 \n                              \n                              \n                                 \n                                    27\n                                 \n                                 \n                                    Parts or supplies could be compromised to permit vehicles to be attacked\n                                 \n                                 \n                                    27.1\n                                 \n                                 \n                                    Hardware or software, engineered to enable an attack or fails to meet design criteria to stop an attack\n                                 \n                              \n                              \n                                 \n                                    28\n                                 \n                                 \n                                    Software or hardware development permits vulnerabilities\n                                 \n                                 \n                                    28.1\n                                 \n                                 \n                                    Software bugs. The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present\n                                 \n                              \n                              \n                                 \n                                    28.2\n                                 \n                                 \n                                    Using remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit access to ECUs or permit attackers to gain higher privileges\n                                 \n                              \n                              \n                                 \n                                    29\n                                 \n                                 \n                                    Network design introduces vulnerabilities\n                                 \n                                 \n                                    29.1\n                                 \n                                 \n                                    Superfluous internet ports left open, providing access to network systems\n                                 \n                              \n                              \n                                 \n                                    29.2\n                                 \n                                 \n                                    Circumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages\n                                 \n                              \n                              \n                                 \n                                    31\n                                 \n                                 \n                                    Unintended transfer of data can occur\n                                 \n                                 \n                                    31.1\n                                 \n                                 \n                                    Information breach. Personal data may be leaked when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)\n                                 \n                              \n                              \n                                 \n                                    32\n                                 \n                                 \n                                    Physical manipulation of systems can enable an attack\n                                 \n                                 \n                                    32.1\n                                 \n                                 \n                                    Manipulation of electronic hardware, e.g. unauthorized electronic hardware added to a vehicle to enable ‘man-in-the-middle’ attack\n                                    Replacement of authorized electronic hardware (e.g., sensors) with unauthorized electronic hardware\n                                    Manipulation of the information collected by a sensor (for example, using a magnet to tamper with the Hall effect sensor connected to the gearbox)\n\nHigh-level descriptions of threats and relating vulnerability or attack method are listed in Table A1.\n\nTable A1\n\nTable A1\n\nList of vulnerability or attack method related to the threats\n\nList of vulnerability or attack method related to the threats\n\nHigh-level and sub-level descriptions of vulnerability/ threat\n\nHigh-level and sub-level descriptions of vulnerability/ threat\n\nExample of vulnerability or attack method\n\nExample of vulnerability or attack method\n\n4.3.1.\n                                             \n                                             \n                                                Threats regarding back-end servers related to vehicles in the field\n\n4.3.1.\n\n4.3.1.\n\nThreats regarding back-end servers related to vehicles in the field\n\nThreats regarding back-end servers related to vehicles in the field\n\nBack-end servers used as a means to attack a vehicle or extract data\n\nBack-end servers used as a means to attack a vehicle or extract data\n\n1.1\n\n1.1\n\nAbuse of privileges by staff (insider attack)\n\nAbuse of privileges by staff (insider attack)\n\n1.2\n\n1.2\n\nUnauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n\nUnauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n\n1.3\n\n1.3\n\nUnauthorized physical access to the server (conducted by for example USB sticks or other media connecting to the server)\n\nUnauthorized physical access to the server (conducted by for example USB sticks or other media connecting to the server)\n\nServices from back-end server being disrupted, affecting the operation of a vehicle\n\nServices from back-end server being disrupted, affecting the operation of a vehicle\n\n2.1\n\n2.1\n\nAttack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on\n\nAttack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on\n\nVehicle related data held on back-end servers being lost or compromised (‘data breach’)\n\nVehicle related data held on back-end servers being lost or compromised (‘data breach’)\n\n3.1\n\n3.1\n\nAbuse of privileges by staff (insider attack)\n\nAbuse of privileges by staff (insider attack)\n\n3.2\n\n3.2\n\nLoss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers\n\nLoss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers\n\n3.3\n\n3.3\n\nUnauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n\nUnauthorized internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n\n3.4\n\n3.4\n\nUnauthorized physical access to the server (conducted for example by USB sticks or other media connecting to the server)\n\nUnauthorized physical access to the server (conducted for example by USB sticks or other media connecting to the server)\n\n3.5\n\n3.5\n\nInformation breach by unintended sharing of data (e.g. admin errors)\n\nInformation breach by unintended sharing of data (e.g. admin errors)\n\n4.3.2.\n                                             \n                                             \n                                                Threats to vehicles regarding their communication channels\n\n4.3.2.\n\n4.3.2.\n\nThreats to vehicles regarding their communication channels\n\nThreats to vehicles regarding their communication channels\n\nSpoofing of messages or data received by the vehicle\n\nSpoofing of messages or data received by the vehicle\n\n4.1\n\n4.1\n\nSpoofing of messages by impersonation (e.g. 802.11p V2X during platooning, GNSS messages, etc.)\n\nSpoofing of messages by impersonation (e.g. 802.11p V2X during platooning, GNSS messages, etc.)\n\n4.2\n\n4.2\n\nSybil attack (in order to spoof other vehicles as if there are many vehicles on the road)\n\nSybil attack (in order to spoof other vehicles as if there are many vehicles on the road)\n\nCommunication channels used to conduct unauthorized manipulation, deletion or other amendments to vehicle held code/data\n\nCommunication channels used to conduct unauthorized manipulation, deletion or other amendments to vehicle held code/data\n\n5.1\n\n5.1\n\nCommunications channels permit code injection, for example tampered software binary might be injected into the communication stream\n\nCommunications channels permit code injection, for example tampered software binary might be injected into the communication stream\n\n5.2\n\n5.2\n\nCommunications channels permit manipulate of vehicle held data/code\n\nCommunications channels permit manipulate of vehicle held data/code\n\n5.3\n\n5.3\n\nCommunications channels permit overwrite of vehicle held data/code\n\nCommunications channels permit overwrite of vehicle held data/code\n\n5.4\n\n5.4\n\nCommunications channels permit erasure of vehicle held data/code\n\nCommunications channels permit erasure of vehicle held data/code\n\n5.5\n\n5.5\n\nCommunications channels permit introduction of data/code to the vehicle (write data code)\n\nCommunications channels permit introduction of data/code to the vehicle (write data code)\n\nCommunication channels permit untrusted/unreliable messages to be accepted or are vulnerable to session hijacking/replay attacks\n\nCommunication channels permit untrusted/unreliable messages to be accepted or are vulnerable to session hijacking/replay attacks\n\n6.1\n\n6.1\n\nAccepting information from an unreliable or untrusted source\n\nAccepting information from an unreliable or untrusted source\n\n6.2\n\n6.2\n\nMan in the middle attack/ session hijacking\n\nMan in the middle attack/ session hijacking\n\n6.3\n\n6.3\n\nReplay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway\n\nReplay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway\n\nInformation can be readily disclosed. For example, through eavesdropping on communications or through allowing unauthorized access to sensitive files or folders\n\nInformation can be readily disclosed. For example, through eavesdropping on communications or through allowing unauthorized access to sensitive files or folders\n\n7.1\n\n7.1\n\nInterception of information / interfering radiations / monitoring communications\n\nInterception of information / interfering radiations / monitoring communications\n\n7.2\n\n7.2\n\nGaining unauthorized access to files or data\n\nGaining unauthorized access to files or data\n\nDenial of service attacks via communication channels to disrupt vehicle functions\n\nDenial of service attacks via communication channels to disrupt vehicle functions\n\n8.1\n\n8.1\n\nSending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner\n\nSending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner\n\n8.2\n\n8.2\n\nBlack hole attack, in order to disrupt communication between vehicles the attacker is able to block messages between the vehicles\n\nBlack hole attack, in order to disrupt communication between vehicles the attacker is able to block messages between the vehicles\n\nAn unprivileged user is able to gain privileged access to vehicle systems\n\nAn unprivileged user is able to gain privileged access to vehicle systems\n\n9.1\n\n9.1\n\nAn unprivileged user is able to gain privileged access, for example root access\n\nAn unprivileged user is able to gain privileged access, for example root access\n\n10\n\n10\n\nViruses embedded in communication media are able to infect vehicle systems\n\nViruses embedded in communication media are able to infect vehicle systems\n\n10.1\n\n10.1\n\nVirus embedded in communication media infects vehicle systems\n\nVirus embedded in communication media infects vehicle systems\n\n11\n\n11\n\nMessages received by the vehicle (for example X2V or diagnostic messages), or transmitted within it, contain malicious content\n\nMessages received by the vehicle (for example X2V or diagnostic messages), or transmitted within it, contain malicious content\n\n11.1\n\n11.1\n\nMalicious internal (e.g. CAN) messages\n\nMalicious internal (e.g. CAN) messages\n\n11.2\n\n11.2\n\nMalicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)\n\nMalicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)\n\n11.3\n\n11.3\n\nMalicious diagnostic messages\n\nMalicious diagnostic messages\n\n11.4\n\n11.4\n\nMalicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)\n\nMalicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)\n\n4.3.3.\n                                             \n                                             \n                                                Threats to vehicles regarding their update procedures\n\n4.3.3.\n\n4.3.3.\n\nThreats to vehicles regarding their update procedures\n\nThreats to vehicles regarding their update procedures\n\n12\n\n12\n\nMisuse or compromise of update procedures\n\nMisuse or compromise of update procedures\n\n12.1\n\n12.1\n\nCompromise of over the air software update procedures. This includes fabricating the system update program or firmware\n\nCompromise of over the air software update procedures. This includes fabricating the system update program or firmware\n\n12.2\n\n12.2\n\nCompromise of local/physical software update procedures. This includes fabricating the system update program or firmware\n\nCompromise of local/physical software update procedures. This includes fabricating the system update program or firmware\n\n12.3\n\n12.3\n\nThe software is manipulated before the update process (and is therefore corrupted), although the update process is intact\n\nThe software is manipulated before the update process (and is therefore corrupted), although the update process is intact\n\n12.4\n\n12.4\n\nCompromise of cryptographic keys of the software provider to allow invalid update\n\nCompromise of cryptographic keys of the software provider to allow invalid update\n\n13\n\n13\n\nIt is possible to deny legitimate updates\n\nIt is possible to deny legitimate updates\n\n13.1\n\n13.1\n\nDenial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features\n\nDenial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features\n\n4.3.4.\n                                             \n                                             \n                                                Threats to vehicles regarding unintended human actions facilitating a cyberattack\n\n4.3.4.\n\n4.3.4.\n\nThreats to vehicles regarding unintended human actions facilitating a cyberattack\n\nThreats to vehicles regarding unintended human actions facilitating a cyberattack\n\n15\n\n15\n\nLegitimate actors are able to take actions that would unwittingly facilitate a cyberattack\n\nLegitimate actors are able to take actions that would unwittingly facilitate a cyberattack\n\n15.1\n\n15.1\n\nInnocent victim (e.g. owner, operator or maintenance engineer) being tricked into taking an action to unintentionally load malware or enable an attack\n\nInnocent victim (e.g. owner, operator or maintenance engineer) being tricked into taking an action to unintentionally load malware or enable an attack\n\n15.2\n\n15.2\n\nDefined security procedures are not followed\n\nDefined security procedures are not followed\n\n4.3.5.\n                                             \n                                             \n                                                Threats to vehicles regarding their external connectivity and connections\n\n4.3.5.\n\n4.3.5.\n\nThreats to vehicles regarding their external connectivity and connections\n\nThreats to vehicles regarding their external connectivity and connections\n\n16\n\n16\n\nManipulation of the connectivity of vehicle functions enables a cyberattack, this can include telematics; systems that permit remote operations; and systems using short range wireless communications\n\nManipulation of the connectivity of vehicle functions enables a cyberattack, this can include telematics; systems that permit remote operations; and systems using short range wireless communications\n\n16.1\n\n16.1\n\nManipulation of functions designed to remotely operate systems, such as remote key, immobilizer, and charging pile\n\nManipulation of functions designed to remotely operate systems, such as remote key, immobilizer, and charging pile\n\n16.2\n\n16.2\n\nManipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)\n\nManipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)\n\n16.3\n\n16.3\n\nInterference with short range wireless systems or sensors\n\nInterference with short range wireless systems or sensors\n\n17\n\n17\n\nHosted 3rd party software, e.g. entertainment applications, used as a means to attack vehicle systems\n\nHosted 3rd party software, e.g. entertainment applications, used as a means to attack vehicle systems\n\n17.1\n\n17.1\n\nCorrupted applications, or those with poor software security, used as a method to attack vehicle systems\n\nCorrupted applications, or those with poor software security, used as a method to attack vehicle systems\n\n18\n\n18\n\nDevices connected to external interfaces e.g. USB ports, OBD port, used as a means to attack vehicle systems\n\nDevices connected to external interfaces e.g. USB ports, OBD port, used as a means to attack vehicle systems\n\n18.1\n\n18.1\n\nExternal interfaces such as USB or other ports used as a point of attack, for example through code injection\n\nExternal interfaces such as USB or other ports used as a point of attack, for example through code injection\n\n18.2\n\n18.2\n\nMedia infected with a virus connected to a vehicle system\n\nMedia infected with a virus connected to a vehicle system\n\n18.3\n\n18.3\n\nDiagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)\n\nDiagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)\n\n4.3.6.\n                                             \n                                             \n                                                Threats to vehicle data/code\n\n4.3.6.\n\n4.3.6.\n\nThreats to vehicle data/code\n\nThreats to vehicle data/code\n\n19\n\n19\n\nExtraction of vehicle data/code\n\nExtraction of vehicle data/code\n\n19.1\n\n19.1\n\nExtraction of copyright or proprietary software from vehicle systems (product piracy)\n\nExtraction of copyright or proprietary software from vehicle systems (product piracy)\n\n19.2\n\n19.2\n\nUnauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.\n\nUnauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.\n\n19.3\n\n19.3\n\nExtraction of cryptographic keys\n\nExtraction of cryptographic keys\n\n20\n\n20\n\nManipulation of vehicle data/code\n\nManipulation of vehicle data/code\n\n20.1\n\n20.1\n\nIllegal/unauthorized changes to vehicle’s electronic ID\n\nIllegal/unauthorized changes to vehicle’s electronic ID\n\n20.2\n\n20.2\n\nIdentity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend\n\nIdentity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend\n\n20.3\n\n20.3\n\nAction to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)\n\nAction to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)\n\n20.4\n\n20.4\n\nData manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)\n\nData manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)\n\n20.5\n\n20.5\n\nUnauthorized changes to system diagnostic data\n\nUnauthorized changes to system diagnostic data\n\n21\n\n21\n\nErasure of data/code\n\nErasure of data/code\n\n21.1\n\n21.1\n\nUnauthorized deletion/manipulation of system event logs\n\nUnauthorized deletion/manipulation of system event logs\n\n22\n\n22\n\nIntroduction of malware\n\nIntroduction of malware\n\n22.2\n\n22.2\n\nIntroduce malicious software or malicious software activity\n\nIntroduce malicious software or malicious software activity\n\n23\n\n23\n\nIntroduction of new software or overwrite existing software\n\nIntroduction of new software or overwrite existing software\n\n23.1\n\n23.1\n\nFabrication of software of the vehicle control system or information system\n\nFabrication of software of the vehicle control system or information system\n\n24\n\n24\n\nDisruption of systems or operations\n\nDisruption of systems or operations\n\n24.1\n\n24.1\n\nDenial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging\n\nDenial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging\n\n25\n\n25\n\nManipulation of vehicle parameters\n\nManipulation of vehicle parameters\n\n25.1\n\n25.1\n\nUnauthorized access of falsify the configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.\n\nUnauthorized access of falsify the configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.\n\n25.2\n\n25.2\n\nUnauthorized access of falsify the charging parameters, such as charging voltage, charging power, battery temperature, etc.\n\nUnauthorized access of falsify the charging parameters, such as charging voltage, charging power, battery temperature, etc.\n\n4.3.7.\n                                             \n                                             \n                                                Potential vulnerabilities that could be exploited if not sufficiently protected or hardened\n\n4.3.7.\n\n4.3.7.\n\nPotential vulnerabilities that could be exploited if not sufficiently protected or hardened\n\nPotential vulnerabilities that could be exploited if not sufficiently protected or hardened\n\n26\n\n26\n\nCryptographic technologies can be compromised or are insufficiently applied\n\nCryptographic technologies can be compromised or are insufficiently applied\n\n26.1\n\n26.1\n\nCombination of short encryption keys and long period of validity enables attacker to break encryption\n\nCombination of short encryption keys and long period of validity enables attacker to break encryption\n\n26.2\n\n26.2\n\nInsufficient use of cryptographic algorithms to protect sensitive systems\n\nInsufficient use of cryptographic algorithms to protect sensitive systems\n\n26.3\n\n26.3\n\nUsing already or soon to be deprecated cryptographic algorithms\n\nUsing already or soon to be deprecated cryptographic algorithms\n\n27\n\n27\n\nParts or supplies could be compromised to permit vehicles to be attacked\n\nParts or supplies could be compromised to permit vehicles to be attacked\n\n27.1\n\n27.1\n\nHardware or software, engineered to enable an attack or fails to meet design criteria to stop an attack\n\nHardware or software, engineered to enable an attack or fails to meet design criteria to stop an attack\n\n28\n\n28\n\nSoftware or hardware development permits vulnerabilities\n\nSoftware or hardware development permits vulnerabilities\n\n28.1\n\n28.1\n\nSoftware bugs. The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present\n\nSoftware bugs. The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present\n\n28.2\n\n28.2\n\nUsing remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit access to ECUs or permit attackers to gain higher privileges\n\nUsing remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit access to ECUs or permit attackers to gain higher privileges\n\n29\n\n29\n\nNetwork design introduces vulnerabilities\n\nNetwork design introduces vulnerabilities\n\n29.1\n\n29.1\n\nSuperfluous internet ports left open, providing access to network systems\n\nSuperfluous internet ports left open, providing access to network systems\n\n29.2\n\n29.2\n\nCircumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages\n\nCircumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages\n\n31\n\n31\n\nUnintended transfer of data can occur\n\nUnintended transfer of data can occur\n\n31.1\n\n31.1\n\nInformation breach. Personal data may be leaked when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)\n\nInformation breach. Personal data may be leaked when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)\n\n32\n\n32\n\nPhysical manipulation of systems can enable an attack\n\nPhysical manipulation of systems can enable an attack\n\n32.1\n\n32.1\n\nManipulation of electronic hardware, e.g. unauthorized electronic hardware added to a vehicle to enable ‘man-in-the-middle’ attack\n                                    Replacement of authorized electronic hardware (e.g., sensors) with unauthorized electronic hardware\n                                    Manipulation of the information collected by a sensor (for example, using a magnet to tamper with the Hall effect sensor connected to the gearbox)\n\nManipulation of electronic hardware, e.g. unauthorized electronic hardware added to a vehicle to enable ‘man-in-the-middle’ attack\n\nReplacement of authorized electronic hardware (e.g., sensors) with unauthorized electronic hardware\n\nManipulation of the information collected by a sensor (for example, using a magnet to tamper with the Hall effect sensor connected to the gearbox)\n\nPart B. Mitigations to the threats intended for vehicles\n\n1.\n\n1.\n\nMitigations for ‘Vehicle communication channels’\n                        Mitigations to the threats which are related to ‘Vehicle communication channels’ are listed in Table B1.\n                        \n                           Table B1\n                        \n                        \n                           Mitigation to the threats which are related to ‘Vehicle communication channels’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats to ‘Vehicle communication channels’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    4.1\n                                 \n                                 \n                                    Spoofing of messages (e.g. 802.11p V2X during platooning, GNSS messages, etc.) by impersonation\n                                 \n                                 \n                                    M10\n                                 \n                                 \n                                    The vehicle shall verify the authenticity and integrity of messages it receives\n                                 \n                              \n                              \n                                 \n                                    4.2\n                                 \n                                 \n                                    Sybil attack (in order to spoof other vehicles as if there are many vehicles on the road)\n                                 \n                                 \n                                    M11\n                                 \n                                 \n                                    Security controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security Modules)\n                                 \n                              \n                              \n                                 \n                                    5.1\n                                 \n                                 \n                                    Communication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream\n                                 \n                                 \n                                    M10\n                                    M6\n                                 \n                                 \n                                    The vehicle shall verify the authenticity and integrity of messages it receives\n                                    Systems shall implement security by design to minimize risks\n                                 \n                              \n                              \n                                 \n                                    5.2\n                                 \n                                 \n                                    Communication channels permit manipulation of vehicle held data/code\n                                 \n                                 \n                                    M7\n                                 \n                                 \n                                    Access control techniques and designs shall be applied to protect system data/code\n                                 \n                              \n                              \n                                 \n                                    5.3\n                                 \n                                 \n                                    Communication channels permit overwrite of vehicle held data/code\n                                 \n                              \n                              \n                                 \n                                    5.4\n                                    21.1\n                                 \n                                 \n                                    Communication channels permit erasure of vehicle held data/code\n                                 \n                              \n                              \n                                 \n                                    5.5\n                                 \n                                 \n                                    Communication channels permit introduction of data/code to vehicle systems (write data code)\n                                 \n                              \n                              \n                                 \n                                    6.1\n                                 \n                                 \n                                    Accepting information from an unreliable or untrusted source\n                                 \n                                 \n                                    M10\n                                 \n                                 \n                                    The vehicle shall verify the authenticity and integrity of messages it receives\n                                 \n                              \n                              \n                                 \n                                    6.2\n                                 \n                                 \n                                    Man in the middle attack / session hijacking\n                                 \n                                 \n                                    M10\n                                 \n                                 \n                                    The vehicle shall verify the authenticity and integrity of messages it receives\n                                 \n                              \n                              \n                                 \n                                    6.3\n                                 \n                                 \n                                    Replay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway\n                                 \n                              \n                              \n                                 \n                                    7.1\n                                 \n                                 \n                                    Interception of information / interfering radiations / monitoring communications\n                                 \n                                 \n                                    M12\n                                 \n                                 \n                                    Confidential data transmitted to or from the vehicle shall be protected\n                                 \n                              \n                              \n                                 \n                                    7.2\n                                 \n                                 \n                                    Gaining unauthorized access to files or data\n                                 \n                                 \n                                    M8\n                                 \n                                 \n                                    Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Example of Security Controls can be found in OWASP\n                                 \n                              \n                              \n                                 \n                                    8.1\n                                 \n                                 \n                                    Sending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner\n                                 \n                                 \n                                    M13\n                                 \n                                 \n                                    Measures to detect and recover from a denial of service attack shall be employed\n                                 \n                              \n                              \n                                 \n                                    8.2\n                                 \n                                 \n                                    Black hole attack, disruption of communication between vehicles by blocking the transfer of messages to other vehicles\n                                 \n                                 \n                                    M13\n                                 \n                                 \n                                    Measures to detect and recover from a denial of service attack shall be employed\n                                 \n                              \n                              \n                                 \n                                    9.1\n                                 \n                                 \n                                    An unprivileged user is able to gain privileged access, for example root access\n                                 \n                                 \n                                    M9\n                                 \n                                 \n                                    Measures to prevent and detect unauthorized access shall be employed\n                                 \n                              \n                              \n                                 \n                                    10.1\n                                 \n                                 \n                                    Virus embedded in communication media infects vehicle systems\n                                 \n                                 \n                                    M14\n                                 \n                                 \n                                    Measures to protect systems against embedded viruses/malware should be considered\n                                 \n                              \n                              \n                                 \n                                    11.1\n                                 \n                                 \n                                    Malicious internal (e.g. CAN) messages\n                                 \n                                 \n                                    M15\n                                 \n                                 \n                                    Measures to detect malicious internal messages or activity should be considered\n                                 \n                              \n                              \n                                 \n                                    11.2\n                                 \n                                 \n                                    Malicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)\n                                 \n                                 \n                                    M10\n                                 \n                                 \n                                    The vehicle shall verify the authenticity and integrity of messages it receives\n                                 \n                              \n                              \n                                 \n                                    11.3\n                                 \n                                 \n                                    Malicious diagnostic messages\n                                 \n                              \n                              \n                                 \n                                    11.4\n                                 \n                                 \n                                    Malicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)\n\nMitigations for ‘Vehicle communication channels’\n\nMitigations to the threats which are related to ‘Vehicle communication channels’ are listed in Table B1.\n\nTable B1\n\nTable B1\n\nMitigation to the threats which are related to ‘Vehicle communication channels’\n\nMitigation to the threats which are related to ‘Vehicle communication channels’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats to ‘Vehicle communication channels’\n\nThreats to ‘Vehicle communication channels’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n4.1\n\n4.1\n\nSpoofing of messages (e.g. 802.11p V2X during platooning, GNSS messages, etc.) by impersonation\n\nSpoofing of messages (e.g. 802.11p V2X during platooning, GNSS messages, etc.) by impersonation\n\nM10\n\nM10\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\n4.2\n\n4.2\n\nSybil attack (in order to spoof other vehicles as if there are many vehicles on the road)\n\nSybil attack (in order to spoof other vehicles as if there are many vehicles on the road)\n\nM11\n\nM11\n\nSecurity controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security Modules)\n\nSecurity controls shall be implemented for storing cryptographic keys (e.g., use of Hardware Security Modules)\n\n5.1\n\n5.1\n\nCommunication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream\n\nCommunication channels permit code injection into vehicle held data/code, for example tampered software binary might be injected into the communication stream\n\nM10\n                                    M6\n\nM10\n\nM6\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n                                    Systems shall implement security by design to minimize risks\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\nSystems shall implement security by design to minimize risks\n\n5.2\n\n5.2\n\nCommunication channels permit manipulation of vehicle held data/code\n\nCommunication channels permit manipulation of vehicle held data/code\n\nM7\n\nM7\n\nAccess control techniques and designs shall be applied to protect system data/code\n\nAccess control techniques and designs shall be applied to protect system data/code\n\n5.3\n\n5.3\n\nCommunication channels permit overwrite of vehicle held data/code\n\nCommunication channels permit overwrite of vehicle held data/code\n\n5.4\n                                    21.1\n\n5.4\n\n21.1\n\nCommunication channels permit erasure of vehicle held data/code\n\nCommunication channels permit erasure of vehicle held data/code\n\n5.5\n\n5.5\n\nCommunication channels permit introduction of data/code to vehicle systems (write data code)\n\nCommunication channels permit introduction of data/code to vehicle systems (write data code)\n\n6.1\n\n6.1\n\nAccepting information from an unreliable or untrusted source\n\nAccepting information from an unreliable or untrusted source\n\nM10\n\nM10\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\n6.2\n\n6.2\n\nMan in the middle attack / session hijacking\n\nMan in the middle attack / session hijacking\n\nM10\n\nM10\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\n6.3\n\n6.3\n\nReplay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway\n\nReplay attack, for example an attack against a communication gateway allows the attacker to downgrade software of an ECU or firmware of the gateway\n\n7.1\n\n7.1\n\nInterception of information / interfering radiations / monitoring communications\n\nInterception of information / interfering radiations / monitoring communications\n\nM12\n\nM12\n\nConfidential data transmitted to or from the vehicle shall be protected\n\nConfidential data transmitted to or from the vehicle shall be protected\n\n7.2\n\n7.2\n\nGaining unauthorized access to files or data\n\nGaining unauthorized access to files or data\n\nM8\n\nM8\n\nThrough system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Example of Security Controls can be found in OWASP\n\nThrough system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Example of Security Controls can be found in OWASP\n\n8.1\n\n8.1\n\nSending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner\n\nSending a large number of garbage data to vehicle information system, so that it is unable to provide services in the normal manner\n\nM13\n\nM13\n\nMeasures to detect and recover from a denial of service attack shall be employed\n\nMeasures to detect and recover from a denial of service attack shall be employed\n\n8.2\n\n8.2\n\nBlack hole attack, disruption of communication between vehicles by blocking the transfer of messages to other vehicles\n\nBlack hole attack, disruption of communication between vehicles by blocking the transfer of messages to other vehicles\n\nM13\n\nM13\n\nMeasures to detect and recover from a denial of service attack shall be employed\n\nMeasures to detect and recover from a denial of service attack shall be employed\n\n9.1\n\n9.1\n\nAn unprivileged user is able to gain privileged access, for example root access\n\nAn unprivileged user is able to gain privileged access, for example root access\n\nM9\n\nM9\n\nMeasures to prevent and detect unauthorized access shall be employed\n\nMeasures to prevent and detect unauthorized access shall be employed\n\n10.1\n\n10.1\n\nVirus embedded in communication media infects vehicle systems\n\nVirus embedded in communication media infects vehicle systems\n\nM14\n\nM14\n\nMeasures to protect systems against embedded viruses/malware should be considered\n\nMeasures to protect systems against embedded viruses/malware should be considered\n\n11.1\n\n11.1\n\nMalicious internal (e.g. CAN) messages\n\nMalicious internal (e.g. CAN) messages\n\nM15\n\nM15\n\nMeasures to detect malicious internal messages or activity should be considered\n\nMeasures to detect malicious internal messages or activity should be considered\n\n11.2\n\n11.2\n\nMalicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)\n\nMalicious V2X messages, e.g. infrastructure to vehicle or vehicle-vehicle messages (e.g. CAM, DENM)\n\nM10\n\nM10\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\nThe vehicle shall verify the authenticity and integrity of messages it receives\n\n11.3\n\n11.3\n\nMalicious diagnostic messages\n\nMalicious diagnostic messages\n\n11.4\n\n11.4\n\nMalicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)\n\nMalicious proprietary messages (e.g. those normally sent from OEM or component/system/function supplier)\n\n2.\n\n2.\n\nMitigations for ‘Update process’\n                        Mitigations to the threats which are related to ‘Update process’ are listed in Table B2.\n                        \n                           Table B2\n                        \n                        \n                           Mitigations to the threats which are related to ‘Update process’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats to ‘Update process’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    12.1\n                                 \n                                 \n                                    Compromise of over the air software update procedures. This includes fabricating the system update program or firmware\n                                 \n                                 \n                                    M16\n                                 \n                                 \n                                    Secure software update procedures shall be employed\n                                 \n                              \n                              \n                                 \n                                    12.2\n                                 \n                                 \n                                    Compromise of local/physical software update procedures. This includes fabricating the system update program or firmware\n                                 \n                              \n                              \n                                 \n                                    12.3\n                                 \n                                 \n                                    The software is manipulated before the update process (and is therefore corrupted), although the update process is intact\n                                 \n                              \n                              \n                                 \n                                    12.4\n                                 \n                                 \n                                    Compromise of cryptographic keys of the software provider to allow invalid update\n                                 \n                                 \n                                    M11\n                                 \n                                 \n                                    Security controls shall be implemented for storing cryptographic keys\n                                 \n                              \n                              \n                                 \n                                    13.1\n                                 \n                                 \n                                    Denial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features\n                                 \n                                 \n                                    M3\n                                 \n                                 \n                                    Security Controls shall be applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP\n\nMitigations for ‘Update process’\n\nMitigations to the threats which are related to ‘Update process’ are listed in Table B2.\n\nTable B2\n\nTable B2\n\nMitigations to the threats which are related to ‘Update process’\n\nMitigations to the threats which are related to ‘Update process’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats to ‘Update process’\n\nThreats to ‘Update process’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n12.1\n\n12.1\n\nCompromise of over the air software update procedures. This includes fabricating the system update program or firmware\n\nCompromise of over the air software update procedures. This includes fabricating the system update program or firmware\n\nM16\n\nM16\n\nSecure software update procedures shall be employed\n\nSecure software update procedures shall be employed\n\n12.2\n\n12.2\n\nCompromise of local/physical software update procedures. This includes fabricating the system update program or firmware\n\nCompromise of local/physical software update procedures. This includes fabricating the system update program or firmware\n\n12.3\n\n12.3\n\nThe software is manipulated before the update process (and is therefore corrupted), although the update process is intact\n\nThe software is manipulated before the update process (and is therefore corrupted), although the update process is intact\n\n12.4\n\n12.4\n\nCompromise of cryptographic keys of the software provider to allow invalid update\n\nCompromise of cryptographic keys of the software provider to allow invalid update\n\nM11\n\nM11\n\nSecurity controls shall be implemented for storing cryptographic keys\n\nSecurity controls shall be implemented for storing cryptographic keys\n\n13.1\n\n13.1\n\nDenial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features\n\nDenial of Service attack against update server or network to prevent rollout of critical software updates and/or unlock of customer specific features\n\nM3\n\nM3\n\nSecurity Controls shall be applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP\n\nSecurity Controls shall be applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP\n\n3.\n\n3.\n\nMitigations for ‘Unintended human actions facilitating a cyberattack’\n                        Mitigations to the threats which are related to ‘Unintended human actions facilitating a cyberattack’ are listed in Table B3.\n                        \n                           Table B3\n                        \n                        \n                           Mitigations to the threats which are related to ‘Unintended human actions facilitating a cyberattack’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats relating to ‘Unintended human actions’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    15.1\n                                 \n                                 \n                                    Innocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack\n                                 \n                                 \n                                    M18\n                                 \n                                 \n                                    Measures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege\n                                 \n                              \n                              \n                                 \n                                    15.2\n                                 \n                                 \n                                    Defined security procedures are not followed\n                                 \n                                 \n                                    M19\n                                 \n                                 \n                                    Organizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions\n\nMitigations for ‘Unintended human actions facilitating a cyberattack’\n\nMitigations to the threats which are related to ‘Unintended human actions facilitating a cyberattack’ are listed in Table B3.\n\nTable B3\n\nTable B3\n\nMitigations to the threats which are related to ‘Unintended human actions facilitating a cyberattack’\n\nMitigations to the threats which are related to ‘Unintended human actions facilitating a cyberattack’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats relating to ‘Unintended human actions’\n\nThreats relating to ‘Unintended human actions’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n15.1\n\n15.1\n\nInnocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack\n\nInnocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack\n\nM18\n\nM18\n\nMeasures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege\n\nMeasures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege\n\n15.2\n\n15.2\n\nDefined security procedures are not followed\n\nDefined security procedures are not followed\n\nM19\n\nM19\n\nOrganizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions\n\nOrganizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions\n\n4.\n\n4.\n\nMitigations for ‘External connectivity and connections’\n                        Mitigations to the threats which are related to ‘external connectivity and connections’ are listed in Table B4.\n                        \n                           Table B4\n                        \n                        \n                           Mitigation to the threats which are related to ‘external connectivity and connections’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats to ‘External connectivity and connections’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    16.1\n                                 \n                                 \n                                    Manipulation of functions designed to remotely operate vehicle systems, such as remote key, immobiliser, and charging pile\n                                 \n                                 \n                                    M20\n                                 \n                                 \n                                    Security controls shall be applied to systems that have remote access\n                                 \n                              \n                              \n                                 \n                                    16.2\n                                 \n                                 \n                                    Manipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)\n                                 \n                              \n                              \n                                 \n                                    16.3\n                                 \n                                 \n                                    Interference with short range wireless systems or sensors\n                                 \n                              \n                              \n                                 \n                                    17.1\n                                 \n                                 \n                                    Corrupted applications, or those with poor software security, used as a method to attack vehicle systems\n                                 \n                                 \n                                    M21\n                                 \n                                 \n                                    Software shall be security assessed, authenticated and integrity protected.\n                                    Security controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle\n                                 \n                              \n                              \n                                 \n                                    18.1\n                                 \n                                 \n                                    External interfaces such as USB or other ports used as a point of attack, for example through code injection\n                                 \n                                 \n                                    M22\n                                 \n                                 \n                                    Security controls shall be applied to external interfaces\n                                 \n                              \n                              \n                                 \n                                    18.2\n                                 \n                                 \n                                    Media infected with viruses connected to the vehicle\n                                 \n                              \n                              \n                                 \n                                    18.3\n                                 \n                                 \n                                    Diagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)\n                                 \n                                 \n                                    M22\n                                 \n                                 \n                                    Security controls shall be applied to external interfaces\n\nMitigations for ‘External connectivity and connections’\n\nMitigations to the threats which are related to ‘external connectivity and connections’ are listed in Table B4.\n\nTable B4\n\nTable B4\n\nMitigation to the threats which are related to ‘external connectivity and connections’\n\nMitigation to the threats which are related to ‘external connectivity and connections’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats to ‘External connectivity and connections’\n\nThreats to ‘External connectivity and connections’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n16.1\n\n16.1\n\nManipulation of functions designed to remotely operate vehicle systems, such as remote key, immobiliser, and charging pile\n\nManipulation of functions designed to remotely operate vehicle systems, such as remote key, immobiliser, and charging pile\n\nM20\n\nM20\n\nSecurity controls shall be applied to systems that have remote access\n\nSecurity controls shall be applied to systems that have remote access\n\n16.2\n\n16.2\n\nManipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)\n\nManipulation of vehicle telematics (e.g. manipulate temperature measurement of sensitive goods, remotely unlock cargo doors)\n\n16.3\n\n16.3\n\nInterference with short range wireless systems or sensors\n\nInterference with short range wireless systems or sensors\n\n17.1\n\n17.1\n\nCorrupted applications, or those with poor software security, used as a method to attack vehicle systems\n\nCorrupted applications, or those with poor software security, used as a method to attack vehicle systems\n\nM21\n\nM21\n\nSoftware shall be security assessed, authenticated and integrity protected.\n                                    Security controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle\n\nSoftware shall be security assessed, authenticated and integrity protected.\n\nSecurity controls shall be applied to minimise the risk from third party software that is intended or foreseeable to be hosted on the vehicle\n\n18.1\n\n18.1\n\nExternal interfaces such as USB or other ports used as a point of attack, for example through code injection\n\nExternal interfaces such as USB or other ports used as a point of attack, for example through code injection\n\nM22\n\nM22\n\nSecurity controls shall be applied to external interfaces\n\nSecurity controls shall be applied to external interfaces\n\n18.2\n\n18.2\n\nMedia infected with viruses connected to the vehicle\n\nMedia infected with viruses connected to the vehicle\n\n18.3\n\n18.3\n\nDiagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)\n\nDiagnostic access (e.g. dongles in OBD port) used to facilitate an attack, e.g. manipulate vehicle parameters (directly or indirectly)\n\nM22\n\nM22\n\nSecurity controls shall be applied to external interfaces\n\nSecurity controls shall be applied to external interfaces\n\n5.\n\n5.\n\nMitigations for ‘Potential targets of, or motivations for, an attack’\n                        Mitigations to the threats which are related to ‘Potential targets of, or motivations for, an attack’ are listed in Table B5.\n                        \n                           Table B5\n                        \n                        \n                           Mitigations to the threats which are related to ‘Potential targets of, or motivations for, an attack’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats to ‘Potential targets of, or motivations for, an attack’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    19.1\n                                 \n                                 \n                                    Extraction of copyright or proprietary software from vehicle systems (product piracy / stolen software)\n                                 \n                                 \n                                    M7\n                                 \n                                 \n                                    Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n                                 \n                              \n                              \n                                 \n                                    19.2\n                                 \n                                 \n                                    Unauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.\n                                 \n                                 \n                                    M8\n                                 \n                                 \n                                    Through system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Examples of Security Controls can be found in OWASP\n                                 \n                              \n                              \n                                 \n                                    19.3\n                                 \n                                 \n                                    Extraction of cryptographic keys\n                                 \n                                 \n                                    M11\n                                 \n                                 \n                                    Security controls shall be implemented for storing cryptographic keys e.g. Security Modules\n                                 \n                              \n                              \n                                 \n                                    20.1\n                                 \n                                 \n                                    Illegal/unauthorised changes to vehicle’s electronic ID\n                                 \n                                 \n                                    M7\n                                 \n                                 \n                                    Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n                                 \n                              \n                              \n                                 \n                                    20.2\n                                 \n                                 \n                                    Identity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend\n                                 \n                              \n                              \n                                 \n                                    20.3\n                                 \n                                 \n                                    Action to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)\n                                 \n                                 \n                                    M7\n                                 \n                                 \n                                    Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n                                    Data manipulation attacks on sensors or transmitted data could be mitigated by correlating the data from different sources of information\n                                 \n                              \n                              \n                                 \n                                    20.4\n                                 \n                                 \n                                    Data manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)\n                                 \n                              \n                              \n                                 \n                                    20.5\n                                 \n                                 \n                                    Unauthorised changes to system diagnostic data\n                                 \n                              \n                              \n                                 \n                                    21.1\n                                 \n                                 \n                                    Unauthorized deletion/manipulation of system event logs\n                                 \n                                 \n                                    M7\n                                 \n                                 \n                                    Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n                                 \n                              \n                              \n                                 \n                                    22.2\n                                 \n                                 \n                                    Introduce malicious software or malicious software activity\n                                 \n                                 \n                                    M7\n                                 \n                                 \n                                    Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n                                 \n                              \n                              \n                                 \n                                    23.1\n                                 \n                                 \n                                    Fabrication of software of the vehicle control system or information system\n                                 \n                              \n                              \n                                 \n                                    24.1\n                                 \n                                 \n                                    Denial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging\n                                 \n                                 \n                                    M13\n                                 \n                                 \n                                    Measures to detect and recover from a denial of service attack shall be employed\n                                 \n                              \n                              \n                                 \n                                    25.1\n                                 \n                                 \n                                    Unauthorized access to falsify configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.\n                                 \n                                 \n                                    M7\n                                 \n                                 \n                                    Access control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n                                 \n                              \n                              \n                                 \n                                    25.2\n                                 \n                                 \n                                    Unauthorized access to falsify charging parameters, such as charging voltage, charging power, battery temperature, etc.\n\nMitigations for ‘Potential targets of, or motivations for, an attack’\n\nMitigations to the threats which are related to ‘Potential targets of, or motivations for, an attack’ are listed in Table B5.\n\nTable B5\n\nTable B5\n\nMitigations to the threats which are related to ‘Potential targets of, or motivations for, an attack’\n\nMitigations to the threats which are related to ‘Potential targets of, or motivations for, an attack’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats to ‘Potential targets of, or motivations for, an attack’\n\nThreats to ‘Potential targets of, or motivations for, an attack’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n19.1\n\n19.1\n\nExtraction of copyright or proprietary software from vehicle systems (product piracy / stolen software)\n\nExtraction of copyright or proprietary software from vehicle systems (product piracy / stolen software)\n\nM7\n\nM7\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n\n19.2\n\n19.2\n\nUnauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.\n\nUnauthorized access to the owner’s privacy information such as personal identity, payment account information, address book information, location information, vehicle’s electronic ID, etc.\n\nM8\n\nM8\n\nThrough system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Examples of Security Controls can be found in OWASP\n\nThrough system design and access control it should not be possible for unauthorized personnel to access personal or system critical data. Examples of Security Controls can be found in OWASP\n\n19.3\n\n19.3\n\nExtraction of cryptographic keys\n\nExtraction of cryptographic keys\n\nM11\n\nM11\n\nSecurity controls shall be implemented for storing cryptographic keys e.g. Security Modules\n\nSecurity controls shall be implemented for storing cryptographic keys e.g. Security Modules\n\n20.1\n\n20.1\n\nIllegal/unauthorised changes to vehicle’s electronic ID\n\nIllegal/unauthorised changes to vehicle’s electronic ID\n\nM7\n\nM7\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n\n20.2\n\n20.2\n\nIdentity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend\n\nIdentity fraud. For example, if a user wants to display another identity when communicating with toll systems, manufacturer backend\n\n20.3\n\n20.3\n\nAction to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)\n\nAction to circumvent monitoring systems (e.g. hacking/ tampering/ blocking of messages such as ODR Tracker data, or number of runs)\n\nM7\n\nM7\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n                                    Data manipulation attacks on sensors or transmitted data could be mitigated by correlating the data from different sources of information\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n\nData manipulation attacks on sensors or transmitted data could be mitigated by correlating the data from different sources of information\n\n20.4\n\n20.4\n\nData manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)\n\nData manipulation to falsify vehicle’s driving data (e.g. mileage, driving speed, driving directions, etc.)\n\n20.5\n\n20.5\n\nUnauthorised changes to system diagnostic data\n\nUnauthorised changes to system diagnostic data\n\n21.1\n\n21.1\n\nUnauthorized deletion/manipulation of system event logs\n\nUnauthorized deletion/manipulation of system event logs\n\nM7\n\nM7\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n\n22.2\n\n22.2\n\nIntroduce malicious software or malicious software activity\n\nIntroduce malicious software or malicious software activity\n\nM7\n\nM7\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP.\n\n23.1\n\n23.1\n\nFabrication of software of the vehicle control system or information system\n\nFabrication of software of the vehicle control system or information system\n\n24.1\n\n24.1\n\nDenial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging\n\nDenial of service, for example this may be triggered on the internal network by flooding a CAN bus, or by provoking faults on an ECU via a high rate of messaging\n\nM13\n\nM13\n\nMeasures to detect and recover from a denial of service attack shall be employed\n\nMeasures to detect and recover from a denial of service attack shall be employed\n\n25.1\n\n25.1\n\nUnauthorized access to falsify configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.\n\nUnauthorized access to falsify configuration parameters of vehicle’s key functions, such as brake data, airbag deployed threshold, etc.\n\nM7\n\nM7\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n\nAccess control techniques and designs shall be applied to protect system data/code. Example Security Controls can be found in OWASP\n\n25.2\n\n25.2\n\nUnauthorized access to falsify charging parameters, such as charging voltage, charging power, battery temperature, etc.\n\nUnauthorized access to falsify charging parameters, such as charging voltage, charging power, battery temperature, etc.\n\n6.\n\n6.\n\nMitigations for ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n                        Mitigations to the threats which are related to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’ are listed in Table B6.\n                        \n                           Table B6\n                        \n                        \n                           Mitigations to the threats which are related to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    26.1\n                                 \n                                 \n                                    Combination of short encryption keys and long period of validity enables attacker to break encryption\n                                 \n                                 \n                                    M23\n                                 \n                                 \n                                    Cybersecurity best practices for software and hardware development shall be followed\n                                 \n                              \n                              \n                                 \n                                    26.2\n                                 \n                                 \n                                    Insufficient use of cryptographic algorithms to protect sensitive systems\n                                 \n                              \n                              \n                                 \n                                    26.3\n                                 \n                                 \n                                    Using deprecated cryptographic algorithms\n                                 \n                              \n                              \n                                 \n                                    27.1\n                                 \n                                 \n                                    Hardware or software, engineered to enable an attack or fail to meet design criteria to stop an attack\n                                 \n                                 \n                                    M23\n                                 \n                                 \n                                    Cybersecurity best practices for software and hardware development shall be followed\n                                 \n                              \n                              \n                                 \n                                    28.1\n                                 \n                                 \n                                    The presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present\n                                 \n                                 \n                                    M23\n                                 \n                                 \n                                    Cybersecurity best practices for software and hardware development shall be followed.\n                                    Cybersecurity testing with adequate coverage\n                                 \n                              \n                              \n                                 \n                                    28.2\n                                 \n                                 \n                                    Using remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit an attacker to access ECUs or gain higher privileges\n                                 \n                              \n                              \n                                 \n                                    29.1\n                                 \n                                 \n                                    Superfluous internet ports left open, providing access to network systems\n                                 \n                              \n                              \n                                 \n                                    29.2\n                                 \n                                 \n                                    Circumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages\n                                 \n                                 \n                                    M23\n                                 \n                                 \n                                    Cybersecurity best practices for software and hardware development shall be followed.\n                                    Cybersecurity best practices for system design and system integration shall be followed\n\nMitigations for ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n\nMitigations to the threats which are related to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’ are listed in Table B6.\n\nTable B6\n\nTable B6\n\nMitigations to the threats which are related to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n\nMitigations to the threats which are related to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n\nThreats to ‘Potential vulnerabilities that could be exploited if not sufficiently protected or hardened’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n26.1\n\n26.1\n\nCombination of short encryption keys and long period of validity enables attacker to break encryption\n\nCombination of short encryption keys and long period of validity enables attacker to break encryption\n\nM23\n\nM23\n\nCybersecurity best practices for software and hardware development shall be followed\n\nCybersecurity best practices for software and hardware development shall be followed\n\n26.2\n\n26.2\n\nInsufficient use of cryptographic algorithms to protect sensitive systems\n\nInsufficient use of cryptographic algorithms to protect sensitive systems\n\n26.3\n\n26.3\n\nUsing deprecated cryptographic algorithms\n\nUsing deprecated cryptographic algorithms\n\n27.1\n\n27.1\n\nHardware or software, engineered to enable an attack or fail to meet design criteria to stop an attack\n\nHardware or software, engineered to enable an attack or fail to meet design criteria to stop an attack\n\nM23\n\nM23\n\nCybersecurity best practices for software and hardware development shall be followed\n\nCybersecurity best practices for software and hardware development shall be followed\n\n28.1\n\n28.1\n\nThe presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present\n\nThe presence of software bugs can be a basis for potential exploitable vulnerabilities. This is particularly true if software has not been tested to verify that known bad code/bugs is not present and reduce the risk of unknown bad code/bugs being present\n\nM23\n\nM23\n\nCybersecurity best practices for software and hardware development shall be followed.\n                                    Cybersecurity testing with adequate coverage\n\nCybersecurity best practices for software and hardware development shall be followed.\n\nCybersecurity testing with adequate coverage\n\n28.2\n\n28.2\n\nUsing remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit an attacker to access ECUs or gain higher privileges\n\nUsing remainders from development (e.g. debug ports, JTAG ports, microprocessors, development certificates, developer passwords, …) can permit an attacker to access ECUs or gain higher privileges\n\n29.1\n\n29.1\n\nSuperfluous internet ports left open, providing access to network systems\n\nSuperfluous internet ports left open, providing access to network systems\n\n29.2\n\n29.2\n\nCircumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages\n\nCircumvent network separation to gain control. Specific example is the use of unprotected gateways, or access points (such as truck-trailer gateways), to circumvent protections and gain access to other network segments to perform malicious acts, such as sending arbitrary CAN bus messages\n\nM23\n\nM23\n\nCybersecurity best practices for software and hardware development shall be followed.\n                                    Cybersecurity best practices for system design and system integration shall be followed\n\nCybersecurity best practices for software and hardware development shall be followed.\n\nCybersecurity best practices for system design and system integration shall be followed\n\n7.\n\n7.\n\nMitigations for ‘Data loss / data breach from vehicle’\n                        Mitigations to the threats which are related to ‘Data loss / data breach from vehicle’ are listed in Table B7.\n                        \n                           Table B7\n                        \n                        \n                           Mitigations to the threats which are related to ‘Data loss / data breach from vehicle’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats of ‘Data loss / data breach from vehicle’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    31.1\n                                 \n                                 \n                                    Information breach. Personal data may be breached when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)\n                                 \n                                 \n                                    M24\n                                 \n                                 \n                                    Best practices for the protection of data integrity and confidentiality shall be followed for storing personal data.\n\nMitigations for ‘Data loss / data breach from vehicle’\n\nMitigations to the threats which are related to ‘Data loss / data breach from vehicle’ are listed in Table B7.\n\nTable B7\n\nTable B7\n\nMitigations to the threats which are related to ‘Data loss / data breach from vehicle’\n\nMitigations to the threats which are related to ‘Data loss / data breach from vehicle’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats of ‘Data loss / data breach from vehicle’\n\nThreats of ‘Data loss / data breach from vehicle’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n31.1\n\n31.1\n\nInformation breach. Personal data may be breached when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)\n\nInformation breach. Personal data may be breached when the car changes user (e.g. is sold or is used as hire vehicle with new hirers)\n\nM24\n\nM24\n\nBest practices for the protection of data integrity and confidentiality shall be followed for storing personal data.\n\nBest practices for the protection of data integrity and confidentiality shall be followed for storing personal data.\n\n8.\n\n8.\n\nMitigations for ‘Physical manipulation of systems to enable an attack’\n                        Mitigation to the threats which are related to ‘Physical manipulation of systems to enable an attack’ are listed in Table B8.\n                        \n                           Table B8\n                        \n                        \n                           Mitigations to the threats which are related to ‘Physical manipulation of systems to enable an attack’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats to ‘Physical manipulation of systems to enable an attack’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    32.1\n                                 \n                                 \n                                    Manipulation of OEM hardware, e.g. unauthorised hardware added to a vehicle to enable ‘man-in-the-middle’ attack\n                                 \n                                 \n                                    M9\n                                 \n                                 \n                                    Measures to prevent and detect unauthorized access shall be employed\n\nMitigations for ‘Physical manipulation of systems to enable an attack’\n\nMitigation to the threats which are related to ‘Physical manipulation of systems to enable an attack’ are listed in Table B8.\n\nTable B8\n\nTable B8\n\nMitigations to the threats which are related to ‘Physical manipulation of systems to enable an attack’\n\nMitigations to the threats which are related to ‘Physical manipulation of systems to enable an attack’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats to ‘Physical manipulation of systems to enable an attack’\n\nThreats to ‘Physical manipulation of systems to enable an attack’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n32.1\n\n32.1\n\nManipulation of OEM hardware, e.g. unauthorised hardware added to a vehicle to enable ‘man-in-the-middle’ attack\n\nManipulation of OEM hardware, e.g. unauthorised hardware added to a vehicle to enable ‘man-in-the-middle’ attack\n\nM9\n\nM9\n\nMeasures to prevent and detect unauthorized access shall be employed\n\nMeasures to prevent and detect unauthorized access shall be employed\n\nPart C. Mitigations to the threats outside of vehicles\n\n1.\n\n1.\n\nMitigations for ‘Back-end servers’\n                        Mitigations to the threats which are related to ‘Back-end servers’ are listed in Table C1.\n\nMitigations for ‘Back-end servers’\n\nMitigations to the threats which are related to ‘Back-end servers’ are listed in Table C1.\n\nTable C1\n\nTable C1\n\nMitigations to the threats which are related to ‘Back-end servers’\n\nMitigations to the threats which are related to ‘Back-end servers’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats to ‘Back-end servers’\n\nThreats to ‘Back-end servers’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n1.1 & 3.1\n\n1.1 & 3.1\n\nAbuse of privileges by staff (insider attack)\n\nAbuse of privileges by staff (insider attack)\n\nM1\n\nM1\n\nSecurity Controls are applied to back-end systems to minimise the risk of insider attack\n\nSecurity Controls are applied to back-end systems to minimise the risk of insider attack\n\n1.2 & 3.3\n\n1.2 & 3.3\n\nUnauthorised internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n\nUnauthorised internet access to the server (enabled for example by backdoors, unpatched system software vulnerabilities, SQL attacks or other means)\n\nM2\n\nM2\n\nSecurity Controls are applied to back-end systems to minimise unauthorised access. Example Security Controls can be found in OWASP\n\nSecurity Controls are applied to back-end systems to minimise unauthorised access. Example Security Controls can be found in OWASP\n\n1.3 & 3.4\n\n1.3 & 3.4\n\nUnauthorised physical access to the server (conducted by for example USB sticks or other media connecting to the server)\n\nUnauthorised physical access to the server (conducted by for example USB sticks or other media connecting to the server)\n\nM8\n\nM8\n\nThrough system design and access control it should not be possible for unauthorised personnel to access personal or system critical data\n\nThrough system design and access control it should not be possible for unauthorised personnel to access personal or system critical data\n\n2.1\n\n2.1\n\nAttack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on\n\nAttack on back-end server stops it functioning, for example it prevents it from interacting with vehicles and providing services they rely on\n\nM3\n\nM3\n\nSecurity Controls are applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP\n\nSecurity Controls are applied to back-end systems. Where back-end servers are critical to the provision of services there are recovery measures in case of system outage. Example Security Controls can be found in OWASP\n\n3.2\n\n3.2\n\nLoss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers\n\nLoss of information in the cloud. Sensitive data may be lost due to attacks or accidents when data is stored by third-party cloud service providers\n\nM4\n\nM4\n\nSecurity Controls are applied to minimise risks associated with cloud computing. Example Security Controls can be found in OWASP and NCSC cloud computing guidance\n\nSecurity Controls are applied to minimise risks associated with cloud computing. Example Security Controls can be found in OWASP and NCSC cloud computing guidance\n\n3.5\n\n3.5\n\nInformation breach by unintended sharing of data (e.g. admin errors, storing data in servers in garages)\n\nInformation breach by unintended sharing of data (e.g. admin errors, storing data in servers in garages)\n\nM5\n\nM5\n\nSecurity Controls are applied to back-end systems to prevent data breaches. Example Security Controls can be found in OWASP\n\nSecurity Controls are applied to back-end systems to prevent data breaches. Example Security Controls can be found in OWASP\n\n2.\n\n2.\n\nMitigations for ‘Unintended human actions’\n                        Mitigations to the threats which are related to ‘Unintended human actions’ are listed in Table C2.\n                        \n                           Table C2\n                        \n                        \n                           Mitigations to the threats which are related to ‘Unintended human actions’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats relating to ‘Unintended human actions’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    15.1\n                                 \n                                 \n                                    Innocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack\n                                 \n                                 \n                                    M18\n                                 \n                                 \n                                    Measures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege\n                                 \n                              \n                              \n                                 \n                                    15.2\n                                 \n                                 \n                                    Defined security procedures are not followed\n                                 \n                                 \n                                    M19\n                                 \n                                 \n                                    Organizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions\n\nMitigations for ‘Unintended human actions’\n\nMitigations to the threats which are related to ‘Unintended human actions’ are listed in Table C2.\n\nTable C2\n\nTable C2\n\nMitigations to the threats which are related to ‘Unintended human actions’\n\nMitigations to the threats which are related to ‘Unintended human actions’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats relating to ‘Unintended human actions’\n\nThreats relating to ‘Unintended human actions’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n15.1\n\n15.1\n\nInnocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack\n\nInnocent victim (e.g. owner, operator or maintenance engineer) is tricked into taking an action to unintentionally load malware or enable an attack\n\nM18\n\nM18\n\nMeasures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege\n\nMeasures shall be implemented for defining and controlling user roles and access privileges, based on the principle of least access privilege\n\n15.2\n\n15.2\n\nDefined security procedures are not followed\n\nDefined security procedures are not followed\n\nM19\n\nM19\n\nOrganizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions\n\nOrganizations shall ensure security procedures are defined and followed including logging of actions and access related to the management of the security functions\n\n3.\n\n3.\n\nMitigations for ‘Physical loss of data’\n                        Mitigations to the threats which are related to ‘Physical loss of data’ are listed in Table C3.\n                        \n                           Table C3\n                        \n                        \n                           Mitigations to the threats which are related to ‘Physical loss of data’\n                        \n                        \n                           \n                           \n                           \n                           \n                           \n                              \n                                 \n                                    Table A1 reference\n                                 \n                                 \n                                    Threats of ‘Physical loss of data’\n                                 \n                                 \n                                    Ref\n                                 \n                                 \n                                    Mitigation\n                                 \n                              \n                              \n                                 \n                                    30.1\n                                 \n                                 \n                                    Damage caused by a third party. Sensitive data may be lost or compromised due to physical damages in cases of traffic accident or theft\n                                 \n                                 \n                                    M24\n                                 \n                                 \n                                    Best practices for the protection of data integrity and confidentiality shall be followed for storing personal data. Example Security Controls can be found in ISO/SC27/WG5\n                                 \n                              \n                              \n                                 \n                                    30.2\n                                 \n                                 \n                                    Loss from DRM (digital right management) conflicts. User data may be deleted due to DRM issues\n                                 \n                              \n                              \n                                 \n                                    30.3\n                                 \n                                 \n                                    The (integrity of) sensitive data may be lost due to IT components wear and tear, causing potential cascading issues (in case of key alteration, for example)\n\nMitigations for ‘Physical loss of data’\n\nMitigations to the threats which are related to ‘Physical loss of data’ are listed in Table C3.\n\nTable C3\n\nTable C3\n\nMitigations to the threats which are related to ‘Physical loss of data’\n\nMitigations to the threats which are related to ‘Physical loss of data’\n\nTable A1 reference\n\nTable A1 reference\n\nThreats of ‘Physical loss of data’\n\nThreats of ‘Physical loss of data’\n\nRef\n\nRef\n\nMitigation\n\nMitigation\n\n30.1\n\n30.1\n\nDamage caused by a third party. Sensitive data may be lost or compromised due to physical damages in cases of traffic accident or theft\n\nDamage caused by a third party. Sensitive data may be lost or compromised due to physical damages in cases of traffic accident or theft\n\nM24\n\nM24\n\nBest practices for the protection of data integrity and confidentiality shall be followed for storing personal data. Example Security Controls can be found in ISO/SC27/WG5\n\nBest practices for the protection of data integrity and confidentiality shall be followed for storing personal data. Example Security Controls can be found in ISO/SC27/WG5\n\n30.2\n\n30.2\n\nLoss from DRM (digital right management) conflicts. User data may be deleted due to DRM issues\n\nLoss from DRM (digital right management) conflicts. User data may be deleted due to DRM issues\n\n30.3\n\n30.3\n\nThe (integrity of) sensitive data may be lost due to IT components wear and tear, causing potential cascading issues (in case of key alteration, for example)\n\nThe (integrity of) sensitive data may be lost due to IT components wear and tear, causing potential cascading issues (in case of key alteration, for example)",
+      "chapter": "Annexes"
+    }
+  ],
+  "definitions": [
+    {
+      "term": "vehicle type",
+      "definition": "vehicles which do not differ in at least the following essential respects: (a) The manufacturer's designation of the vehicle type; (b) Essential aspects of the electric/electronic architecture and external interfaces with respect to cybersecurity. 'Vehicle type' means vehicles which do not differ in at least the following essential respects: (a) (a) The manufacturer's designation of the vehicle type; The manufacturer's designation of the vehicle type; (b) (b) Essential aspects of the electric/electronic architecture and external interfaces with respect to cybersecurity. Essential aspects of the electric/electronic architecture and external interfaces with respect to cybersecurity",
+      "article": "2"
+    },
+    {
+      "term": "cybersecurity",
+      "definition": "the condition in which road vehicles and their functions are protected from cyber threats to electrical or electronic components. 'Cybersecurity' means the condition in which road vehicles and their functions are protected from cyber threats to electrical or electronic components",
+      "article": "2"
+    },
+    {
+      "term": "cybersecurity management system (csms)",
+      "definition": "a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks. 'Cybersecurity Management System (CSMS)' means a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks",
+      "article": "2"
+    },
+    {
+      "term": "system",
+      "definition": "a set of components and/or sub-systems that implements a function or functions. 'System' means a set of components and/or sub-systems that implements a function or functions",
+      "article": "2"
+    },
+    {
+      "term": "development phase",
+      "definition": "the period before a vehicle type is type approved. 'Development phase' means the period before a vehicle type is type approved",
+      "article": "2"
+    },
+    {
+      "term": "production phase",
+      "definition": "the duration of production of a vehicle type. 'Production phase' refers to the duration of production of a vehicle type",
+      "article": "2"
+    },
+    {
+      "term": "post-production phase",
+      "definition": "the period in which a vehicle type is no longer produced until the end-of-life of all vehicles under the vehicle type. Vehicles incorporating a specific vehicle type will be operational during this phase but will no longer be produced. The phase ends when there are no longer any operational vehicles of a specific vehicle type. 'Post-production phase' refers to the period in which a vehicle type is no longer produced until the end-of-life of all vehicles under the vehicle type. Vehicles incorporating a specific vehicle type will be operational during this phase but will no longer be produced. The phase ends when there are no longer any operational vehicles of a specific vehicle type",
+      "article": "2"
+    },
+    {
+      "term": "mitigation",
+      "definition": "a measure that is reducing risk. 'Mitigation' means a measure that is reducing risk",
+      "article": "2"
+    },
+    {
+      "term": "risk",
+      "definition": "the potential that a given threat will exploit vulnerabilities of a vehicle and thereby cause harm to the organization or to an individual. 'Risk' means the potential that a given threat will exploit vulnerabilities of a vehicle and thereby cause harm to the organization or to an individual",
+      "article": "2"
+    },
+    {
+      "term": "risk assessment",
+      "definition": "the overall process of finding, recognizing and describing risks (risk identification), to comprehend the nature of risk and to determine the level of risk (risk analysis), and of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable (risk evaluation). 'Risk Assessment' means the overall process of finding, recognizing and describing risks (risk identification), to comprehend the nature of risk and to determine the level of risk (risk analysis), and of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable (risk evaluation)",
+      "article": "2"
+    },
+    {
+      "term": "risk management",
+      "definition": "coordinated activities to direct and control an organization with regard to risk. 'Risk Management' means coordinated activities to direct and control an organization with regard to risk",
+      "article": "2"
+    },
+    {
+      "term": "threat",
+      "definition": "a potential cause of an unwanted incident, which may result in harm to a system, organization or individual. 'Threat' means a potential cause of an unwanted incident, which may result in harm to a system, organization or individual",
+      "article": "2"
+    },
+    {
+      "term": "vulnerability",
+      "definition": "a weakness of an asset or mitigation that can be exploited by one or more threats. 'Vulnerability' means a weakness of an asset or mitigation that can be exploited by one or more threats",
+      "article": "2"
+    }
+  ]
+}