Automotive cybersecurity standards – a living list

Last updated, January 2022

Safe and secure transportation relies on a foundation of recommendations and guidance.

This is the home of our automotive cybersecurity standards living list. As mentioned in our Overview of the automotive cybersecurity standards landscape, we have identified a long list of documents either supporting or directly related to automotive cybersecurity, which can be broadly classified into the following groups:  

  • Recommendations directly addressing automotive security  
  • Extensions to safety considerations  
  • Coding and software standards  
  • General foundations

The individual entries (numbered) are detailed below, including external recommendations that are referenced within each of the documents, when applicable and where the information is available to view publicly. Additional notes and comments can also be found in the list to further aid understanding.

  • Recommendations directly addressing automotive security 

1 – ISO/SAE 21434:2021, Road Vehicles – Cybersecurity Engineering
Lists engineering requirements for cybersecurity risk management, including threat modelling, so that organisations operating in the automotive sector are better placed to tackle evolving attack methods. Note that the document does not prescribe specific technologies or solutions.

External references within the recommendation: 
ISO 31000, Risk management – Guidelines 
ISO 26262-3:2018, Road vehicles – Functional Safety – Part 3: Concept phase

2 – ISO/DPAS 5112 – Road vehicles — Guidelines for auditing cybersecurity engineering 
Under development. The guidelines are based on ISO 21434 (see 1) and intended to be used to audit a cybersecurity management system as defined by UNECE WP.29 regulations (see 7).

3 – SAE J3101 – Hardware Protected Security for Ground Vehicles J3101_202002 (2020)
The standard provides a perspective on security mechanisms supported in hardware for automotive use cases, along with best practices for using such mechanisms. Such hardware-based approaches are necessary to ensure that systems are able to resist attacks that would otherwise defeat software-only based implementations.

4 – SAE J3061 – Cybersecurity Guidebook for Cyber-Physical Vehicle Systems J3061_201601 (2016)
Recommendations cover the complete vehicle lifecycle from concept phase through production, operation, service and decommissioning. The standard is a precursor to ISO 21434 and calls for a lifecycle approach to cybersecurity engineering. As mentioned in our overview article, efforts are underway to re-work SAE J3061 and it has been reported that the new version will be in three parts. Part 1 will describe a threat and risk analysis method for classifying threats within an Automotive cybersecurity Integrity Level (AcSIL) framework. Part 2 will give an overview of security testing methods for software and hardware. And part 3 will discuss security tools. The new document set should provide a more technical companion to ISO 21434.

5 – UK Government’s Key Principles of Cyber Security for Connected and Automated Vehicles 
Published in August 2017 and created by the UK’s Department for Transport, in conjunction with Centre for the Protection of National Infrastructure (CPNI), the guidance is split into eight key principles — each with sub-details — to support all parties in the manufacturing supply chain in tightening automotive cybersecurity. Topics include taking ownership of organisational security, the importance of using a defence-in-depth design approach as well as performing appropriate management and assessment of risk, securing and controlling the storage and transmission of data, and the need for product aftercare and incident response to ensure that systems are secure over their lifetime.

External references within the recommendation: 
SAE 
J3061 – Cybersecurity guidebook for cyber-physical vehicle systems
J3101 – Requirements for hardware protected security for ground vehicle applications
ISO
9797-1 – Security techniques: message authentication codes – specifies a model for secure message authentication codes using block cyphers and asymmetric keys
12207 – Systems and software engineering – software lifecycle processes
15408 – Evaluation of IT security – specifies a model for evaluating security aspects within IT
27001 – Information security management system
27002 – Code of practice – security – provides recommendations for information management (contains guidance on access control, cryptography and supplier relationship)
27010 – Information security management for inter-sector and inter-organizational communications
27018 – Code of practice – handling PII / SPI (privacy) – protection of personally identifiable information (PII) in public clouds
27034 – Application security techniques – guidance to ensure software delivers necessary level of security in support of an organisations security management system
27035 – Information security incident management
29101 – Privacy architecture framework
29119 – Software testing standard
DEFSTAN
05-138 – Cyber security for defence suppliers
NIST
800-30 – Guide for conducting risk assessments
800-88 – Guidelines for media sanitization
SP 800-50 – Building an information technology security awareness and training program
SP 800-61 – Computer security incident handling guide
Other
Microsoft security development lifecycle (SDL)
SAFE Code best practices
OWASP Comprehensive, lightweight application security process (CLASP)
HMG Security policy framework
PAS 1192-5 – BSI publication on security-minded building information modelling, digital built environments and smart asset management (Withdrawn and replaced with BS EN ISO 19650-5)
BS EN ISO 19650-5:2020 – Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM). Information management using building information modelling. Security-minded approach to information management
PAS 754 – BSI publication on software trustworthiness, governance and management (Withdrawn following the publication of BS 10754-1:2018)
BS 10754-1:2018 – Information technology. Systems trustworthiness. Governance and management specification
BS ISO/IEC 11179-5, BS ISO/IEC/IEEE 15288:2015, BS EN ISO/IEC 27002, BS ISO/IEC/IEEE 42010, BS EN ISO/IEC 27001

6 – BSI PAS 1885 (The fundamental principles of automotive cyber security – specification) 
Intended for vehicle manufacturers, tier-1 and tier-2 suppliers, authorised service centres, aftermarket suppliers, road/highway authorities and service providers to both the vehicle and its occupants and/or cargo, the recommendations are aimed at helping all parties involved in the vehicle lifecycle and ecosystem improve their understanding of how to maintain vehicle security and the security of associated intelligent transport systems (ITS).

