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.

Race report: Spa, 19 October 2021

Qualification was the big highlight as setup issues and aero damage hampered progress in the race

Spa’s high-speed sections reward drivers that can push to the limit, but only if the car setup is fully dialled in. And, unfortunately, for Copper Horse Racing in the last race of Season 8 it wasn’t. But if you never try, you’ll never know and with three top ten finishes out of the six races entered, the team is more than happy with the performance overall. 

Uphill battle: Copper Horse Racing’s laps of the Spa circuit did not go to plan. 

Unfortunately, due to a lot of work and travel in the week before the race, the time to perfect Car 59’s setup just wasn’t there for the final event of the season. A crash early in the practice race on the Sunday prior to Tuesday’s main race gave some indications that the setup wasn’t where it should be, with the car feeling very nervous through the two main high-speed corners, Eau Rouge and Radillion, when fully loaded with fuel.  

Testing the tyre model 

This unsettling of the car unsettled the driver too! However, it was an opportunity to bank some very important lessons about tyre ‘flat-spotting’. As the car begins to lose traction and spin at high-speed, the instinct in the cockpit is to keep your foot on the brakes, but this makes a bad situation worse. Wheel rotation impeded, the tyre rubber quickly scrubbed off against the track surface and left a flat spot on each that made the car almost undriveable after recovering from the crash. 

Mercedes power: Daniel Molina goes through Les Combes on Lap 1. 

To the qualification on Tuesday and David put in a decent performance with a credible 2:20 lap earning him 10th on the grid for the race. Nerves about the car state at full fuel made David back off through the high-speed corners for the race, but staying within the limits of the suboptimal setup proved to be impossible. On lap 3, the rear end went at the fast Radillion section and the white and green Lamborghini Huracán careered into the barriers (thankfully no foot on the brake through the slide this time – noting the lessons learned from the practice race).  

Suboptimal setup: Car 59 just before heading into the barriers through Radillion. 

Quickly recovering, but with places lost, David made a beeline for the pits. The mandatory pit stop would have to be served early, including an additional thirty-some seconds of repairs. Back on track, fighting through the pack to regain lost time wasn’t as easy as planned. Further hampering this effort was the need to nurse the poorly setup Lamborghini through the high-speed combination of Eau Rouge and Radillion, losing out on the speed that’s vital to carry into the Kemmel Straight that follows it. 

Hoovering up the tarmac: the aerowork on Jamie Sterritt’s Ferrari floats close to the track, with Car 59 just visible from behind. 
Newer model: Dominik Szymanski drives the black and yellow Lamborghini Huracán GT3 Evo. 

Bumped at the bus stop 

However, another incident was to have a bigger impact on Copper Horse Racing’s success at Spa. Turning into the slow Bus Stop chicane on lap 16, a car smashed into the rear of the Lamborghini, wrecking the aerodynamic bodywork. Taking another pit stop would be an instant write-off for the race. But with the aero damage came a further worry – more vehicle instability. And, sure enough, Car 59 took another spin at the top of Radillion, collecting more damage. David continued to complete the race, gathering points in the process and finishing 18th. A less than ideal second-half of the race and a disappointing end to the season, which had been very positive up until Spa. But as the late, great Murray Walker once said, “That’s history. I say history because it happened in the past.” 

Talking telemetry 

Hands on the wheel: Copper Horse’s vehicle hacking simulator uses in-game telemetry to drive real world vehicle components such as the instrument cluster shown here. In the image, the turn signal is illuminated in response to the left indicator signal generated within Euro Truck Simulator 2. The fluffy dice are an optional extra. 

It was interesting to hear from Edward Green, McLaren’s Head of Commercial Technology, at this year’s Splunk conference as the presentation nicely validated the power of driving game telemetry. In our case, we are using the data to provide inputs for the vehicle hacking rig’s real world components such as the instrument cluster. And for McLaren, the telemetry feed was an efficient way for them to explore new approaches to race analysis and visualization during lockdown. Green noted some perks of the game data too – you get everything without interruption. On track, teams have to be more selective about which of the up to 300 sensors per car to examine due to bandwidth and weight considerations. Plus, there can be gaps in the wireless transmission depending on the geography and architecture of the circuit, although the full data set can be recovered when cars return to the garage.   

