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.

History lessons 4: What to do when an anomaly is detected?

David Rogers continues his blog series — commissioned by on-chip monitoring experts UltraSoC (now part of Siemens) examining security through the ages and highlighting lessons for emerging and future technologies.

There are many tales from history where things have been detected that have led to plots being uncovered. Some of this has been driven by prior knowledge, sometimes the actors involved are already under suspicion in some way and in other cases it is pure chance and luck.

Guy Fawkes
Source: Edgar Wilson “Bill” Nye (1850-1896 [Public domain]

The gunpowder plot to blow up England’s parliament in 1605 was ultimately discovered because of a message to a Catholic parliamentarian warning him to stay away from the opening of parliament on November 5th. It was dismissed as a hoax at the time, but the King’s suspicions were raised and he instigated searches of parliament, increasing security. On the night of November 4th, Guy Fawkes was discovered and caught as he was leaving the place where he had stored the gunpowder underneath parliament. It appears that this was genuinely an artefact of the increased vigilance, as a few days before, Guy Fawkes had reported to his co-conspirators that “he found his ‘private marks’ all undisturbed” at the site where the gunpowder was stored. This seems to indicate that Guy Fawkes had taken his own precautions against the discovery and potential sabotage of the plot.

Another interesting story of discovery and detection is the Babington plot against Queen Elizabeth I. Queen Elizabeth’s spymaster, Francis Walsingham, discovered that a group of Catholic plotters led by a man called Anthony Babington were communicating with Mary Queen of Scots in order to depose Elizabeth and put Mary on the English throne. Walsingham first used an agent to change and control the channel by which Mary was communicating, ensuring that messages to and from her were hidden in the corks of beer barrels. This allowed him to have them intercepted and deciphered. The plot was allowed to continue, while Walsingham waited and gathered further evidence through the letters.

In the technology space, detection and response mechanisms exist on the network side mainly. Network traffic analysis tools are now backed by AI and machine learning techniques. The techniques for handling large volumes of network traffic and processing this at scale to discover anomalies have come a long way but are yet to really properly take into account what is going on with the end points and certainly not the innards of them to a chip level.

Attackers already have a variety of ways to evade detection, having fought a cat-and-mouse game for many years. Intrusion detection and anti-virus systems often whitelist domains – so if an attacker is exfiltrating data through a legitimate service – Amazon AWS, or Google for example, it may be that a compromise is never detected. Equally, modern malware often protects its command and control channels by using encryption, a logical thing to do given that many enterprises and tools will be looking for maliciousness within traffic. Another factor is that the barriers to entry have been lowered significantly through free encryption certificate issuing services such as Let’s Encrypt. For a defender, deciding exactly what to look for is driven by external factors and intelligence feeding into systems that look for anomalies.

If something is infiltrated into a device it may also never exfiltrate its data out over a corporate IP-connected network and may never need to connect to a command and control server that way. There are now a multitude of connection types available to devices and many of these will both leave and not be in control of the business. Bluetooth, low-power radio networks and mobile radio connections could all be used at the right time to move data from a compromised device.

Of course the attacker may not want to take any data at all, they might just want to compromise as many devices as possible and lie in wait to turn on some form of destructive attack at a later date, such as a Distributed Denial of Service, ransomware or wiper-style deletion attack.

All of these types of compromise point to the need to have additional intelligence from devices themselves rather than just relying on the network traffic and there is no better place to do this than the foundations of the device itself, inside the hardware.

No matter where anomaly and intrusion detection are taking place, false positives are always going to be a problem and a risk. They could cause a defender to become fatigued with the number of alerts they are getting or to misplace resources. For safety critical systems, taking the wrong action on a security anomaly could create an unsafe situation for a system’s users.

What if the attacker deliberately behaves in a way that causes the system to do something?

Sophisticated attacks may seek to trigger false positives. Bruce Schneier’s book ‘Secrets and Lies’ talks about Mujahedeen attacks on Soviet bases in 1980s Afghanistan, where fence sensors would deliberately be triggered by throwing a rabbit near them. By doing this repeatedly, eventually the sensors would be turned off and next thing there would be a vehicle through the fence.

One could imagine this happening against monitoring at a low level in devices and the trick to dealing with this is to resist the temptation to take immediate action. Events should be appropriately assessed and systems designed in such a way that they do not tip-off or alert the attacker that the system is aware of anything out of the ordinary happening. This in the long-term also allows the defender to potentially gather intelligence on the attacker for later attribution efforts or for forensic purposes. Deciding exactly when to take action relies on taking a measured approach to whether damage or harm is going to be caused. This may be a human decision, but it may also be automated, so making sure the right decision is made is paramount.

‘Babington with his Complices in St. Giles Fields’, 1586
(Public domain)

In the Babington plot, Walsingham even manipulated Mary’s communications, adding text to a letter from her, requesting that the conspirators were named. This caused Babington to reveal their names, leading to the unravelling of the plot.

Manipulating attacker traffic in a system to send back false data or to lead the attacker into blind traps is much more sophisticated and a potentially risky operation, but could be possible, with the defender significantly regaining the initiative over an attacker.

In the case of Mary Queen of Scots, Walsingham waited until exactly the right moment to trap her having taken control of the situation to this point. The evidence in the end was so damning that it caused the linguist who deciphered her messages to draw a gallows on the letter before he passed it to Walsingham.


For more on how historical security measures and failures can help instruct the future of security design for hardware in connected devices, check out the webinar (co-hosted by UltraSoC CSO Aileen Ryan and Copper Horse founder and CEO David Rogers) accompanying this series of blog posts.

Next blog post in the series >> 5/5 The game of defence and attack

Previous blog post in the series << 3/5 Confusing the guards and what it means for future hardware chip design

About the author

David Rogers is Founder and CEO at Copper Horse.

Many consumer IoT companies failing to adopt fundamental security measures despite the threat of legislation and regulation

Latest report finds that providers of consumer IoT are less likely to have a readily detectable vulnerability disclosure policy in place than firms operating in the business-to-business space.

Published today (4 November 2021), the latest IoT Security Foundation (IoTSF) report examining the adoption of vulnerability disclosure in IoT – commissioned by the IoTSF and prepared by Copper Horse – finds little improvement on last year’s figures. The overall trend, while moving in the right direction, remains far short of what’s needed to bolster confidence in the security of IoT products. Given the persistently slow pace of voluntary adoption, regulatory wheels have started turning to force companies to think more seriously about their vulnerability disclosure processes.

Slow progress: 100% adoption is a long way off based on the survey results.

2021 headlines 

  • The adoption of vulnerability disclosure in the IoT sector remains unacceptably low (just 21.6% of firms surveyed had a readily detectable policy in place). Based on these findings, almost 4 out of 5 companies are failing to provide the very basic security hygiene mechanism to allow security vulnerabilities to be reported to vendors so they can be fixed. 
  • The slow pace of vulnerability disclosure adoption by IoT providers continues to put users at risk by failing to maximise the opportunity to close gaps in product security (the percentage of firms surveyed with a readily detectable policy in place is up just 2.7% on findings for 2020). 
  • Anticipating forthcoming legislation, only 21 out of the more than 300 IoT providers surveyed would meet modest regulatory requirements. 
  • Business-to-business IoT providers are much more likely to have a readily detectable policy in place compared with firms operating in the consumer sector. 
  • Lack of information is no longer an excuse for IoT providers as best practice guides have been updated and new tools made available to streamline putting a vulnerability disclosure policy in place.

Security benefits are too good to ignore 

Reporting a product security issue should be made simple so that a vendor can get to work on investigating and developing a fix as soon as possible.  Coordinated Vulnerability Disclosure (CVD) policies cover all stages of the process from advertising the correct point of contact, through to the timescale for fixing any issues and recognition for any bugs discovered. 

Vulnerability disclosure, backed by a Vulnerability Disclosure Programme (VDP), benefits multiple parties – governments, businesses, security researchers and customers – so much so, that the process is well on its way to becoming a mandatory requirement at an international level.

Free guides and online tools 

2021 has seen a jump in the provision of information to help firms, which includes the IoTSF’s updated Best Practice Guide and a time-saving policy-maker tool, developed by disclose.io. More details and links can be found in the report. 

Legislative wheels are turning 

With governments around the world turning to legislative and regulatory means to tackle the lack of improvement in the market, it is surprising to us that there hasn’t been an increase in the rate of adoption of CVD, particularly in the last year. These companies will find it difficult to sell their products if they don’t change their ways, and soon. 

David Rogers, the CEO of Copper Horse said, “The report provides measurable evidence of IoT manufacturer and brands’ lax attitudes towards security in general. There is nowhere to hide for these companies – international standards are there to be used and coordinated vulnerability disclosure is recognised good security practice. The question for consumers globally is: ‘why should I buy products from these companies if they don’t look after security?’”

Mapping IoT Security and Privacy Recommendations and Guidance to the Consumer IoT Standard ETSI EN 303 645

In 2018 we took on the task of mapping the IoT security standards and recommendations space to the UK government’s Code of Practice for Consumer IoT Security. This was done with the hopes of garnering a better understanding of the heavily fragmented space. Now that we are seeing worldwide adoption of ETSI EN 303 645, an international, European standard, we have refocused our mapping so that you can understand how different recommendations, standards and compliance schemes map to that standard.  

We are pleased to launch iotsecuritymapping.com, realigned to focus on the ETSI EN including all previously mapped documents from the existing site, including the UK Code of Practice itself (with the older versions of this work still available here). As well as the EN provision 5.1-5.13 maps and open data, there is a high-level relationship map mapping all the referenced organisations within the documents we reviewed. This provides an excellent high-level view on which organisations and material are frequently referenced. 

Once again, we’re making all the data available to use as open data as we really want to help people to use this information in their own organisations. 

Similar to our approach to the Code of Practice mapping site, we aim to update this regularly. As inevitably there were standards released during or after our research, and others we hope to include. However, for now at least, we are satisfied that this mapping helps people and organisations understand the commonalities between the numerous bodies and organisations creating standards and recommendations in this area, during a period of defragmentation and harmonisation. With legislation being pushed over the line in many countries, this is an exciting time for the space and we are hoping for even greater harmonisation than ever. The next steps for IoT security will be focused on conformance and compliance, so we’ll keep track of progress in that space too.  

Considering the Future 

Comment from David Rogers: When we tweeted about the new site, we had a comment from Art Manion “I’m concerned that IoT security will sink under the weight and complexity. Any chance of avoiding this common compliance failure?”. It’s a view and concern that we share and goes back to our original rationale for creating the site. As an aside – one of the greatest moves in the UK work was to have the Code of Practice translated into the world’s major languages. It instantly removed barriers and friction to understanding and ultimately, adoption. In this space, we started out with massive fragmentation and no real common view on how to move forward – we had some approaches which were really deeply implementation specific versus super high-level guidance and even some that said we should just educate users. There were a lot of voices however saying the same thing and I’d spoken to a lot of those people and also worked on the technologies that had already been developed in the mobile industry to tackle these issues already. Where we are now is that we do have a harmonised view, we’ve successfully defragmented in a big way such that the major regions and countries of the world are looking at only a couple of (very similar) ways forward now in the consumer IoT space. The devil however is in the detail, as companies implement these standards they will want to do so in different ways. This is perfect because the last thing we wanted to do was to stifle innovation. However, that could (in theory) make compliance processes really cumbersome and complicated – or worse – useless and not worth the paper they’re written on. There has been a lot of work to try and break this down. ETSI’s conformance work for EN 303 645 is this standard – TS 103 701. It is prescriptive to a point and crucially doesn’t ultimately rely on a decision by a company not to implement the measures via a risk assessment. A risky approach but a necessary one in my view – for too long companies have not been doing any risk assessments or threat analysis and even if they have done, they’ve missed the real threats by a country mile. We really need a new approach that is more prescriptive in the short term. If this evolves over time beyond these baseline measures, I have no problem with that, but it is an effective solution for the problems we face today and in the near-term. Another final thing is that we haven’t bitten off more than we can chew when it comes to being tempted into looking at other IoT verticals such as industrial which has a lot of existing standards and safety concerns. 

There is no doubt we’ll get some edge cases. I’ve had to think about them a lot – in fact I painfully missed out on a day’s skiing on holiday while diving deep into the Bluetooth specifications and thinking about Smart TV child locks, while trying to find a way through the ‘default credentials’ problem. None of this stuff is easy, but I don’t think we need to be afraid of playing hard ball on the basics. We’ve had a few decades of this stuff not being designed properly and we have technical solutions that can fix those. 

Visit the new site here

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.

History lessons 3: Confusing the guards and what it means for future hardware chip design

David Rogers continues his blog series — commissioned by on-chip monitoring experts UltraSoC (now part of Siemens) examining security through the ages and highlighting lessons for emerging and future technologies.

The city walls of York
Source: David Rogers

Previously, I talked about how expensive defences can be subverted by a determined and clever adversary. This time I continue the theme of access, but consider the problem of confusion.

In considering the story in the last blog, I was thinking about whether the carpenter’s entry into Conwy Castle should be classed as (what is known in the technology world as a) ‘confused deputy attack’ (it isn’t). This type of attack often happens in web applications in cross-site request forgery (CSRF) attacks in order to confuse the browser, as the agent of the attacker, into getting a website to do something it shouldn’t.

Keeping enemies out

Another example from history can better explain the concept of a confused deputy attack. Firstly, a bit of background. There are many stories in the UK of historic laws and bylaws that stem from medieval times that give an insight into how towns controlled access from people who they would consider to be “enemies”. Some of these are true and others are mere rumour. For example:

  • “Welsh people were allowed to enter the towns by day but kept out at night and forbidden to either trade or carry weapons”
  • “In the city of York, it is legal to murder a Scotsman within the ancient city walls, but only if he is carrying a bow and arrow”
  • “In Carlisle, any Scot found wandering around may be whipped or jailed”
  • “Welshmen are prohibited from entering Chester before the sun rises – and have to leave again before the sun goes down”
  • “It is still technically okay to shoot a Welshman on a Sunday inside the city walls – as long as it’s after midnight and with a crossbow”

As a note – the law commission looked into some of these stories and clarifies that:
“It is illegal to shoot a Welsh or Scottish (or any other) person regardless of the day, location or choice of weaponry. The idea that it may once have been allowed in Chester appears to arise from a reputed City Ordinance of 1403, passed in response to the Glynd?r Rising, and imposing a curfew on Welshmen in the city. However, it is not even clear that this Ordinance ever existed. Sources for the other cities are unclear.”

In York however (a northern English city which was walled to keep the Scots out), we do know that at the Bootham Bar, an entrance to the city, a door knocker was installed in 1501. Scotsmen who wanted to enter the city had to knock first and ask for permission from the Lord Mayor.

Bootham Bar Roman gateway
YORK, YORKSHIRE, UK: JULY 22, 2008: Bootham bar Roman gateway in York city wall .

The confused deputy

We have to assume that the Lord Mayor himself was not there all the time to give permission in person and delegated the authority for checking whether someone could come in to the guards. The guards still had to come to him for sign-off though.

This is where we can explain the concept of the confused deputy more clearly. Imagine that there is a Scottish attacker who wants to get into York to cause some damage. He’s knocked on the Bootham Bar gate door knocker and convinced the guards he’s authorized because he tells them he’s there to do work (he succeeds in confusing them – they become the confused deputy, conferring trust on the Scotsman where there should be none). However, our attacker still has to gain authority – through the Lord Mayor himself.

The guards carry the message to the Lord Mayor that the Scotsman is legitimate and should be allowed to enter. The Lord Mayor assumes trust and authorizes our Scotsman to enter the city to do work.

The attacker didn’t need to convince the Lord Mayor at all, all he had to do was convince the guards and use them to gain the authority he wanted. The Lord Mayor trusted his guards, but wouldn’t trust the attacker – however he’ll never see him. This is how some website and technology attacks work, by escalating the privilege level of access via an unwitting, trusted agent. To avoid this, additional measures need to be in place for the Lord Mayor to independently validate that the Scotsman is not actually an attacker, before providing further authority to him.

One concern about chip-level attacks is that the vast majority of the communications inside the chip are not integrity checked or validated in any way. An attacker can abuse existing authorities to gain trust in other parts of the system. Changing this is going to be a long-term task for the industry as attacks become more sophisticated. In the meantime, we need to put in measures to be on guard and look for unusual activity going on, rather than automatically assuming everything within the ‘city’ is trusted; perhaps the technological equivalent of using a bow and arrow after sundown.

Sources:


For more on how historical security measures and failures can help instruct the future of security design for hardware in connected devices, check out the webinar (co-hosted by UltraSoC CSO Aileen Ryan and Copper Horse founder and CEO David Rogers) accompanying this series of blog posts.

Previous blog post in the series << 2/5 Who has access?

About the author

David Rogers is Founder and CEO 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.