External references within the recommendation:
BS ISO 55002, IEC 62443, PAS 555, BS 7858, BS ISO 55000, BS ISO/IEC 29100, ETSI TR 102 893, BS ISO 26262, BS ISO/IEC 27001, PAS 1192-5:2015, BS EN ISO/IEC 27001:2017, BS 10010:2017, PAS 183:2017, BS ISO/IEC 38505-1:2017, PAS 185:2017, PAS 754:2014, PAS 555:2013, BS EN ISO 15118-1:2015, BS ISO/IEC 15408-1:2009, BS ISO 55001:2014, PAS 11281:2018, BS ISO/IEC 38500:2015, BS ISO/IEC 27032:2012 

7 – UNECE WP.29: UN Regulation No. 155 – 2021 
The regulations require that automotive providers have a cybersecurity management system (CSMS) in place for the lifetime of the vehicle. Vehicle categories include passenger cars, vans, trucks and buses, and light four-wheeler vehicles if equipped with automated driving functionalities from level 3 onwards (this is to cover new automated pods and shuttles as well as trailers, if fitted with at least one electronic control unit).

From a threat analysis and risk assessment perspective, it is noteworthy that the guidance specifies a baseline for threats, vulnerabilities and attack methods (available in Annex 5 of the document) that should be considered and defended against.

To sell into the markets where UNECE WP.29 regulations apply, manufacturers will have to demonstrate to national technical services or homologation authorities (who will likely base their audits on ISO/DPAS 5112) that they fulfil the following requirements: 

– Cyber Security Management System is in place and its application to vehicles on the road is available;
– Provide risk assessment analysis, identify what is critical;
– Mitigation measures to reduce risks are identified;
– Evidence, through testing, that mitigation measures work as intended;
– Measures to detect and prevent cyber-attacks are in place;
– Measures to support data forensics are in place;
– Monitor activities specific for the vehicle type;
– Reports of monitoring activities will be transmitted to the relevant homologation authority.  

External references within the recommendation:
ISO 26262-2018, ISO/PAS 21448, ISO/SAE 21434   

8 – UNECE WP.29: Draft Recommendation on Software Updates of the Task Force on Cyber Security and Over-the-air issues
The document provides information on managing software updates so that they can be performed safely and securely over-the-air; noting the increased importance (given the rising number of software elements in a vehicle) of being able to implement software corrections and add new features without the hassle and expense of recalling models to dealerships.  

Vehicle manufacturers will need to obtain a certificate of compliance for their software update management system (SUMS) – much like they will need to for their cybersecurity management system (CSMS). 

9 – ITU-T X.1373 : Secure software update capability for intelligent transportation system communication devices
Offers practical advice that can be used by car manufacturers and ITS-related industries regarding secure software update procedures between a software update server and vehicles with appropriate security controls.  

External references within the recommendation: 
ITU-T X.509, ITU-T X.1521, ISO/IEC 15408-1, ISO/IEC 27000:2014

10 – ENISA good practices for security of Smart Cars (2019)
Created to help promote cybersecurity for connected and automated cars across Europe, the report raises awareness on relevant threats and risks with a focus on “cybersecurity for safety”. 

External references within the recommendation: 
ETSI TS 102 940 v1.3.1, “Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management
ETSI TS 102 941 V1.2.1 “Intelligent Transport Systems (ITS); Security; Trust and Privacy Management
ETSI TS 102 942 V1.1.1 “Intelligent Transport Systems (ITS); Security; Access Control”
ETSI TS 102 943 V1.1.1 “Intelligent Transport Systems (ITS); Security; Confidentiality services”
SAE J3061 “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems
SAE J3016 “Taxonomy and Definitions for Terms Related to Driving Automations Systems for On-Road Motor Vehicles”
ISO/SAE CD 21434 “Road Vehicles – Cybersecurity engineering
Auto-ISAC “Automotive Cybersecurity Best Practices – Executive summary”
ITF/OECD “Safer Roads with Automated Vehicles”
PAS 1885:2018 The fundamental principles of automotive cyber security specification, bsi
IEC – IEC 62443-3-3:2013 System security requirements and security levels
ISO – ISO/IEC 27001:2013 Information technology — Security techniques – Information security management systems – Requirements
ISO – ISO/IEC 27002:2013 Information technology — Security techniques — Code of practice for information security controls
NIST – NIST SP 800 53r4: Security and Privacy Controls for Federal Information Systems and Organizations
NIST – NISTIR 8183: Cybersecurity Framework Manufacturing Profile
SANS Institute – Vulnerability Management: Tools, Challenges and Best Practices
NIST – Draft NISTIR 8228: Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks
NIST – NIST SP 800 30r1 – Guide for Conducting Risk Assessments
NIST – NIST SP 800 82r2: Guide to Industrial Control Systems (ICS) Security
ETSI – ETSI TR 102 893 V1.2.1 — Intelligent Transport Systems: Security, Threat, Vulnerability and Risk Analysis
International Telecommunications Union – Security capabilities supporting safety of the Internet of things
Five Star Automotive Cyber Safety Program
IEC – IEC 62443-2-1:2010 Establishing an industrial automation and control system security program
PRESERVE – Security Requirements of Vehicle Security Architecture v1.1
NIST – NIST SP 800-146 Cloud Computing Synopsis and Recommendations
oneM2M – Standards for M2M and the Internet of Things – TR 0008 Security V2.0.0 – Security. Technical Report