Tier 10 final standings 

Top spot in the Tier 10 leaderboard: Steffen Bley, driving a Porsche 991 II GT3 R. 
Race winner: Matthew North took first place at Spa-Francorchamps. 

With Nico Urbantat unable to start the final race, his lead at the top of the standings was vulnerable. And thanks to another second place finish (his fourth in the season), Steffen Bley took the top spot, nudging Nico Urbantat into the runner-up position. Matthew North, who missed last week’s event at Monza, took maximum points at Spa, which was enough to take third place overall and push Teis Hertgers into fourth. 

Look out for the logos: a close up view of Car 59. 

Copper Horse Racing held on to its P16 in the standings out of the 32 eligible drivers competing in Tier 10.    

About the authors  

James Tyrrell is a Threat Modelling Analyst at Copper Horse.  

David Rogers is Founder and CEO of Copper Horse and Driver of Car 59.

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

Race report: Monza, 12 October 2021

Sent spinning off track in lap 1, Car 59 battles back to finish P9

Season 8 is back-loaded with a testing trilogy of iconic circuits – Suzuka, Monza and Spa – as AOR’s virtual GT3 series nears the end of its eight-race run. Last week’s laps of Suzuka certainly pushed drivers to the limit, but how about the sim-racing rigs? In the case of Copper Horse Racing’s setup, there were definitely some complaints from the pedal board, which started to cause throttle fluctuations in the closing stages of the event. 

For Monza, the issue has been dealt with by a squirt of contact cleaner – with the can kept handy for the mandatory pit stop, adding an element of real-world vehicle maintenance to the already impressive on-screen action. 

Tough driving conditions: traction loss was an issue in the wet at Monza .

Track knowledge 

Monza is one of Copper Horse Racing’s most-driven tracks, which bumped up the potential to deliver a good result – at least in the dry. However, the constant rain during both qualifying and race sessions nudged Car 59 towards a more cautious strategy. 

Not all drivers took this route though, as – like clockwork – a three-wide tangle between competitors on lap one of the main event sent cars spinning. Unfortunately for Copper Horse Racing, the casualties included Car 59 – with the white and green Lamborghini rejoining the track almost at the back of the pack, scrubbing out any gains made during qualifying. 

Moving up through the order: Car 59 passes the Audi of Spaniard Manu Prieto at the Variante della Roggia.

Trading places 

What followed was the most epic battle yet for Car 59 as it worked its way up the order and chased down the Lexus of A. Bayer – from the 9th lap right through to the end of the 90 minute race, trading places back and forth throughout. Both drivers showed the other respect, each leaving just enough space to avoid any incident and clearly enjoying the opportunity to practice their race craft.  

Inside line: A. Bayer in the Lexus goes through into Retifillio, but the battle with the white and green Lamborghini would continue.
Advancing again: the Lexus edges ahead once more as spray from both vehicles leaves a cloud of water behind. 
Yet another overtake: this time it’s Copper Horse Racing that gets in front with the Lamborghini finishing P9 ahead of the Lexus in P10 at the chequered flag – concluding an epic battle.

Rig updates 

As regular readers of our race reports will know, the driving rig also doubles as a vehicle hacking simulator and we’ve been making some upgrades to add to the experience and also help people feel safer when we’re out on the road at events, including the addition of a seatbelt. These additions also pave the way for us to further integrate other elements of the instrument cluster and other components – such as various cabin warning signals. With modern vehicles containing a raft of sensors, there are lots of options to explore on this theme as we build on our Secure-CAV work and continue to the develop the rig.  

Buckle up for the ride: a race-grade 4-point harness is the latest upgrade to the Copper Horse vehicle hacking simulator as we prepare to take the rig out on tour (stay tuned @CopperHorseUK on Twitter for more details on our whereabouts in November). 

Monza podium 

Teis Hertgers, third-place finisher at Suzuka last week, won in convincing style at Monza – leading the race from lap five. Steffen Bley came in second, followed by Matheus Martins in P3 to complete the podium. 

