Overview
ISO/SAE 21434 is the first global network security standard for the automotive industry jointly developed by SAE and ISO. It comprehensively defines the network security requirements for road vehicles, components, and interfaces, and provides detailed descriptions on how to achieve network security management objectives based on network security issues. ISO/SAE 21434 is regarded as an industry consensus and an important reference document for regulatory and certification agencies in network security.
ISO/SAE 21434 mainly addresses vehicle network security from 15 perspectives. Chapters 5 to 7 provide an overall description of the network security requirements for vehicle networks at a macro level:
- Overall network security management
- Project-based network security management
- Continuous network security activities
The following 7 chapters define the requirements for vehicle network security at each stage of the product life cycle, from risk assessment, concept development, verification to production, operation, and retirement.
The final chapter, “Distributed Network Security Activities“, mainly introduces the network security requirements for asset identification, quotation requirements, responsibility distribution, and other aspects in the context of current distributed collaborative development of vehicles.
Each chapter is described from the perspective of “Overview, Purpose, Input, Requirements and Recommendations, Work Products”. In the following articles, each chapter will be interpreted one by one.
Overall Requirements
Chapter 5, Overall Cybersecurity Management, sets the strategic requirements for network security management at the company/organizational level. Its central idea is to develop network security management strategies and measures for vehicles from the perspective of the entire life cycle of the vehicle at the company-wide level.
The standard proposes 8 global-level network security management requirements:
Cybersecurity Governance
- [RQ-05-01]: The organization must define a cybersecurity policy.
This policy includes: a) acknowledgment of road vehicle network security risks; b) senior management’s commitment to managing network security risks.
-
[RQ-05-02]: The organization should establish and maintain organizational-level rules and processes to support the implementation of relevant requirements and the execution of network security activities.The process can take the form of process definition, technical rules, methodology, or templates, covering the entire lifecycle of the project, including important activities such as network security risk management, information sharing, vulnerability disclosure, network security monitoring, and incident response.
-
[RQ-05-03]: The organization should allocate and authorize responsibilities for network security activities.
-
[RQ-05-04]: The organization should provide the resources necessary to address network security issues.
-
[RQ-05-05]: The organization should identify professional fields related to network security and establish and maintain channels of communication among these fields.
-
[RQ-05-06]: The organization must define a risk value in the risk matrix.
A risk matrix will be detailed in 8.8 Risk Determination.
Cybersecurity Culture
- [RQ-05-07]: The organization must establish and maintain a cybersecurity culture.
- [RQ-05-08]: The organization must ensure that personnel participating in network security have the corresponding abilities and awareness.
This includes knowledge, experience, network security-related training, tools, systems, and so on.
- The organization should establish and maintain continuous improvement processes.
Cybersecurity Risk Management
- [RQ-05-09]: Cybersecurity risk management should comply with ISO 31000.
- [PM-05-01]: The organization can maintain consistency between network security risk management and enterprise risk management.
Organizational Cybersecurity Audit
- [RQ-05-11]: Organizational cybersecurity audits should be conducted to independently judge whether the organization’s processes meet the requirements of this standard.
Information Sharing
- [RQ-05-12]: The organization should define environmental conditions and consider which internal and external sharing is necessary, allowed, and prohibited.
Management System
- [RQ-05-13]: The organization should establish and maintain a quality management system to support network security engineering in accordance with international standards or equivalent standards.
- [RQ-05-14]: Network security configuration information for mass-produced products should remain available until the end of maintenance for the product.
- [RC-05-01]: A network security management system for production manufacturing processes should be developed.
Tool Management
-
[RQ-05-15]: Tools that can affect relevant projects, systems, and components should be managed.
-
[RC-05-02]: Before product support ends, a corresponding environment that supports network security incident response remedies must be able to be replicated.Information Security Management
-
[RC-05-03]: The relevant information attributes of the work products required by the network security plan should be managed by an information security management system.
According to the above 8 requirements, the following work products should be produced:
- [WP-05-01]: Network security policies, rules, and procedures.
- [WP-05-02]: Evidence of competence management, awareness management, and continuous improvement.
- [WP-05-03]: Organizational-level network security audit report.
- [WP-05-04]: Evidence of organizational management system.
- [WP-05-05]: Evidence of tool management.
*RQ: Requirement; RC: Recommendation; PM: Permission; WP: Work Product.
It can be seen that 21434 mainly elaborates on the activities that should be taken by organizations at the network security level in this chapter. In the process of implementation in the automaker, this work is centralized in the company’s system department, with quality assurance and IT departments as support. Because it involves company-wide processes, organizational structure, and management measures, the entire car factory usually matches the corresponding requirements of 21434 based on its own existing processes and highlights the evidence of network security on work products to meet the standards requirements.
In fact, this top-down, logic-driven network security system construction is a relatively ideal situation. In reality, more cases are driven by regulations. In order to meet the form certification requirements of VTA, the automaker first conducts research on network security requirements based on products, ensuring compliance technically and promoting system construction from the bottom up. After all, there is relatively loose operation space of “document review” in the system, but if the form certification on the product doesn’t pass, it is likely to be “rejected”.
Project Dependent Cybersecurity Management
The chapter on project-dependent cybersecurity management gives a generalized, project-level network security management requirements. It includes the network security activities that need to be implemented, the responsibility assignment of each activity, the pruning principle, and the requirements for network security cases and network security assessments.
Cybersecurity Responsibility and Their AssignmentCybersecurity Plan
This is one of the key parts of this chapter, and the steps to develop a cybersecurity plan are as follows:
- Firstly, identify which components are related to cybersecurity. Appendix D provides a decision-making process for this.
- Analyze the components to determine whether they are newly developed or reused, in order to determine whether pruning is necessary.
- Based on the results of the above analysis, and in accordance with the requirements of [RQ-05-03] and [RQ-05-04], develop a cybersecurity plan and assign responsibilities.
The following requirements must be met for the cybersecurity plan:
- The cybersecurity plan should be incorporated into the project development plan.
- Activities in both the conceptual and product development phases of the cybersecurity plan must meet the requirements specified in this standard (which will be discussed in later chapters).
- The cybersecurity plan must include:
- The purpose of the activity
- Dependencies on other activities or information
- The person responsible for the activity
- Resources needed for the activity
- The start and end times, as well as the duration of the activity
- Identification of the work product
- Relevant activities and work products need to be maintained and updated
- If the activity involves a vendor, the requirements for cybersecurity activity planning in Chapter 15 of this standard must be followed
- All work products generated by cybersecurity activities must be subject to configuration management, requirements management, and document management.
Tailoring of the Cybersecurity activities
In 21434, it is allowed to tailor the cybersecurity activities if necessary. If pruning is implemented, evidence must be provided to demonstrate that the relevant cybersecurity objectives can still be fully achieved.
The standard specifies three situations where tailoring can be performed: reuse, components outside the requirements, and existing components. In these three situations, pruning must adhere to the requirements and recommendations in the standard.
Reuse
Component reuse is very common in vehicle development. Although reused components use existing architecture, interfaces, and security solutions, necessary analysis of the component is still required due to changes in the operating environment, configuration information, and continuous development of attack techniques and new vulnerability discoveries. Reused components must undergo reuse analysis, which follows the steps below:- Identify changes in the environment where the component will be used, design changes, and changes in configuration or calibration data;
- Analyze if the component meets the current project’s network security requirements, and if existing work products are sufficient to support its integration into the new project;
- Identify missing work products and network security activities, and develop a network security plan for the component.
Component out of context
A component out of context usually refers to pre-developed or pre-deployed components provided by suppliers. These components are usually reserved for platform development and are not within the scope of the current product requirements.
For such components, 21434 requires recording their expected usage, environment, and interfaces in work products, and these components must be developed based on the network security requirements of the expected usage.
Off-the-shelf Component
Off-the-shelf components refer to software that is not developed specifically for the project, such as third-party software, open-source software libraries, and so on. For such components, 21434 requires collecting their relevant network security information and ensuring that their related evidence documents are sufficient to support the current project’s network security requirements.
Cybersecurity case
A cybersecurity case is the object of network security assessment. The case must provide a series of work products required for network security planning to demonstrate the implementation of network security in this project.
Cybersecurity Assessment
The purpose of cybersecurity assessment is to determine the level of network security implementation of the object or component and to determine if it can achieve the network security objectives required by this standard.
The verification of whether network security activities are performed and the degree of implementation is mainly based on the review of work products and documentary evidence. The following figure shows the main contents of cybersecurity assessment:
The evaluation results include acceptance, conditional acceptance, and rejection. Conditional acceptance usually proposes corrective measures in the evaluation results and monitors the completion of corrective items throughout the project phases.
Release for Post-Development
The following work products must be released before post-development begins:
- Cybersecurity case
- Cybersecurity assessment report
- Network security requirements for post-development.## Continuous Network Security Activities
Unlike most engineering activities in traditional vehicle development, network security activities are continuous throughout the entire lifecycle of the product. OEMs not only need to conduct necessary risk analysis and network security development during the development phase, but also need to implement network security monitoring and operation, establish a mechanism for emergency response to network security incidents, and continuously ensure the network security of vehicles throughout the entire product lifecycle. The discovery of new vulnerabilities, network security emergencies, and the emergence of new attack techniques may trigger network security activities.
In 21434, four continuous network security activities are required:
- Cybersecurity monitoring
- Network security event assessment
- Vulnerability analysis
- Vulnerability management
Cybersecurity Monitoring
By continuously collecting information on potential threats, vulnerabilities, and possible solutions of components through cybersecurity monitoring, OEMs can respond to known and newly emerging threats. The information obtained from monitoring can serve as inputs for vulnerability management and network security incident response.
The information for monitoring can come from external or internal sources.
External sources: cybersecurity researchers, commercial/non-commercial sources, supply chain, customers, government
Internal sources: vulnerability analysis results, on-site collected information (such as vulnerability scan reports, maintenance information, customer usage information), configuration information (such as software/hardware material lists).
The collected information needs to be classified to determine whether it can be defined as a network security incident. The organization needs to define a classification criterion, which can refer to the following factors:
- Whether it comes from a known and trustworthy source
- Determine the risk of the information in various threat scenarios according to [RQ-09-05];
- Type of information (active attacks, POC tests, etc.)
Output products:
Cybersecurity monitoring source list, network security information classification result.Cybersecurity Event Assessment
The purpose of a cybersecurity event assessment is to determine the severity of the event and make decisions on whether or not to initiate a response activity. An analysis of the event is conducted based on vulnerability analysis to determine if it affects relevant components. If not affected, corresponding cybersecurity activities can be dispensed with. If impacted, vulnerability management or cybersecurity emergency response should be carried out.
Outputs:
Results of cybersecurity event assessment
Vulnerability Analysis
Inputs for vulnerability analysis come from previous cybersecurity event assessments, past vulnerability analysis reports, verification reports, and security emergency response information. The purpose is to check the degree of vulnerability of a weakness and evaluate whether it can be exploited for a cyber attack.
The objects of vulnerability analysis are weaknesses, including the following types:
- Lack of requirements or specifications
- Architectural or design weaknesses, including incorrect security protocol design
- Weaknesses in implementation, including hardware and software defects and security protocol misimplementation
- Weaknesses in operational processes and procedures, including misuse and inadequate user training
- Use of outdated or deprecated functions, including confidential algorithms
Using attack path and attack feasibility analysis methods in Chapter 8, determine the attack feasibility level for each vulnerability.
Outputs:
Results of vulnerability analysis
Vulnerability Management
Vulnerability management is carried out based on previous vulnerability analysis and cybersecurity event assessment results to ensure that corresponding risks are disposed of. In this activity, principles for risk disposal must be defined to ensure that each risk has a corresponding disposal measure. Risk disposal principles may be based on vulnerability analysis results, risk determination results, and other information. Specific methods for vulnerability disposal will be introduced in Chapters 8, 9, and 10.
Note: Accepting risk is also a risk disposal measure, but the reasonable reasons for accepting risks need to be explained and recorded.
Outputs:
Basic principles of vulnerability management
Finally, summarize the inputs and outputs of the four activities introduced in this chapter in a table:
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.