11 – TR 68 – 3 : 2019, Technical Reference for Autonomous vehicles – Part 3 : Cybersecurity principles and assessment (Singapore) 
Describes a framework for assessing the cybersecurity of Autonomous Vehicles deployed on public roads.

External references within the recommendation:
GSMA CLP.11 – IoT security guidelines and CLP.17 IoT Security Assessment
ISO/IEC 19790:2012 – Information technology – Security techniques – Security requirements for cryptographic modules.
ISO/IEC 26262 series – Road vehicles – Functional safety
ISO/IEC 27000 series – Information technology – Security techniques – Information security management systems – Overview and vocabulary
ISO/SAE 21434 – Road vehicles – Cybersecurity Engineering
NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment, 2008
OWASP Open Web Application Security Project
SAE J3016 – Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles
SAE J3061 – Cybersecurity Guidebook for Cyber-Physical Vehicle Systems
WP.29 – UNECE ITS/AD CS/OTA
TR 64: 2018 Guidelines for IoT Security for Smart Nation  

12 – US DoT NHTSA Cybersecurity Best Practices for the Safety of Modern Vehicles (Draft 2020 update) 
Updates the Agency’s non-binding and voluntary guidance to the automotive industry for improving motor vehicle cybersecurity.

External references within the recommendation:
ISO 21434
ISO/IEC 29147:2018, Information Technology Security Techniques Vulnerability Disclosure   

13 – US H.R.701 – SPY Car Study Act 
The ‘Security and privacy in your car’ act was proposed in the US (originally in 2015 and then reintroduced in 2017 and 2019) to determine appropriate cybersecurity standards for motor vehicles, and for other purposes. The bill in its earlier forms requires the National Highway Traffic Safety Administration to report on standards for the regulation of the cybersecurity of motor vehicles manufactured or imported for sale in the United States. And, more recently, has cast its attention on consumer needs and driving data (see below).

2017 

2019 

In this version, the bill directs the NHTSA to ‘require the fuel economy labelling that manufacturers attach to motor vehicles to display a cyber dashboard with a standardized graphic to inform consumers about the extent to which the vehicle protects individuals’ cybersecurity and privacy beyond the minimum requirements’. 

There is also an additional focus on so-called driving data – defined as ‘any electronic information collected about the status of the vehicle, including the location and speed of the vehicle; and any owner, lessee, driver or passenger of a vehicle’. The 2019 version directs the Federal Trade Commission to ‘require manufacturers to notify owners or lessees about the collection, retention and use of driving data and provide an option to terminate such data collection and retention, and to prohibit manufacturers from using such data for advertising or marketing without the owner’s or lessee’s consent’. 

  • Extensions to safety considerations 

ISO 26262 series and related
The series, derived from IEC 61508, comprise a functional safety standard targeting the lifecycle of automotive equipment and systems. The approach features the use of an ‘Automotive Safety Integrity Level’ ASIL, which ranges from A (least strict) to D (most strict). Annex E of ISO 26262 gives guidance on the interaction between safety and cybersecurity. Edition 3 (in discussion) could contain more details on security-aware safety topics.

14 – ISO 26262-1:2018 Road vehicles — Functional safety — Part 1: Vocabulary 

External references within the recommendation:
ISO 26262 (all parts), Road vehicles — Functional safety   

15 – ISO 26262-2:2018 Road vehicles — Functional safety — Part 2: Management of functional safety 

External references within the recommendation: 
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses  

16 – ISO 26262-3:2018 Road vehicles — Functional safety — Part 3: Concept phase 

External references within the recommendation:
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses  

17 – ISO 26262-4:2018 Road vehicles — Functional safety — Part 4: Product development at the system level 

External references within the recommendation:
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses  

18 – ISO 26262-5:2018 Road vehicles — Functional safety — Part 5: Product development at the hardware level 

External references within the recommendation:
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses  

19 – ISO 26262-6:2018 Road vehicles — Functional safety — Part 6: Product development at the software level 

External references within the recommendation: 
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

20 – ISO 26262-7:2018 Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning 

External references within the recommendation: 
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

21 – ISO 26262-8:2018 Road vehicles — Functional safety — Part 8: Supporting processes 

External references within the recommendation:
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses  

22 – ISO 26262-9:2018 Road vehicles — Functional safety — Part 9: Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses 

External references within the recommendation: 
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes

23 – ISO 26262-10:2018 Road vehicles — Functional safety — Part 10: Guidelines on ISO 26262 

External references within the recommendation:
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary  

24 – ISO 26262-11:2018 Road vehicles — Functional safety — Part 11: Guidelines on application of ISO 26262 to semiconductors 

External references within the recommendation:
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary  

25 – ISO 26262-12:2018 Road vehicles — Functional safety — Part 12: Adaptation of ISO 26262 for motorcycles 

External references within the recommendation: 
ISO 26262-1, Road vehicles — Functional safety — Part 1: Vocabulary
ISO 26262-2:2018, Road vehicles — Functional safety — Part 2: Management of functional safety
ISO 26262-3:2018, Road vehicles — Functional safety — Part 3: Concept phase
ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level
ISO 26262-5:2018, Road vehicles — Functional safety — Part 5: Product development at the hardware level
ISO 26262-6:2018, Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262-7:2018, Road vehicles — Functional safety — Part 7: Production, operation, service and decommissioning
ISO 26262-8:2018, Road vehicles — Functional safety — Part 8: Supporting processes
ISO 26262-9:2018, Road vehicles — Functional safety — Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