Dominant drive: Teis Hertgers led the race from lap five at Monza in a white and black Aston Martin.

With race seven complete, competitors have just one more event to bag points as season 8 draws to a close at Spa-Francorchamps. Look out for the next race blog to see if Car 59 can round out the calendar with a trio of top ten finishes.  

About the author 

James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Race report: Suzuka, 5 October 2021

Copper Horse Racing puts in fast laps under the stars to bag another top 10 finish  

In season 7, Car 59 raced around Zolder and now – in season 8 – it’s time to add another John Hugenholtz designed track to the list – the mighty Suzuka circuit. Built in the 1960’s to fulfill Honda’s test track needs, the technical layout wastes no time in discovering a driver’s limit thanks to iconic features such as ‘the Esses’ (or ‘Snake’) and ‘Spoon curve’. 

Esses from the air: after navigating turn one, competitors then snake through a series of ‘S’ curves.

Also, if that wasn’t enough to contend with, series organisers Apex Online Racing have made this event a night race, although sparingly, a dry night race.  

Fully committed: Car 59 positions itself for the high-speed 130R bend followed by Sweden’s Mathias Alenmalm in an underrated LEXUS RC F GT3 – one of the best handling models on the grid. 

Green lights and away 

Qualifying mid-pack in P12, it was important to survive the opening laps without incident. A couple of bumps from neighbouring drivers threatened to send the white and green 2015 Lamborghini Huracan GT3 off-track. But lead driver David Rogers had confidence in the vehicle settings and managed to keep Car 59 between the white lines. So began the 60 minutes slog around a very physically demanding circuit (yes, that’s right – sim racing can be both physically and mentally demanding!).  

First lap action at Suzuka in Season 8 of AOR’s GT3 sim-racing series.

Under race conditions, the Lamborghini performed well across all three sectors as grip levels allowed it to find more time through the Hairpin and two Degner corners – sequences that had been more costly in qualification with less rubber on track. A conscious choice had been made to increase the level of rear wing for this race and to keep the traction control at a reasonable level as the cold night air made the track slippery than usual. 

Overtaking opportunity: Copper Horse Racing’s white and green Lamborghini pulls ahead of Davy Melin in a McLaren.

Playing the long game, Car 59 had moved up five places to 7th by lap 10, picking its battles to keep within the limits of track and driver. As the leaders pitted, the Secure-CAV liveried Lamborghini enjoyed a short spell at the front of the race until it too had to stop for new tyres. 

Cockpit view: Copper Horse racing spent much of the race behind Brazilian driver Matheus Martins who drove well in a Mercedes AMG GT3. 

Rejoining the action, the biggest concern was obeying track limits, particularly around the tricky ‘Spoon’. With ten minutes to go, a second track limits warning was received; one more and it would be a stop-go penalty. Careful driving in that section for the remainder allowed the Lambo to steer clear of last minute disaster! 

Penalties avoided, it was an encouraging night’s work as Car 59 registered its best race result in the competition so far – P8. 

X-section: Suzuka’s figure of eight layout is enabled by an overpass. Race leader Nico Urbantat heads under the bridge, stuck in traffic between the yellow number 87 McLaren of Northern Ireland’s Willy Cranston in 13th and 14th-placed number 878 of Poland’s Robert. Davy Melin’s number 22 McLaren 720s GT3 in 9th place crosses over the top. 

Secure-CAV makes its YouTube debut 

With our race reports in double figures, you probably know a great deal about our exploits on track. But there’s plenty that happens when we’re not racing. One of our biggest projects currently is Secure-CAV, where Copper Horse is contributing threat modelling and security testing expertise. And a quick way of finding out more, is to check out this short film commissioned by the project partners and made over the summer by Suited & Booted studios

Podium positions 

No change from Last week with Nico Urbantat taking the win once again and Matthew North coming second. But the third spot has proven to be less predictable with Teis Hertgers taking P3 this time around. 

Top spot: Nico Urbantat in a Porsche 991 takes the win at Suzuka.

About the author 

James Tyrrell is a Threat Modelling Analyst at Copper Horse. 

