On August 31, 2021, the ISO International Organization for Standardization officially released the ISO/SAE 21434: Road vehicles-Cybersecurity engineering (road vehicle information security engineering) standard, which defines cyber security engineering design practices/practices for all on-board electronic systems, vehicle components, on-board software and external networks.
Standard Release
The standard mainly specifies the information security risk management requirements for road vehicle electronic and electrical systems and their components and interfaces during the concept, development, production, operation, maintenance and destruction phases. The standard mainly focuses on the automotive information security process and does not specify specific technologies or solutions related to information security. As one of the most important international standards in the field of automotive information security, its release will provide strong support for the information security process management and information security management system construction throughout the life cycle of the vehicle.
The standard formulation work started on January 30, 2016 and was released in August 2021. Led by CATARC, industry experts are promoting the transformation of ISO/SAE 21434 international standard into a recommended national standard "Road Vehicle Cybersecurity Engineering". The standard document was jointly prepared by Technical Committee ISO/TC 22, Road Vehicles, Subcommittee SC 32, Electrical and Electronic Components and General Systems, and SAE TEVEES18A Vehicle Cybersecurity Systems Engineering Committee. The first edition of ISO/SAE 21434 cancels and replaces SAE J3061:2016- Cybersecurity Guidebook for Cyber-Physical Vehicle Systems.
ISO/SAE 21434 Overview
ISO/SAE 21434 Overview
ISO/SAE 21434 focuses on cybersecurity risks in the design and development of automotive electronics. The standard covers cybersecurity governance and structure, safety engineering throughout the vehicle lifecycle, and post-production safety processes. The predecessor ISO standard to ISO/SAE 21434 is ISO 26262 "Road vehicles - Functional safety". ISO 26262 provides a lifecycle (management, development, production, operation, service, retirement) concept for automotive safety and provides the necessary support during these lifecycle stages. The standard covers the overall development process (including requirements planning, design, implementation, integration, verification, validation and configuration) in terms of functional safety. 26262 does not cover software development or vehicle subsystems, nor how to handle cybersecurity incidents. ISO/SAE 21434 covers all aspects of cybersecurity - from the initial design of the vehicle to retirement. The supply chain is also included in every step of automotive production. ISO/SAE 21434 covers all phases of the connected vehicle lifecycle, including electrical and electronic systems, including their components and interfaces, including: • Design and engineering • Production • Customer operation • Repair and maintenance • End-of-life This lifecycle approach to cybersecurity management makes ISO/SAE 21434 one of the most comprehensive approaches to connected vehicle cybersecurity.
Impact on automotive OEMs and developers
Any manufacturer, developer or OEM should consider actively integrating ISO/SAE 21434 into its current production process. The main focus of the new standard is cyber security. The focus of the standard is to provide better safety for automotive consumers by regulating the way manufacturers test their products.
ISO/SAE 21434 requires manufacturers and developers to conduct risk assessments. Before identifying risks, manufacturers need to know what causes the risk. The assessment will identify any components, APIs, or software functions that may be vulnerable to attack. After completing the assessment, the vulnerabilities should be identified.
The impact on car developers and manufacturers is that they can produce applications and components that are tested before release, which benefits drivers and their safety.
Standards also work with other frameworks: in the case of ISO/SAE 21434, NIST SP-800-30 and Stampard ISO/IEC 31010 can be used to establish the basis for risk assessment using tried and tested methods.
The ISO/SAE 21434 standard was introduced by automotive stakeholders to address the security issues brought about by connectivity. The standard provides a framework for enhancing security and promotes a more ideal approach to building safer vehicles.
Introduction to ISO/SAE 21434:2021
(I) General information of standards
Status: Published Publication date: 2021-08 Version: 1st edition Number of pages: 81 pages Technical Committee: ISO/TC 22/SC 32 Electrical and electronic components and general system aspects
2. Purpose of the Standard
This document sets out the information security perspective in the engineering of electrical and electronic (E/E) systems for road vehicles. By ensuring appropriate consideration of information security, this document aims to keep E/E systems engineering up to date with state-of-the-art technology and evolving attack methods. This document provides vocabulary, objectives, requirements and guidelines related to information security engineering as a basis for a common understanding throughout the supply chain. This enables organizations to: • define information security policies and processes; • manage information security risks; • foster an information security culture. This document can be used to implement an information security management system, including information security risk management.
3. Organization of this document
Figure 1 gives an overview of the structure of the standard document. The elements in Figure 1 do not dictate the order in which the various topics should be addressed. Overview of the Standard Document
Section 4 (General Considerations) is for reference only and contains the background and perspectives on the engineering approach to road vehicle cybersecurity in this document.
Article 5 (Organizational information security management) includes information security management and specification of organizational information security policies, rules and processes.
Article 6 (Project-related information security management) includes information security management and information security activities at the project level.
Clause 7 (Distributed information security activities) includes requirements for the distribution of responsibilities for information security activities between customers and suppliers.
Clause 8 (Ongoing information security activities) includes activities to inform ongoing risk assessment and defines vulnerability management of electronic/electronic systems until the end of information security support.
Clause 9 (Concept) includes activities to determine the project's information security risks, information security objectives, and information security requirements.
Clause 10 (Product Development) includes activities to define information security specifications, implement and verify information security requirements.
Article 11 (Information Security Verification) includes information security verification of vehicle-level items.
Article 12 (Production) covers information security related aspects of the manufacture and assembly of articles or components.
Clause 13 (Operation and Maintenance) includes activities related to information security incident response and updating of items or components.
Clause 14 (End of Information Security Support and Decommissioning) covers information security considerations for ending support and decommissioning of a project or component.
Article 15 (Threat analysis and risk assessment methods) includes a modular analysis and assessment method to determine the extent of information security risks and take appropriate measures.
Clauses 5 to 15 have their own objectives, provisions (i.e. requirements, recommendations, permissions) and work products. Work products are the results of information security activities that satisfy one or more related requirements.
“Prerequisites” are mandatory inputs consisting of the work products of the previous phase, and “Further Supporting Information” refers to information that can be considered and can be provided by sources other than those responsible for information security activities.
Clauses and Work Products are assigned unique identifiers consisting of a two-letter abbreviation ("RQ" for Requirement, "RC" for Recommendation, "PM" for Permission, and "WP" for Work Product) followed by two numbers separated by a hyphen. The first number identifies the clause and the second number identifies the sequential order of the clause or work product, respectively. For example, [RQ-05-14] refers to Clause 14 in Clause 5, which is a requirement.
(IV) Standard Catalog
Standard Catalog | (Reference translation) |
Foreword | Preface |
Introduction | introduce |
1 Scope | 1 Scope |
2 Normative references | 2 Normative references |
3 Terms, definitions and abbreviated terms | 3 Terms, definitions and abbreviations |
3.1 Terms and definitions | 3.1 Terms and Definitions |
3.2 Abbreviated terms | 3.2 Abbreviations |
4 General considerations | 4. General considerations |
5 Organizational cybersecurity management | 5Organizational Information Security Management |
5.1 General | 5.1 General |
5.2 Objectives | 5.2 Objectives |
5.3 Inputs | 5.3 Input |
5.4 Requirements and recommendations | 5.4 Requirements and recommendations |
5.5 Work products | 5.5 Work Products (Outcomes) |
6 Project dependent cybersecurity management | 6. Security management of project-related information |
6.1 General | 6.1 General |
6.2 Objectives | 6.2 Objectives |
6.3 Inputs | 6.3 Input |
6.4 Requirements and recommendations | 6.4 Requirements and recommendations |
6.5 Work products | 6.5 Work Results |
7 Distributed cybersecurity activities | 7. Distributed Information Security Activities |
7.1 General | 7.1 General |
7.2 Objectives | 7.2 Objectives |
7.3 Inputs | 7.3 Input |
7.4 Requirements and recommendations | 7.4 Requirements and recommendations |
7.5 Work products | 7.5 Work Results |
8 Continual cybersecurity activities | 8. Continuous Information Security Activities |
8.1 General | 8.1 General |
8.2 Objectives | 8.2 Objectives |
8.3 Cybersecurity monitoring | 8.3 Information Security Monitoring |
8.4 Cybersecurity event evaluation | 8.4 Information Security Incident Assessment |
8.5 Vulnerability analysis | 8.5 Vulnerability Analysis |
8.6 Vulnerability management | 8.6 Vulnerability Management |
9 Concept | 9 Concept |
9.1 General | 9.1 General |
9.2 Objectives | 9.2 Objectives |
9.3 Item definition | 9.3 Project Definition |
9.4 Cybersecurity goals | 9.4 Information Security Objectives |
9.5 Cybersecurity concept | 9.5 Information Security Concept |
10 Product development | 10 Product Development |
10.1 General | 10.1 General |
10.2 Objectives | 10.2 Objectives |
10.3 Inputs | 10.3 Input |
10.4 Requirements and recommendations | 10.4 Requirements and recommendations |
10.5 Work products | 10.5 Work Products |
11 Cybersecurity validation | 11Information Security Verification |
11.1 General | 11.1 General |
11.2 Objectives | 11.2 Objectives |
11.3 Inputs | 11.3 Input |
11.4 Requirements and recommendations | 11.4 Requirements and recommendations |
11.5 Work products | 11.5 Work Products |
12 Production | 12 Production |
12.1 General | 12.1 General |
12.2 Objectives | 12.2 Objectives |
12.3 Inputs | 12.3 Input |
12.4 Requirements and recommendations | 12.4 Requirements and recommendations |
12.5 Work products | 12.5 Work Products |
13 Operations and maintenance | 13 Operation and Maintenance |
13.1 General | 13.1 General |
13.2 Objectives | 13.2 Objectives |
13.3 Cybersecurity incident response | 13.3 Information Security Incident Response |
13.4 Updates | 13.4 Update |
14 End of cybersecurity support and decommissioning | 14 End of Information Security Support and Decommissioning |
14.1 General | 14.1 General |
14.2 Objectives | 14.2 Objectives |
14.3 End of cybersecurity support | 14.3 End of Information Security Support |
14.4 Decommissioning | 14.4 Scrapping |
15 Threat analysis and risk assessment methods | 15 Threat Analysis and Risk Assessment Methods |
15.1 General | 15.1 General |
15.2 Objectives | 15.2 Objectives |
15.3 Asset identification | 15.3 Asset Identification |
15.4 Threat scenario identification | 15.4 Threat Scenario Identification |
15.5 Impact rating | 15.5 Impact Level |
15.6 Attack path analysis | 15.6 Attack Path Analysis |
15.7 Attack feasibility rating | 15.7 Attack Feasibility Level |
15.8 Risk value determination | 15.8 Determination of Risk Value |
15.9 Risk treatment decision | 15.9 Risk Management Decisions |
Annex A Summary of cybersecurity activities and work products | Appendix A Overview of Information Security Activities and Work Products |
A.1 General | A.1 Overview |
A.2 Overview of cybersecurity activities and work products | A.2 Overview of information security activities and work results |
Annex B Examples of cybersecurity culture | Appendix B Information Security Culture Examples |
Annex C Example of cybersecurity interface agreement template | Appendix C Information Security Interface Protocol Template Example |
C.1 General | C.1 Overview |
C.2 Example template | C.2 Sample Template Appendix |
Annex D Cybersecurity relevance – example methods and criteria | Annex D Information Security Relevance - Example Methods and Criteria |
D.1 General | D.1 General |
D.2 Methods | D.2 Methods |
Annex E Cybersecurity assurance levels | Appendix E Network Security Assurance Classification |
E.1 General | E.1 General |
E.2 Determining a CAL | E.2 Determining CAL |
E.3 Using a CAL | E.3 Using CALs |
Annex F Guidelines for impact rating | Appendix F Impact Rating Guidelines |
F.1 General | F.1 General |
F.2 Impact rating for safety damage | F.2 Impact level of safety damage |
F.3 Impact rating for financial damage | F.3 Impact Rating of Financial Losses |
F.4 Impact rating for operational damage | F.4 Impact level of operating damage |
F.5 Impact rating for privacy damage | F.5 Privacy Impact Rating Appendix |
Annex G Guidelines for attack feasibility rating | G Attack Feasibility Rating Guidelines |
G.1 General | G.1 Overview |
G.2 Guidelines for the attack potential-based approach | G.2 Guidance on methods based on attack potential |
G.3 Guidelines for the CVSS-based approach | G.3 CVSS-based methodological guidance |
G.4 Guidelines for the attack vector-based approach | G.4 Attack vector-based methodological guidance |
Annex H Examples of application of TARA methods – headlamp system | Appendix H TARA Method Application Example - Headlight System |
H.1 General | H.1 General |
H.2 Example activities for concept phase of a headlamp system | H.2 Example of activities during the concept phase of a headlamp system |
BIBLIOGRAPHY | references |
Previous article:New system analyzes camera data in real time to detect not only occupants’ facial features but also their postures
Next article:Luminar to introduce active safety system at IAA Mobility
- Popular Resources
- Popular amplifiers
- A new chapter in Great Wall Motors R&D: solid-state battery technology leads the future
- Naxin Micro provides full-scenario GaN driver IC solutions
- Interpreting Huawei’s new solid-state battery patent, will it challenge CATL in 2030?
- Are pure electric/plug-in hybrid vehicles going crazy? A Chinese company has launched the world's first -40℃ dischargeable hybrid battery that is not afraid of cold
- How much do you know about intelligent driving domain control: low-end and mid-end models are accelerating their introduction, with integrated driving and parking solutions accounting for the majority
- Foresight Launches Six Advanced Stereo Sensor Suite to Revolutionize Industrial and Automotive 3D Perception
- OPTIMA launches new ORANGETOP QH6 lithium battery to adapt to extreme temperature conditions
- Allegro MicroSystems Introduces Advanced Magnetic and Inductive Position Sensing Solutions
- TDK launches second generation 6-axis IMU for automotive safety applications
- LED chemical incompatibility test to see which chemicals LEDs can be used with
- Application of ARM9 hardware coprocessor on WinCE embedded motherboard
- What are the key points for selecting rotor flowmeter?
- LM317 high power charger circuit
- A brief analysis of Embest's application and development of embedded medical devices
- Single-phase RC protection circuit
- stm32 PVD programmable voltage monitor
- Introduction and measurement of edge trigger and level trigger of 51 single chip microcomputer
- Improved design of Linux system software shell protection technology
- What to do if the ABB robot protection device stops
- CGD and Qorvo to jointly revolutionize motor control solutions
- CGD and Qorvo to jointly revolutionize motor control solutions
- Keysight Technologies FieldFox handheld analyzer with VDI spread spectrum module to achieve millimeter wave analysis function
- Infineon's PASCO2V15 XENSIV PAS CO2 5V Sensor Now Available at Mouser for Accurate CO2 Level Measurement
- Advanced gameplay, Harting takes your PCB board connection to a new level!
- Advanced gameplay, Harting takes your PCB board connection to a new level!
- A new chapter in Great Wall Motors R&D: solid-state battery technology leads the future
- Naxin Micro provides full-scenario GaN driver IC solutions
- Interpreting Huawei’s new solid-state battery patent, will it challenge CATL in 2030?
- Are pure electric/plug-in hybrid vehicles going crazy? A Chinese company has launched the world's first -40℃ dischargeable hybrid battery that is not afraid of cold
- Measuring the flow control valve signal of the auto repair actuator with an automotive oscilloscope
- How is this kind of PCB wiring designed using AD? Please give me some guidance, masters!
- EEWORLD University ---- Quartus Prime Development Process (Intel Official Tutorial)
- Issues with STM32L15xCC
- Access control panel with Bluetooth low energy and capacitive touch technology
- [A-Current Signal Detection Device] Sichuan Province-Second Prize
- IoT Smart Lights
- The problem of static electricity
- Flathead RVB2601 creative application development] @fxyc87 RVB2601-Qiqiao technology
- Looking for a DC/DC step-down chip