26 – SAE J2980_201804: Considerations for ISO 26262 ASIL Hazard Classification
A companion to ISO 26262, J2980 gives a method together with examples of determining the Automotive Safety Integrity Level (ASIL) for automotive motion control electrical and electronic (E/E) systems – limited to passenger cars weighing up to 3.5 metric tons. Note that the document prioritises collision-related hazards associated with motion control systems as these scenarios tend to generate higher ratings.

External references within the recommendation: 
ISO 26262 series

27 – ISO/PAS 21448:2019 Road vehicles — Safety of the intended functionality
The guidance — which was originally going to be a section of ISO 26262, but has since been published as its own standard — considers intended use and reasonably foreseeable misuse together with potentially hazardous system behaviour as inputs to design, verification and validation measures that together provide ‘safety of the intended functionality’ (SOTIF).   

External references within the recommendation:
ISO 26262-1:2018, Road vehicles — Functional Safety Part 1: Vocabulary  

28 – UK Code of Practice: Automated vehicle trialling
Published in 2019, the code requires that software is tested and appropriate measures are in place to manage data security and the risk of unauthorised data access – among a long list of other requirements. Vehicle manufacturers and organisations providing systems for trial in the UK are recommended to follow the UK Government’s Key Principles of Cyber Security for Connected and Automated Vehicles (see 5).

29 – PAS 11281:2018 (Connected automotive ecosystems. Impact of security on safety. Code of practice)
Not directly referenced by the UK code of practice (see 28), but can be considered as related guidance as the recommendations concern the management of security risks that might compromise safety in a connected automotive ecosystem.  

External references within the recommendation:
BS ISO/IEC 29147, BS ISO 26262, ISO 10393, BS 10754, PAS 1885, BS EN IEC 62443, BS ISO/IEC 27035, BS ISO 20077-1, IEC 61508:2011, BS ISO 55000, BS EN ISO/IEC 27042, BS EN ISO/IEC 27037, PAS 1085, BS ISO/IEC/IEEE 15288, IEC 61511-1, BS ISO 28000, PD ISO/IEC TS 17961:2013, BS EN ISO/IEC 27002:2017, BS EN ISO 22300:2018, BS ISO/IEC 15026-2:2011, PD ISO/IEC GUIDE 51:2014, PAS 1192-5:2015, PD ISO/IEC TR 24772:2013, BS ISO 26021-2:2008, BS ISO/IEC 27032:2012, BS ISO 14229-1:2013 

30 – General foundations AEC-Q100 series 
The series establishes electrical qualification requirements for components deployed in the harsh conditions of an automotive environment.

External references within the recommendation: 
SAE J1752/3 Integrated Circuits Radiated Emissions Measurement Procedure
MIL-STD-883 Test Methods and Procedures for Microelectronics
MIL-STD-750 Test Methods for Semiconductor Devices
JEDEC JESD-22 Reliability Test Methods for Packaged Devices
UL-STD-94 Tests for Flammability of Plastic materials for parts in Devices and Appliances
IPC/JEDEC J-STD-020 Moisture/Reflow Sensitivity Classification for Plastic Integrated Circuit
Surface Mount Devices – JESD89 Measurement and Reporting of Alpha Particle and Terrestrial Cosmic Ray-Induced Soft
Errors in Semiconductor Devices – JESD89-1 System Soft Error Rate (SSER) Test Method; JESD89-2 Test Method For Alpha Source Accelerated Soft Error Rate; JESD89-3 Test Method for Beam Accelerated Soft Error Rate

  • Coding and software guidelines 

Automobiles have been accumulating lines of code for some time, primarily in the electronic control units that reside within the vehicle. But greater connectivity, an increase in driver assistance, more data-enabled services and a switch from fossil fuels to electric power will see software play an even wider role in the sector.  

Given this trend in new vehicles – sometimes dubbed CASE by analysts, referring to ‘Connected’, ‘Autonomous’, ‘Shared & Services’ and ‘Electric’ aspects of the future vehicle landscape – it will be more important than ever for OEMs and their suppliers to adopt secure coding practices. At the same time, developers will need to track not just their own code, but all software versions that are deployed in their products so that security patches can be applied when vulnerabilities come to light. 

31 – ISO/TR 15497:2000, Road vehicles — Development guidelines for vehicle based software
Aimed at automotive software engineers, managers and other stakeholders relating to embedded vehicle software – the recommendations consider a range of issues, including diagnostics and integrated vehicle systems; integrity; noise; EMC; real-time performance; control systems software; metrics; verification and validation; and subcontracting of software development.

MISRA 
Originally formed to develop guidelines for creating automotive software, the MISRA consortium offers best practice applicable to both embedded control systems and standalone software.

32 – MISRA C: 1998 

Written for C90, has 127 coding rules. 

33 – MISRA C: 2004 

Written for C90, has 142 coding rules. 

34 – MISRA C++: 2008 

Guidelines produced for C++ in recognition of its growing use in the field 

35 – MISRA C: 2012 

Extends support to C99, while maintaining guidelines for C90, has 143 coding rules. 

36 – MISRA C: 2012 Amendment 1 (released 2016) 

Includes 156 rules and 17 directives, giving a total of 173 guidelines. 

37 – MISRA C: 2012 Amendment 2 (released 2020) 