Race report: Nürburgring, 21 September 2021

Under wet conditions, Copper Horse Racing gains 7 places from qualifying to finish P11

If you are looking for tough racing then the Nürburgring is not going to disappoint. Drivers in season 8 of AOR’s GT3 league were spared the ‘Green Hell’ of the epic Nordschleife circuit, racing instead on the Grand Prix loop. But they still had to contend with the region’s notoriously bad weather, which pushed up the difficulty of navigating a mix of fast and technical circuit features another notch. 

Built in 1984, Nürburgring’s GP track is home to a wide range of racing formats including the ‘Eco Grand Prix’, held since 2013. 

81% changing conditions 

Series organisers AOR kept sim-racers on their toes by advertising changeable dry and wet weather conditions. That being said, tier 10 entrants received a particularly bad roll of the dice with the track becoming wet, wet and wetter as the race unfolded. However, drivers in other tiers did experience drier spells as Yorkie065’s livestream on YouTube shows. 

Qualifying low down the order in P18 with a wet setup that never felt quite right, Car 59 driven by David Rogers had to focus hard to stay out of trouble in the main pack. If previous races are a guide – taps, tangles and off-track excursions are almost guaranteed at some point as opponents jostle for position on cold tyres (especially in the wet). And there was nothing to suggest that things would be any different this time around. 

A hard slog 

Driver perspective:

The first lap was less eventful than usual and I managed to pick up five places going into lap 2. However, a tap from behind as the car turned into the tight Castrol ‘S’ meant lost places and the accident caused other cars to go off too. In the split-second that was available to make decisions and relatively unsighted (a problem with sim racing), I attempted to move out of the entirely blocked road. My car was then hit again by another car trying to manoeuvre around a stranded vehicle; my movement ultimately caused the stewards to penalise me for dangerous driving. This was warranted as sim racing requires you to remain stationary if stuck on the track during an incident, precisely because of this awareness issue. For drivers using VR headsets or TrackIR, they have a better appreciation of what’s going on around them, but it is still never going to be the same as a real car.

First full lap of the race: Secure-CAV sponsored Car 59 moves up through the race order.

Another challenge for everyone, is that the cars all have different setups and braking points and in the wet this can cause a lot of issues especially where cars can also be carrying damage from their own incidents. The 2015 Lamborghini has quite a long braking distance in comparison with other cars on the track. 

In fact, racing at the Nürburgring generated the most Tier 10 DNF’s of the series so far, with five drivers failing to make it to the chequered flag – a measure of the challenging conditions. 

Plus, this week’s race was run in the longer 90 minute format, which gives an extra 30 minutes for things to go wrong as concentration levels fade. The final stint certainly proved tricky for Copper Horse Racing’s white and green Lamborghini Huracán, with a late spin — caused simply by being momentarily distracted — dropping the car from P8 to P12. 

The race’s mandatory pitstop was taken 10 minutes from the end, with only a splash of fuel needed and opting for no repairs to the minor damage to the vehicle. The minimal time in the pits brought the car out behind a rapidly slowing damaged McLaren. On the final lap and driving hard and being chased by Chris Maitland in his Footwork liveried 2016 Lexus RC F GT3, I made a move on the McLaren in the Mercedes Arena complex of corners. Taking a different, inside line to the slow driver, the move resulted in a clash between the two cars, and I backed off, allowing the McLaren to return to racing. A couple of corners later at the Valvoline-Kurve, the McLaren opened the door wide, so I moved in again, this time getting through with the McLaren hitting the side of the car and losing time, allowing Maitland’s Lexus through too behind me. A post-race stewards’ inquiry was inevitable, but I didn’t have much choice in the moment, not knowing what was going on with the McLaren or why it was driving slowly. 

Rapid refuel: the white and green Lamborghini of Copper Horse Racing takes a short pitstop ahead of the final few laps.

To be competitive, drivers have more to consider than just watching out for other opponents and keeping the car between the white lines. Other demands include monitoring the in-game telemetry, which represents the sensor data that would be available in a real GT3 car, to keep tabs on brake temps, fuel load, tyre pressures and much more besides. 