Two additional rules, taking the total number of guidelines up to 175. 

38 – MISRA C:2012 — Addendum 2  

Mapping of MISRA rules to the C Secure rules in ISO/IEC TS 17961:2013. 

39 – MISRA C:2012 — Addendum 3  

Mapping of MISRA rules to the CERT C rules. 

Further events – MISRA to merge C++ guidelines with AUTOSAR 

40 – ASPICE – Automotive SPICE Process Reference Model Process Assessment Model Version 3.1 (2017)
A framework for quality management in the automotive sector.

External references within the recommendation:
ISO/IEC 33001:2015, ISO/IEC 33002:2015, ISO/IEC 33003:2015, ISO/IEC 33004:2015, ISO/IEC 33020:2015, ISO/IEC 15504-5:2006, ISO/IEC 12207:2008, ISO/IEC/IEEE 29119-1:2013, ISO/IEC/IEEE 29119-3:2013 So, ISO/IEC/IEEE 24765:2010 S, ISO/IEC 25010:2011, ISO/IEC 12207, ISO/IEC 15288 

41 – IATF 16949:2016
An alternative to ASPICE (see 40), the recommendations provide a standard for quality management to be used in conjunction with ISO 9001:2015.  

42 – NTIA software component transparency
The US National Telecommunications and Information Administration (NTIA) are working with the automotive sector to report on ‘Supplier recommendations for industry standards to automakers’ over the next 12 months.   

NTIA provides guidance on how to produce, deliver, update and consume SBOMs through its survey document.

External references within the recommendation: 
ISO/IEC 19770-2:2015: Information Technology – Software Asset Management – Part 2: Software Identification Tag
ISO/IEC TS 17961:2013 Information technology — Programming languages, their environments and system software interfaces — C secure coding rules
SEI CERT C Coding Standard
ISO/IEC 5055:2021 Information technology — Software measurement — Software quality measurement — Automated source code quality measures
ISO/IEC 25000:2014 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE

  • General foundations 

43 – BS 10754-1:2018 (Information technology – Systems trustworthiness. Governance and management specification) 
A widely applicable approach to improving the trustworthiness of systems, software and services.

External references within the recommendation:
BS ISO/IEC 11179-5, BS ISO/IEC/IEEE 15288:2015, BS EN ISO/IEC 27002, BS ISO/IEC/IEEE 42010, BS EN ISO/IEC 27001, ITU-T Recommendation X.1520, BS ISO 31000, BS ISO/IEC 19770-1, BS EN ISO/IEC 27000, BS EN ISO/IEC 17024, ITU-T Recommendation X.1521, ITU-T Recommendation X.1525, BIP 0008-1, BS EN 61508 (all parts), BS ISO/IEC 20000-1, BS EN ISO/IEC 17043, BS EN ISO 9001, BS ISO/IEC 15408-1, BS ISO/IEC 19770-2, BS ISO/IEC 27034-1, BS ISO/IEC 15504 (all parts), ITU-T Recommendation X.1544, BS EN ISO/IEC 17025, ITU-T Recommendation X.1524, BS ISO/IEC 33001:2015, BS EN ISO 22301:2014, BS EN ISO 9000:2015, BS EN ISO/IEC 27043:2016 

44 – BS EN IEC 60812:2018 Failure modes and effects analysis (FMEA and FMECA)
Considers the planning, performance, documentation and maintenance of FMEA to raise awareness of how an item or process might fail to perform its function and the treatments that could be applied.

External references within the recommendation:
IEC 60050-192 – International electrotechnical vocabulary – Part 192: Dependability

45 – BS EN IEC 61025. Fault tree analysis (FTA) 
Comments are being invited for the upcoming version, which like the current document will support the identification and analysis of combinations of conditions and factors that risk the occurrence of undesirable outcomes, or ‘top events’.

BS EN 61508 series
Methods concerning the application, design, deployment and maintenance of safety-related systems, applicable to a wide range of industries. Note that IEC 61508 formed the basis for ISO 26262. 

46 – BS EN 61508-1:2010. Functional safety of electrical/electronic/ programmable electronic safety-related systems. General requirements 

47 – BS EN 61508-2:2010. Functional safety of electrical/electronic/ programmable electronic safety-related systems. Requirements for electrical/electronic/ programmable electronic safety-related systems 

48 – BS EN 61508-3:2010. Functional safety of electrical/electronic/ programmable electronic safety-related systems. Software requirements 

49 – BS EN 61508-4:2010. Functional safety of electrical/electronic/ programmable electronic safety related systems. Definitions and abbreviations 

50 – BS EN 61508-5:2010. Functional safety of electrical/electronic/ programmable electronic safety related systems. Examples of methods for the determination of safety integrity levels 

51 – BS EN 61508-6:2010. Functional safety of electrical/electronic/ programmable electronic safety related systems. Guidelines on the application of IEC 61508-2 and IEC 61508-3 

52 – BS EN 61508-7:2010. Functional safety of electrical/electronic/ programmable electronic safety related systems. Overview of techniques and measures 

IEC TR 62443 series
Devised to support the secure operation of industrial automation and control systems, the guidance notes that cyberattacks on critical infrastructure can put public health at risk and threaten the environment. Recommendations focus not just on the technology, but also on the work processes, countermeasures and employee roles.

53 – IEC 62443-2-1:2010. Industrial communication networks – Network and system security – Part 2-1: Establishing an industrial automation and control system security program