Data protection and threat modelling 

In Formula One, cars reportedly run with over 300 sensors per vehicle, up from just 24 when teams began using the technology more than three decades ago. The trend can be seen in road vehicles too, especially those fitted with advanced driver assistance systems (ADAS), which rely on a range of vehicle and environmental data to operate.  

Sensor data brings tremendous knowledge to racing teams and, on the road, can boost safety by helping drivers to navigate otherwise unforeseen hazards. But as vehicles rely more heavily on the exchange of information – connected and autonomous vehicles being the most extreme example – security measures will need to evolve to mitigate the corresponding threats. 

In a previous race report, we discussed the manipulation of algorithms used to recognise road signs. More recently, security researchers have shown how projected (or phantom) images can confuse vehicle cameras. But it’s not just vehicle safety that’s at risk. Attacks on sensors (or their data) could impact privacy or have other consequences. For example, what if payment information could be extracted, or other personal details such as trip history and location?  

There are many angles for carmakers and their suppliers to consider, but there’s also a process that can help – threat modelling (one of our security activities at Copper Horse), which at the highest level boils down to answering four key questions

  1. What are we working on? 
  2. What can go wrong?
  3. What are we going to do about it?
  4. Did we do a good enough job? 

Also, cleverly designed card decks can make threat modelling sessions much more interactive and engaging for participants.  

Talking of fun, let’s return to the race details.  

Race results 

Victory at the Nürburgring went to Swiss driver Matthew North in an Aston Martin V8 Vantage, who managed to get one up on pole sitter Teis Hertgers of The Netherlands. Copper Horse’s David Rogers kept it together to finish P11, gaining 7 places (5 in the first lap) overall. But this week, the most positions gained award goes to Davy Melin in a McLaren 720S, who passed the chequered flag in fifth position, up 8 places on his qualifying spot. 

Race winner: Matthew North crosses the line driving an Aston Martin V8 Vantage.

The post-race stewards’ inquiry found against David Rogers in the final lap incidents, resulting in points deductions and license penalties. In the cold light of day, it is easy to make retrospective analyses of on-track incidents. But during the race it is very different with drivers in difficult conditions making split-second decisions – as real-life driver Alex Fontana, also driving a Lamborghini discovered at Valencia at the weekend. This makes racing what it is – an exciting battle between competitors who all really want to win. 

 The series continues with racing at Zandvoort, where Tier 10 drivers might get to enjoy sunnier weather with only a 30% chance of rain, according to the forecast. 

About the authors 

James Tyrrell is a Threat Modelling Analyst at Copper Horse. 

David Rogers is Founder and CEO of Copper Horse and Driver of Car 59. 

On the move: the driver’s viewpoint from car 59 in the wet mid-race at the Nürburgring GP circuit

Race report: Snetterton, 14 September 2021

Top ten finish for Copper Horse Racing on Season 8 debut

Copper Horse Racing is back for another season of virtual GT3 racing organised by Apex Online Racing. Once again supporting its Secure-CAV livery, Car 59 joined the action at the third event in the calendar – Snetterton, a tight and technical track originally created from a network of runways.

Close racing: Side by side into the Montreal corner with the number 271 Ferrari of Jamie Sterritt

Moving target

To recap, our target for Season 7 was to finish top 20 in the overall standings (Tier 10) – which, thanks to the (slowly improving!) sim-racing skills of Copper Horse’s David Rogers, we managed to hit by placing 19th. Given that this time around we’re joining at race 3 and missing out on points from the first two events, our Season 8 target is going to be different – to bag a podium finish. There’s some debate in the back-room as to the likelihood of achieving this goal, but based on the trajectory of last season’s finishes – it’s not beyond the realms of possibility. Plus, we begin this season further up the learning curve in terms of car setup and race craft.

We were up against good competition in Season 7, which is the best training you can have. Looking at some of the familiar names from our Tier 10 debut, El Tigre Blanco and Justin Dawson have jumped up two tiers for Season 8. Scott Ullmann (Tier 10 champion in Season 7), Scott Cranston and Mar Coolio have gone one better and are all now racing in Tier 7. Copper Horse rejoins in Tier 10 and faces some fresh talent in the league who are very quick.