External references within the recommendation:
IEC/TS 62443?1?12 – Industrial communication networks – Network and system security – Part 1-1: Terminology, concepts and models

54 – IEC TR 62443-2-3:2015. Security for industrial automation and control systems – Part 2-3: Patch management in the IACS environment 

External references within the recommendation:
IEC TS 62443-1-1, Industrial communication networks – Network and system security – Part 1-1: Terminology, concepts and models
IEC 62443-2-1, Industrial communication networks – Network and system security – Part 2-1: Establishing an industrial automation and control system security program

55 – IEC 62443-2-4:2015+AMD1:2017 CSV. Consolidated version. Security for industrial automation and control systems – Part 2-4: Security program requirements for IACS service providers 

56 – IEC TR 62443-3-1:2009. Industrial communication networks – Network and system security – Part 3-1: Security technologies for industrial automation and control systems 

An overview of the automotive cybersecurity standards landscape

The advent of numerous wireless connections and telemetry services has extended the attack surface of a modern vehicle far beyond its physical boundary. What’s more, as automakers strive to meet the expectations of a fully autonomous driving experience, future cars will need to rely even more heavily on the data around them – adding to the number of potential entry points for bad actors.

Connected future: vehicles are relying more heavily on the data around them.

Details provided by onboard sensors, V2X sources such as nearby vehicles and road infrastructure, and data centres in the cloud will need to be validated, for example, as studies have shown that systems can be vulnerable to spoofed information. The proliferation of new interfaces, external connections, protocols and technologies increases the attack surface and multiplies the potential number of exploitable vulnerabilities substantially.

Guidelines must adapt to protect drivers, passengers and other road users against new vehicle attacks. And, over time, the automotive industry has augmented its standards landscape – most recently with the publication of ISO SAE 21434 “Road Vehicles – Cybersecurity engineering” in 2021 and before that the adoption of UNECE WP29 (World Forum for Harmonization of Vehicle Regulations) proposals covering the management of automotive cybersecurity (R155) and software updates (R156) – with a number of security requirements.

These include establishing a baseline for threats, vulnerabilities and attack methods, and a requirement for OEMs and their suppliers to consider their impact.

As part of our contributions to the Secure-CAV project, which included threat modelling and security testing activities, we have taken a look at the automotive cybersecurity standards landscape to give developers an overview of recommendations that aim to keep attack surfaces in check.

Standards summary

We identified a long list (see: Automotive cybersecurity standards – a living list) of documents either supporting or directly related to automotive cybersecurity, which can be broadly classified into the following groups –  

  • Recommendations directly addressing automotive security  
  • Extensions to safety considerations  
  • Coding and software standards  
  • General foundations

The list we’ve identified is non-exhaustive – it is important to remember that there are new recommendations and technology-specific standards that also include security considerations, as well as pre-existing internet and telecoms standards and protocols which future automotive implementations will rely on. This emphasises the general need to improve cyber security across the board, as there are multiple cross-dependencies between sectors and industries.

Snapshot: a visual summary of the relationships between some of the automotive standards and recommendations, grouped into four categories. The abbreviations are described in full at the bottom of the post.

Timeline

While there are many established international standards for IT security and industrial control systems, these recommendations don’t address the needs of vehicle makers directly. In response, the automotive sector has issued a number of security guidelines. 

1994

MISRA publishes development guidelines for vehicle-based software.

2015

SAE formed Vehicle Cybersecurity Systems Engineering Committee to address automotive-specific threats and vulnerabilities in the US market.

2016

SAE published J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems. Recommendations cover the complete vehicle lifecycle from concept phase through production, operation, service and decommissioning. The standard is a precursor to ISO 21434 and calls for a lifecycle approach to cybersecurity engineering.

2018

ISO 26262 (second edition) is published. The final version includes comments on the interaction between safety and security (Annex E), but participants agreed that safety and cybersecurity will be treated in separate standards.

2019

MISRA and AUTOSAR announced that their industry standard for best practice in C++ will be integrated into one publication.

2021

The final version of ISO 21434 is published. The standard supersedes SAE J3061 and provides a framework for implementing a cybersecurity management system (CSMS) – in line with WP.29 UNECE recommendations – and managing road vehicle cybersecurity risk.

Efforts are underway to re-work SAE J3061 and it has been reported that the new version will be in three parts. Part 1 will describe a threat and risk analysis method for classifying threats within an Automotive cybersecurity Integrity Level (AcSIL) framework. Part 2 will give an overview of security testing methods for software and hardware. And part 3 will discuss security tools. The document set should provide a more technical companion to ISO 21434.

ISO/DPAS 5112 is moving through the committee stages and has been voted on ahead of future registration as a DIS. The document is based on ISO 21434 and provides guidelines for auditing the cybersecurity engineering of road vehicles, a function that is mandated through the recently adopted WP.29 UNECE regulations.

2022

July – WP.29 UNECE regulations (R155) come into force for ‘new vehicle types’ (vehicles in development) due to be sold in the EU.

2024

July – WP.29 UNECE regulations come into force for all new vehicles being sold in the EU.

>> To navigate to the latest version of the living list, please visit: Automotive cybersecurity standards – a living list