Snetterton race notes

Waiting for the green light: Secure-CAV badged Car 59 lines up 7th on the grid.

A long formation lap helped to calm the nerves and the white and green Lamborghini Huracán GT3 of Copper Horse Racing, having qualified in its highest ever position of 7th, started ahead of the main pack. The setup for this track involved stiffening the rear of the car to get extra stability and finding the right balance of rear wing for the long straights and tight hairpins.

A relatively clean start for all began an hour of hard driving amongst a group of very fast and determined competitors. The 2015 Lambo was faster than many, but on a tight circuit, it proved difficult to get past some cars. There were a couple of off-track moments whilst attempting to squeeze past opponents, losing some early places – especially while tyres came up to temperature.

Learning curve: chasing down Alen Bardet in his Porsche 911 through the infamous ‘Bomb Hole’ before he dived into the pits.

As the race settled in, the tactical battle of the mandatory pitstop began. David opted to stay out until either he hit traffic or the tyre wear started to compromise the lap times.

On lap 19, the tyres started to go off, so the car headed into the pits – choosing to not repair some minor suspension damage in order to keep the stop short. Returning to the track, battling resumed with the Ferrari 488 GT3 Evo of Jamie Sterritt until the Lamborghini found a way past on lap 22, holding its P9 position until the finish. The final part of the race involved car 59 chasing down the number 96 Mercedes-AMG of Armands Petrovics, with the gap steadily dropping. But it would have needed a couple more laps to pass, with the gap reduced to around a second at the chequered flag.

Last lap: under the bridge for the final time.

The dry conditions allowed racers to set some quick lap times, with three of the top 20 best laps being set by David Rogers, although it’s both pace and consistency that ultimately brings victory – as demonstrated by race winner Nico Urbantat in a Porsche 911 II GT3 R 2019.

Next week, organisers dial up the difficulty (and the drama!) as drivers tackle the Nürburgring in the wet.

Cars that don’t exist

Readers of previous race reports will notice that we like to introduce security topics into the blogs to shine a light on our day job. Copper Horse engages in a wide range of activities including threat modelling, policy development, training and product security testing from web applications through to device hardware.

This week, it’s interesting to note how easy – thanks to the laser-scanned track and car details – it can be to confuse in-game images with real life photos, at least from some angles. Artificial intelligence can mix things up further still – for example, in 2018 Nvidia researchers used a technique dubbed style-mixing to generate images of cars that don’t exist, yet appear real (a copy of their paper is available on arXiv).

Abraham Lincoln famously said that you can’t fool all of the people all of the time, but computers could one day push that quotation to the limit.

It also makes us wonder whether we’ll ever get some mixed reality racing in future SRO GT series. There is already a concurrent esports series to the existing real GT World Challenge, with the same drivers. Imagine a world where there are real racing drivers remotely driving real cars, fully autonomous real cars on the track, combined with virtual cars around the real track (that the real drivers on track can also see!). It is really not that far-fetched, but it is certainly going to be a very different world!

About the author

James Tyrrell is a Threat Modelling Analyst at Copper Horse.

Race report: Silverstone, 29 June 2021

Saving the best until last, car 59 finishes top 10 in the final race of the season 

After seven rounds of hard driving, the sim-racing series reached its last sessions of the season at Silverstone – a fast-paced circuit built on a former airfield. The organisers, Apex Online Racing, had set the scene for some quick lap times – treating drivers to a dry track. Albeit one with grey clouds looming large overhead, a familiar sight at the circuit. 

Season finale: drivers arrive at Silverstone for round 8.

Towards the end of qualification, a less-than-ideal setup and rival drivers seemed to turn up the wick – pushing Copper Horse Racing down to P20. However, in the race itself this turned out to be a blessing. With just a few points separating leaders in the overall classification, nobody at the front wanted to yield position and the inevitable first lap carnage that followed catapulted car 59 up the order. 

Wheels in the air: a collision in the front half of the pack on lap 1 left multiple cars out of position.

As the former leaders rejoined the track, they were anxious to overtake and chase down the vehicles that had passed them by. David Rogers in car 59 was soon put under pressure and drove well to fend off drivers dive-bombing from behind like seagulls after a bag of chips. 

Battle of the generations: Lamborghini Huracán GT3 and GT3 Evo (lime green and black) duke it out on track.

Vehicle hacking simulator 

The ever-evolving rig, based on a DOF Reality full-motion platform – now with triple screens optically stitched together by light refracting panels – has served us well throughout our first season of esports, but its main role is to support our work on automotive security. In the last two races, it has had its brake wires loosely twisted together while we perform modifications and testing on that part of the rig, somehow managing to survive 90 minutes of Imola and 60 minutes of Silverstone and all the practice in between!  

By adding real vehicle components such as an instrument cluster and after-market head unit – all integrated through a CAN-Bus and fed with rich in-game telemetry – we are able to simulate (safely) the effects of multiple automotive attacks. 

Wraparound view: refractive panels provide a continuous display by hiding the screen bezels. Also shown, is the real world instrument cluster, which responds to in-game telemetry fed via a CAN-bus.

Scenarios that can be demonstrated, include the loss of braking function, steering take-over, manipulation of the vehicle’s mileage, hi-jacking of a car’s headlights and infotainment-based attacks – to name just a few of the possibilities.  

Simulators are nothing new for automotive testing, but it’s rare to have a setup that can be used to explore and visualise the automotive threat landscape in this way. The Copper Horse vehicle hacking rig puts people in the driving seat so that they can better experience the various attack scenarios first-hand. 

Moving up the leaderboard 

At the end of the race, following penultimate lap drama ahead and a last lap, last gasp pass by Dave Bramhall – who went on to finish second in the season overall – Copper Horse Racing ended up in P9 at Silverstone, advancing 11 places from qualifying and grabbing its biggest haul of points yet. 

Seizing the opportunity: confusion between the drivers ahead allowed car 59 (in the background) to pick up another two places, although Dave Bramhall in car 92 would go on to finish in front of the white and green Huracán.

And while those points didn’t mean any prizes this time around, they did move David up to nineteenth out of 50 entrants in the leaderboard – a very respectable debut performance and worthy of the champagne that was drunk after the race. 

In Tier one, where sim-racers get to mix it with the pros, Kevin Siclari overhauled Maciej Malinowski’s lead in the championship to take the top spot. And looking at the other close races for the title, Jake Mills lost out to Ryan Rees in Tier 8, but Manuel Rutter kept his hands on the trophy in Tier 9 – staying ahead of Richard Aconley. 

Celebrating with donuts: Tier 10 champion Scott Ullmann puts on a show in his Porsche.

Participating in the online racing calendar has given us the chance to shine a light on Secure-CAV and related topics in the world of automotive security. 

Next steps in the project 

At our UK facility, Copper Horse is now engaged in the security testing phase of Secure-CAV. Here, the team is taking a ‘whitebox’ or ‘clearbox’ approach to code security review of our partners’ implementation against various standards. Alongside this, we are considering different attack patterns against interfaces and other aspects to identify potential vulnerabilities, including fuzzing – for example, probing the ability of the system to handle malformed inputs – to give just a couple of examples of the activities underway. We are doing this together with our own partners YGHT Ltd to give some logical and sensible separation from the project itself.  

On track, our plan is to be back in the driving seat for more sim racing in the Autumn.  

About the author 

James Tyrrell is a Threat Modelling Analyst at Copper Horse. 

Race report: Bathurst Mount Panorama, 8 June 2021

Heartbreak avoided as a strong drive by car 59 recovers all but one of the 13 places dropped in first lap chaos on the mountain. 

Changeable weather meant that drivers had to know their setups inside out to make progress at Bathurst Mount Panorama – a 6 km ‘scenic drive’ with no shortage of excitement. Put a foot wrong on the mountain section, which includes a string of tough turns such as ‘The Esses’ and ‘The Dipper’, and it can easily be game over with barriers either side of the track leaving little margin for error. 

Keeping it tight: drivers had to observe close barriers on the mountain section