Abbreviations
AEC – Automotive Electronics Council (US body establishing electronic components standards for use in harsh automotive environments).
ASPICE – Automotive Software Performance Improvement and Capability dEtermination.
BSI – British Standards Institution (UK national standards body).
GSMA – Industry organisation represents the interests of mobile network operators worldwide.
ETSI – European Telecommunications Standards Institute.
IATF – International Automotive Task Force (alternative to ASPICE).
IEC – International Electrotechnical Commission (standards organisation).
ISO – International organisation for standardisation.
ITF – International Transport Forum (intergovernmental organisation with 63 member countries).
ITU – International Telecommunication Union (United Nations agency for information and communication technologies).
MISRA – Motor Industry Reliability Association (consortium focused on safe and secure application of embedded control systems and standalone software).
NTIA – US National Telecommunications and Information Administration.
PAS – Publicly available specification (a fast-track standardisation document).
SAE – Association of engineers and technical experts in aerospace, automotive and commercial vehicle industries.
SEI – (Carnegie Mellon) Software Engineering Institute, US.
UNECE WP.29 – United Nations Economic Commission for Europe World Forum for Harmonization of Vehicle Regulations.
US DoT NHTSA – United States Department of Transportation National Highway Traffic Safety Administration.

About the author
James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Secure-CAV whitepaper: Addressing the challenges of securing connected and autonomous vehicles

Over the summer, Siemens commissioned Copper Horse to write a whitepaper that captured the key themes of the Secure-CAV project and gave readers a headstart in navigating the status of automotive cyber security as well as a glimpse at its future.

Executive Summary 

Vehicles are becoming the most sophisticated connected objects in the ‘Internet of Things’ as designers consider a fully autonomous future. But integrating such features causes the attack surface of the vehicle to grow – for example, as systems make use of remote connectivity at multiple points. 

At the same time, the automotive industry has a challenge in that legacy technologies are both insecure and take a long time to age out. Unlike many other connected products, vehicles can have a very long lifespan, which demands an innovative approach when it comes to cyber security concerns. 

Beginning in late 2019, the Innovate UK-sponsored Secure-CAV consortium set out to develop and prove hardware-based security technology that will allow the automotive industry to leap ahead of the threats that it faces currently and – in the near-term – put the industry into a much more tenable cyber security posture than it currently holds. 

Secure-CAV partner, Siemens, has developed Intellectual Property (IP) as well as anomaly detection software, which is able to monitor protocols and transactions at the lowest level in hardware. This is backed by unsupervised machine learning algorithms and statistical analysis, with expert input from consortium member University of Southampton.  

The solution has been integrated into Field-Programmable Gate Array (FPGA) technology and linked to two vehicle demonstrators developed by teams at Coventry University and cyber security specialists Copper Horse – also part of the Secure-CAV line up.  

Building mitigations to a number of real-world and theoretical attacks into a demonstrator enabled the consortium to prove the theory that security anomalies can be detected and responded to appropriately, forming the foundation and basis for future developments in this emergent security solution space. 

Security perspective 

Setting the scene, the Secure-CAV whitepaper – authored by Copper Horse CEO David Rogers – provides examples of representative vehicle hacking scenarios and dissects the methodologies that adversaries rely upon. 

Briefing document: the Secure-CAV whitepaper covers a wide range of topics from the history of car hacking to the use of on-chip monitoring to boost the response times of automotive cyber security.

Moving ahead, the discussion then turns to solutions and looks at what the industry can do to improve its cyber security posture, which includes adopting hardware-based techniques that have the potential to adapt as the threat landscape evolves. 

Discover all of the details 

Published this month, the 22-page whitepaper is now available as a free PDF download

Automotive threat modelling: off-the-shelf solutions

Copper Horse’s automotive cybersecurity posts, including Automotive threat modelling: off-the-shelf solutions, can now be found on the Secure-CAV microsite.

Secure-CAV is an ambitious collaborative project that aims to improve the safety and security of tomorrow’s connected and autonomous vehicles through a combination of cybersecurity monitoring, hardware solutions, machine learning and functional demonstrators.

About the author

James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Threat modelling connected and autonomous vehicle cybersecurity: an overview of available tools

Copper Horse’s automotive cybersecurity posts, including Threat modelling connected and autonomous vehicle cybersecurity: an overview of available tools, can now be found on the Secure-CAV microsite.

Secure-CAV is an ambitious collaborative project that aims to improve the safety and security of tomorrow’s connected and autonomous vehicles through a combination of cybersecurity monitoring, hardware solutions, machine learning and functional demonstrators.

About the author

James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Computers on wheels and networks in the fast lane

Copper Horse’s automotive cybersecurity posts, including Computers on wheels and networks in the fast lane, can now be found on the Secure-CAV microsite.

Secure-CAV is an ambitious collaborative project that aims to improve the safety and security of tomorrow’s connected and autonomous vehicles through a combination of cybersecurity monitoring, hardware solutions, machine learning and functional demonstrators.

About the author

James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Vehicle Communications and the Road to Driverless Automotive

Copper Horse’s Development Lead, Mark Neve discusses technology being deployed in the vehicle comms space.

 

The car of tomorrow is going to be communicating with many different things and not just for passenger entertainment. The field of Vehicle-to-“X” communications is growing considerably. The X can mean Vehicle-to-Vehicle (known as V2V) or Vehicle-to-Infrastructure (V2I) and even V2P – Vehicle to Pedestrian or V2B – Vehicle to Bike, with many different applications within. The opportunities to improve road safety are enormous but the security and safety implications of getting it wrong are equally as important. This is something that we’re looking at as a company and we’ve already trained vehicle OEMs on our IoT Foundations of Security training course which will be running again soon.

 

 