The YouTube video below illustrates just how bizarre some of the crashes have been at the real-life Bathurst circuit – in this example from 2020, the car (also a GT3 Lamborghini) comes to rest on a fence! 

Lamborghini on the barriers: if you hadn’t seen it, you wouldn’t have believed it

In qualifying, Copper Horse Racing placed a very encouraging P17, before becoming derailed by a slow car rejoining the track towards the end of the session. Back in the pits, we’d prepared a number of race setups as it was forecast to rain. It wasn’t certain as to whether the race would be dry, fully wet or changeable. As it turned out, the race ‘weekend’ gave us heavy rain for the race itself. 

First lap chaos in the wet: car 59 did its best to navigate crashes on the left and right of the track

Within seconds of the lights going green, multiple incidents and cars littered the mountain, leading to an unavoidable crash and damage which sent car 59 tumbling down the order to P30 and forced the strategy into taking a very early pitstop. On the up side, this had the benefit of clearing a stop-go penalty from the previous race imposed by the stewards and also dealt with the mandatory tyre change, meaning that we could stay out for the remainder of the race.  

Voice activated

Many, if not all, of the sim racers taking part are using Crew Chief – an outstanding app that plays dual roles of spotter and race engineer, providing words of wisdom throughout every session. What’s more, the communication is two-way and Crew Chief can be programmed to listen out for instructions – for example, to prepare a set of tyres ahead of a pitstop. 

Battered but not broken: an unavoidable collision on lap one forced an early pitstop for car 59

Voice assistants can be found in real cars too – for example, to program heating or cooling in the cabin, change the volume on the radio, adjust the ambient lighting, set a destination for the Sat-Nav and even to activate a back massage. As well as bespoke offerings, vehicle OEMs are teaming up with tech giants such as Amazon and Apple, integrating ‘Alexa’ and ‘Siri’ into their products. Also, recent versions of Android Auto, which is reportedly available for over 50 different brands of vehicle, feature ‘Google Assistant’. 

But inviting microphones into the cockpit could have its downside. In 2010, researchers at the Universities of Washington and California San Diego pointed out that telematics units in vehicles could provide a path for bad actors to capture audio from the vehicle. In 2020, the paper – which explores a wide range of threats to a modern automobile – was given a ‘Test of time’ award from the IEEE; recognising the momentum that the study has added to the field of automotive cybersecurity. 

As you might have gathered from the first blog post in this series, the rig that’s used to compete in the Apex Online Racing GT3 Season 7 league functions as a vehicle hacking simulator outside of races. The setup can be configured to recreate numerous automotive cyber-attacks, including some of those first mentioned in the 2010 study, and follows from our activities within Secure-CAV

Back on track

At Bathurst, the white Lamborghini  drove a lonely few laps, with a clear track to pull its way back into contention after its early pitstop. The hot stint helped Copper Horse Racing to reel in drivers who were struggling ahead and positions were gained too as competitors took their mandatory single pitstop. 

Lonely laps: the middle section of the race felt like a hot stint

On the last lap of the race, a chance emerged to take 17th place from the car in front after a mistake on the mountain. Coming up to the last corner, as the race ticked out its final seconds, a successful do or die overtake would have restored car 59 to its qualifying position, however it just wasn’t to be. But there were no complaints from the team (or Jim, our vocal engineer in Crew Chief) with the P18 finish – the best race result so far for David Rogers in the series. 

Gotta go for it: Copper Horse Racing was on a mission to recover all of the places lost from the early crash and almost made it back to P17

On the top spot, with their first visit to the podium, was El Tigre Blanco who had shown they could be quick over a lap in qualifying. Dave Bramhall bested his familiar P3 by one to finish second and Scott Ullmann took third. A special mention in the blog also goes to Philippe Riehl of France who gained a monster 19 places to finish P9. 

See you at the next race (Tue 14 Jun, from 19:30 UK time) which takes place over Belgium’s Zolder circuit. And remember you can tune into the fun as we’ll be streaming live on Twitch.  

About the author 

James Tyrrell is a Threat Modelling Analyst at Copper Horse.