So how do vehicles communicate with their surrounding environment and how does new technology assists the driver in keeping control of the vehicle? This not only affects current human driven vehicles but also the drive towards fully autonomous vehicles with Alphabet company Waymo planning to have 20,000 self-driving vehicles on the road by 2020. The government statistics for casualties on UK roads for 2016 state that 448 pedestrians were killed and more than 23,000 were injured on our roads. If vehicles can assist the driver in avoiding obstacles, or reduce the collision speed, they can possibly lead to a reduction in deaths and injuries on our roads.

 

Let’s look at some of the technology emerging on cars which shows the evolving path towards full V2x communications:

 

Independent Autonomous Braking

Autonomous Emergency Braking (AEB) works in conjunction with vehicle mounted sensors and cameras which are used to detect obstacles and if needed, apply the brakes. According to Thatcham Research, 8 of the top 10 selling cars in the UK offer AEB, with 50% of vehicles fitting at standard.

 

Image source

 

Drivers have experienced issues with this type of technology and an article in UK newspaper the  Plymouth Herald in October 2017 highlighted problems with a Volkswagen Tiguan where the “Front Assist” system may mistake high roadside hedges as an obstacle and brake sharply. This behaviour could lead to accidents if drivers in following vehicles do not see the same hazard and react more slowly in applying their brakes.

 

V2V for Emergency Vehicles

Emergency Vehicle Approaching warning systems are currently being trialled. Trying to locate the source of a siren can be difficult and can slow the progress of the emergency vehicle, costing precious time.  Warning systems being trialled allow the emergency vehicle to report its location and direction when it is approaching other vehicles on the road, allowing them extra time to create space for the emergency vehicle. This solution is further being developed so that emergency vehicles can be given priority at traffic lights, turning the lights green as they approach.

 

V2V Platooning

In the US, several companies such as Volvo, Daimler and Tesla are testing Platooning, the coordinated operation of two or more vehicles. The lead vehicle wirelessly communicates its speed, distance, brake status and information about any obstacle. Platoon vehicles use another V2V technology: cooperative adaptive cruise control (CACC) – a feature which monitors the speed of the vehicle ahead and adjusts its own speed to maintain a safe distance. Platooning could improve fuel economy by reducing drag as well as reducing accidents through safer following distances and instant notification of emergency braking.

 

V2I for Traffic Lights

Audi US and Traffic Technology Services (TTS)  have launched a vehicle to infrastructure (V2I) service which communicates with traffic lights and informs the driver how long before their lights turn green.

Image source

 

The vehicle communicates with the lights using a built-in LTE connection, communicating through an Audi connect PRIME feature called Traffic Light Information (TLI). This system is currently on trial in Las Vegas and has been rolled out to other cities across the US including Dallas, Denver, Houston, Palo Alto and Washington DC supporting signals for more than 1,600 intersections.

 

V2P

Vehicle to pedestrian (V2P) technology is under development by vehicle manufacturers using DSRC (Dedicated Short Range Communication) technology built into both vehicles and the smartphones of pedestrians, notifying the vehicle of the speed and direction of pedestrians and alerting drivers to a hazard. There are several other V2P technologies currently under development, the US Department of Transportation keep a publicly available excel “database” of current V2P technologies here .

 

V2B

Vehicle to bike (V2B) technology is a more of a problem to implement as cyclists sometime behave like pedestrians and at times like cars making it much more difficult to track their movement. Proximity sensors can detect cyclists in certain areas around the vehicle but there are still many blind spots. One solution that is currently being suggested is bicycles with a beacon attached to communicate with other vehicles on the road although this idea has been met with scepticism by some of the biking community, with them suggesting that pedestrians and wild animals will also need a beacon.

 

 

Driverless Vehicles and Accidents

Vehicle technology continues to evolve very quickly with the move towards driverless cars. The Google self-driving project, Waymo has now clocked up over 5 million self-driven miles, although the vehicle is being constantly monitored by a driver, who should be ready to take control if the self-drive systems fail as they did in 2016.

 

There have been numerous stories in the news highlighting accidents involving autonomous vehicles. A study commissioned by Google and carried out by the Virginia Tech Transportation Institute concluded that the US national crash rate is 4.2 accidents per million miles and 3.2 accidents per million for self-driving cars. There is a lack of data currently available due to the lack of self-driving vehicles, however many countries have plans to test self-driving cars on their roads over the next few years.

 

In March 2018 it was reported that an Uber car being tested in Tempe, Arizona struck Elaine Herzberg who was crossing a road while carrying a bike. She was transferred to hospital but later died of her injuries. At the time of this blog, Uber are yet to release their full report, so all the evidence isn’t currently available. There have been some articles highlighting how Uber scaled back their LIDAR sensors from seven sensors to one 360-degree sensor when they replaced the Ford Fusion vehicle with the Volvo XC90. The internal camera shows how the vehicle minder sitting in the driver’s seat was distracted for around 5 seconds prior to the crash; the former may have played a role in the inability to detect the pedestrian.

 

Where are we going?

It’s clear that there’s still much research and development to be done prior to fully-autonomous vehicles being allowed to share the highways with human driven vehicles. While not yet at the level required, systems which aid drivers could both help to reduce accidents and help test out safety technology critical to fully-autonomous vehicles. The more connected vehicles are to their surroundings correlates with the chance of avoiding obstacles. When we do see self-driving vehicles on our roads, it will be interesting to see the interaction with the human drivers and how human attackers may target these systems to exploit them for various purposes, but that’s a story for the future.