GB/T 38628-2020 PDF in English
GB/T 38628-2020 (GB/T38628-2020, GBT 38628-2020, GBT38628-2020)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GB/T 38628-2020 | English | 355 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
Information security technology -- Cybersecurity guide for automotive electronics systems
| Valid |
Standards related to (historical): GB/T 38628-2020
PDF Preview
GB/T 38628-2020: PDF in English (GBT 38628-2020) GB/T 38628-2020
NATIONAL STANDARD OF THE
PEOPLE’S REPUBLIC OF CHINA
ICS 35.040
L 80
Information security technology - Cybersecurity guide
for automotive electronics system
ISSUED ON: APRIL 28, 2020
IMPLEMENTED ON: NOVEMBER 01, 2020
Issued by: State Administration for Market Regulation;
Standardization Administration of PRC.
Table of Contents
Foreword ... 4
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions ... 6
4 Abbreviations ... 8
5 Cybersecurity activity framework of automotive electronic system ... 8
5.1 Overview ... 8
5.2 Organization management ... 9
5.3 Cybersecurity activities ... 9
5.4 Support guarantee ... 11
6 Cybersecurity organization management of automotive electronics systems
... 12
6.1 Set organizational structure ... 12
6.2 Establish a communication and coordination platform ... 12
6.3 System construction and employee training ... 13
6.4 Test and evaluation ... 13
6.5 Stage inspection ... 15
7 Cybersecurity activities of automotive electronics systems ... 16
7.1 Conceptual design stage ... 16
7.2 System-level product development stage ... 22
7.3 Hardware-level product development stage ... 27
7.4 Software-level product development stage ... 31
7.5 Product production, operation and service stage ... 36
8 Cybersecurity support for automotive electronic systems ... 38
8.1 Configuration management ... 38
8.2 Demand management ... 38
8.3 Change management ... 39
8.4 Document management ... 39
8.5 Supply chain management ... 40
8.6 Cloud management ... 41
Appendix A (Informative) Typical cybersecurity risks of automotive electronic
systems ... 44
Appendix B (Informative) Examples of cybersecurity protection measures for
automotive electronic systems ... 49
Appendix C (Informative) Example of incident handling checklist ... 52
References ... 53
Information security technology - Cybersecurity guide
for automotive electronics system
1 Scope
This standard gives a framework for cybersecurity activities in automotive
electronics systems, as well as recommendations for cybersecurity activities,
organizational management, support assurance for automotive electronics
systems under this framework.
This standard is applicable to guide OEMs, parts suppliers, software suppliers,
chip suppliers, various service providers, and other organizations in the
automotive electronics supply chain to carry out cybersecurity activities, guide
relevant personnel to meet the basic cybersecurity needs during design,
development, production, operation, service when engaging in automotive
electronics systems.
2 Normative references
The following documents are essential to the application of this document. For
the dated documents, only the versions with the dates indicated are applicable
to this document; for the undated documents, only the latest version (including
all the amendments) are applicable to this standard.
GB/T 18336-2015 (all parts) Information technology - Security techniques -
Evaluation criteria for IT security
GB/T 20984-2007 Information security technology - Risk evaluation
specification for information security
GB/T 29246-2017 Information technology - Security techniques -
Information security management systems - Overview and vocabulary
GB/T 30279-2013 Information security technology - Vulnerability
classification guide
GB/T 31167-2014 Information security technology - Security guide of
cloud computing services
GB/T 31168-2014 Information security technology - Security capability
requirements of cloud computing services
inspection, and other activities.
5.3.2 Product development stage
The product development stage includes the development stage of system-
level product, the development stage of hardware-level product, the
development stage of software-level product. Figure 2 shows the basic process
of the product development stage as well as the relationship between product
development at the system level, hardware level, and software level. Figure 2
does not include the iterative process, but in fact many stages require repeated
iterations, in order to finally achieve the development goals.
The development stage of system-level product mainly includes initiation of
development of system-level product, cybersecurity technical specifications
(including system-level vulnerability analysis, cybersecurity strategy
specification, determination of cybersecurity technical requirements, etc.),
system design, system function integration, cybersecurity testing, cybersecurity
verification, cybersecurity evaluation and inspection, product release, etc.
The development stage of hardware-level product mainly includes initiation o
development of hardware product, hardware cybersecurity specifications
(including hardware-level vulnerability analysis, determination of cybersecurity
requirements), hardware design, hardware integration and cybersecurity
testing, verification of hardware cybersecurity requirements, detailing
cybersecurity evaluation, and so on.
The development stage of software-level product mainly includes initiation of
development of software product, software cybersecurity specifications
(including software-level vulnerability analysis, determination of cybersecurity
requirements), software architecture design, software unit design and
implementation, software unit testing, software integration, cybersecurity
testing, verification of software cybersecurity needs, detailing cybersecurity
evaluation and so on.
When cryptographic technology is needed in the product development stage, it
is necessary to comply with relevant national cryptographic management
provisions.
management end security and so on.
6 Cybersecurity organization management of
automotive electronics systems
6.1 Set organizational structure
Organizations need to attach great importance to cybersecurity; consider
cybersecurity at the strategic level of the organization; specifically reflect it from
the following aspects:
a) Formulate and implement the organization's cybersecurity strategy, policy,
objectives;
b) To implement the leadership responsibility system for cybersecurity, it may
establish a cybersecurity leadership group with the responsibility of
organized senior leaders, to be responsible for the supervision on
formulation and implementation of cybersecurity strategies, policies,
objectives, meanwhile coordinating the cooperation between various
departments;
c) Set up a special institute to be responsible for cultural construction,
information communication, training, cross-departmental resource
allocation and other related work related to cybersecurity;
d) Employees can clearly know the organizational settings and division of
responsibilities related to cybersecurity within the organization.
6.2 Establish a communication and coordination platform
The organization should establish internal and external information
communication and coordination channels for cybersecurity, including but not
limited to the following:
a) Develop a process for individuals or organizations inside or outside the
organization to report on cybersecurity incidents; clarify the interface
between relevant departments within the organization and the
responsibilities that shall be assumed;
b) Develop a process for notifying relevant parties about cybersecurity
incidents; carry out hierarchical management of the severity of the incident;
c) Develop a process for responding to and handling cybersecurity incidents
d) The evaluation team should not be employees of the organization being
evaluated;
e) The evaluation team should not induce the organization to use its own
services;
f) The evaluation team should record the results of the evaluation in detail,
including any new vulnerabilities found.
Note: This is mainly for the recommendation of the organization to hire a third-
party evaluation team. The organization's self-built evaluation team may refer
to it.
6.4.2 Cybersecurity test content
Vulnerability testing, penetration testing and fuzzy testing are important
methods for evaluating an object's cybersecurity capabilities. Among them,
vulnerability testing is a more common method, which can include but not
limited to the following specific methods:
a) Vulnerability scanning, to detect whether the object has vulnerabilities that
may be attacked;
b) Exploratory testing, to detect and investigate vulnerabilities that may arise
in software or hardware implementation;
c) Aggressive testing, invading the object by destroying, bypassing,
tampering with cybersecurity control measures, etc., to achieve the
purpose of testing the object's resistance to attack.
6.4.3 Cybersecurity evaluation
The cybersecurity evaluation is used to verify whether the currently
implemented cybersecurity strategy meets cybersecurity requirements and
whether it can effectively reduce threats and risks, which may include but not
limited to the following:
a) Evaluate whether the cybersecurity strategy at each stage meets the
cybersecurity requirements;
b) Evaluate whether the cybersecurity design at each stage complies with
the cybersecurity strategy;
c) For threats that are not resolved by the cybersecurity strategy, define them
as corresponding pending questions and assess whether the pending
questions can be accepted;
d) If the pending question is acceptable, provide a corresponding explanation,
c) Clarify the start time and deadline of each activity;
d) Clarify the reporting and supervision rules of each activity status.
7.1.4 Threat analysis and risk evaluation
The organization should conduct threat analysis and risk evaluation on the
automotive electronic system, in order to systematically identify the
cybersecurity threats that the automotive electronic system may face; make a
reasonable estimate of the cybersecurity risk, to provide basis for determining
cybersecurity goals of the automotive electronic system and taking appropriate
risk treatment measures. Grasping of technology of threat analysis and risk
evaluation and implementation in the early stage of product development, can
minimize the cost of expensive repairs caused by problems discovered at a
later stage of the product life cycle; in addition, as the product development
process continues to deepen, threat analysis and risk evaluation activities can
also be iterated in time for the gradual refinement of products in a timely manner,
to provide a basis for cybersecurity evaluation at each stage of product
development.
The threat analysis and risk evaluation activities of automotive electronic
systems should be carried out in accordance with GB/T 18336-2015, GB/T
20984-2007, GB/T 31509-2015, GB/T 31722-2015 and other standard,
combined with practical experience in the automotive industry. It mainly
includes the following steps:
a) Preparation: Determine the goal and scope of threat analysis and risk
evaluation.
b) Function definition: Identify the main functions of the automotive electronic
system and the assets that need to be protected.
Example 1:
The assets that need to be protected in automotive electronic systems can
be mainly considered from the following aspects:
- In-vehicle equipment: including ECU, sensors, actuators, network
communication equipment, etc.;
- Functional safety-critical and non-functional safety-critical applications
running on the equipment;
- Data link inside ECU, between ECU, between ECU and sensor/actuator,
between ECU and network communication equipment and application
program.
comprehensive analysis of the impact on the vehicle's functional safety,
privacy, economy, handling, etc. can be conducted comprehensively; for the
probability of the threat successfully carrying out the attack, it may
comprehensively consider various factors, including the time it takes to
attack (including the time to identify vulnerabilities, develop attack programs,
successfully install programs, etc.), expertise, knowledge of the attacking
target, time window of opportunity, requirements for special equipment, etc.
f) Risk treatment: Prioritize asset threats according to risk levels, especially
the need to identify threats with high risk levels and assess whether the
risk level of each asset threat is at an acceptable level; if the risk level is
unacceptable, it should consider applying appropriate methods or risk
control measures (see Appendix B for specific measures) to reduce the
residual risk of the system to an acceptable range.
Example 3:
In response to the cybersecurity risks that the ECU’s "CAN bus access"
described in Appendix A may face, the risk control measures that can be
taken are to provide a secure communication function (software) of the CAN
bus, to realize the anti-tampering and anti-replay mechanism of the
communication data.
Example 4:
In response to the cybersecurity risks that the vehicle gateway’s
"FOTA/SOTA" described in Appendix A may face, the risk control measures
that can be taken are to implement a secure FOTA/SOTA process, to prevent
the vehicle gateway firmware/software or data from being counterfeited,
tampered with, or subject to information disclosure during its update process.
Example 5:
In response to the cybersecurity risk of unauthorized access to the USB
interface of the onboard access device described in Appendix A, the risk
control measures that can be taken are to implement secure access control
on the USB interface and record the access events through the security log,
in order to timely identify possible unauthorized access.
7.1.5 Determination of cybersecurity goal
The organization should determine the cybersecurity objectives based on the
high-risk threats as identified in the risk evaluation results, especially the
highest-risk threats.
Example 1:
such as vulnerability testing and penetration testing. Based on the results of the
integration test, it is verified whether the cybersecurity technical needs are met,
then perform the cybersecurity evaluation for the system, finally the product is
officially released.
7.2.2 Initiation of system-level product development
The organization should initiate cybersecurity activities for system-level product
development, which may include:
a) Formulate a product development plan at the system level and clarify the
content and requirements related to cybersecurity;
b) Set up a cybersecurity group, which is specifically responsible for the
technical and management aspects of cybersecurity during product
development; determine the key members and responsibilities of the
group.
7.2.3 Analysis of system-level vulnerability
The cybersecurity team should conduct a vulnerability analysis of the system's
potential threats, to find areas where the system is more likely to be attacked,
which may include the following steps:
a) Classify the assets in the system; comprehensively rate various assets
according to importance and value. It should classify security
vulnerabilities according to the content of GB/T 30279-2013;
b) Find vulnerabilities and threats in higher-rated assets;
c) Design specific measures to repair vulnerabilities and counter threats.
Note 1: Compared with the conceptual design stage, more detailed
information will appear at the system-level stage, so it is necessary to carry
out a system-level vulnerability analysis.
Note 2: During the analysis, adequate communication should be conducted
to ensure that the cybersecurity needs of the system can be fully defined
and managed.
7.2.4 Specific cybersecurity policy
The organization should embody the cybersecurity policy in the conceptual
design stage into a cybersecurity technology policy, which is mainly aimed at
the parts of the system with higher cybersecurity risks; define a cybersecurity
design that can protect its functions and data at the system level.
7.2.5 Identification of cybersecurity technology needs
b) Whether the system can implement corresponding countermeasures
against threats.
c) Carry out vehicle-level system integration and testing, to confirm that all
system functions can work together properly and meet vehicle-level
cybersecurity needs.
7.2.8 Cybersecurity verification
In order to ensure that the applied security technology can meet the
cybersecurity technology requirements of the system, the organization should
verify its effectiveness through an independent cybersecurity evaluation team.
The available verification methods include:
a) Vulnerability testing, to determine that the system requirements for
reducing vulnerability risks have been fulfilled;
b) Penetration testing, by simulating actual combat attacks on the system, to
verify that the system can effectively implement the corresponding
security measures;
c) Fuzzy test, through a large number of data or signals, stress test the
system function to determine whether the system will produce loopholes
or abnormal behavior under the set conditions;
d) Inspection and verification using other test methods or tools.
7.2.9 System-level cybersecurity evaluation
After completing the cybersecurity verification, the organization should conduct
cybersecurity evaluation through an independent cybersecurity evaluation team,
generate a description of the cybersecurity status, evaluate the cybersecurity
status of the system. The main contents include:
a) Whether the cybersecurity needs at all stages of the product have been
met;
b) Whether the pending questions in the product development process are
properly handled;
c) For unresolved cybersecurity issues, provide explanatory documents that
explain why the cybersecurity issues can be accepted.
7.2.10 Stage inspection of system-level product development
Before the product is released, the organization should conduct a stage
inspection of system-level product development through an independent
technical expert group. Its purpose is mainly to re-check and confirm the
c) Determine the scope of hardware cybersecurity testing and evaluation.
7.3.3 Hardware-level vulnerability analysis
The organization should conduct hardware-level vulnerability analysis to
identify and quantify its cybersecurity risks and prioritize them.
Example:
Specific analysis aspects of hardware vulnerabilities in automotive electronic
systems may include but are not limited to:
a) Whether there are design defects or loopholes in the ECU hardware itself,
such as the lack of anti-signal interference, anti-reverse analysis and other
mechanisms, which leads to information disclosure due to subject to
corresponding attacks.
b) JTAG interface for debugging: Whether it is removed in the final hardware
product, if not, whether corresponding access control measures have
been taken (such as closing the interface in a non-debugging state). If the
interface is accessed illegally, malicious programs may be implanted into
the system.
c) OBD interface for vehicle diagnosis: Whether corresponding access
control measures have been taken for this interface. If the OBD interface
is used illegally, unauthorized devices may communicate with the
automotive gateway through the unprotected OBD bus, read sensitive
data in the gateway, or even directly read and write the onboard bus, send
forged control information, which seriously interfere with the normal
function of the car.
d) Serial port, USB and various wireless communication interfaces: Whether
corresponding access control measures have been taken. Unprotected
interface access may lead to the risk of the visitor's identity being spoofed,
data disclosure, access data being tampered.
7.3.4 Determination of cybersecurity needs
The organization should further determine the cybersecurity needs at the
hardware level based on the actual situation, which may include the following:
a) Check and update the system context as needed;
b) Clarify how the hardware supports the cybersecurity goals and tasks that
the entire system needs to achieve;
c) Define other constraints, including internal or external threats, legal and
regulatory requirements, cost constraints, etc.
c) Identify the supporting tools for the software development process; define
the credibility level of the tools, reference manuals and tutorials;
d) Choose appropriate software development methods;
e) Choose programming language and modeling language;
f) Plan software integration and testing process requirements, especially the
process and requirements of cybersecurity testing.
7.4.3 Determination of cybersecurity requirements
The organization should further determine the cybersecurity needs based on
the actual situation, which may include the following:
a) Check and update the system context as needed;
b) Clarify how the software supports the cybersecurity goals and tasks that
the entire system needs to achieve;
c) Define software non-functional parameters related to cybersecurity, such
as performance requirements, storage space requirements, reliability
requirements, etc.;
d) Define constraints on other aspects of software development, including
internal or external threats, legal and regulatory requirements, cost
constraints, etc.
7.4.4 Software architecture design
The organization should pay attention to considering the software architecture
design from the aspect of security, which may include but not limited to the
following:
a) Design to maintain the confidentiality, integrity and availability of data;
b) Use partitioned software architecture and isolation technology to ensure
security at the software level;
c) Provide error detection and error recovery functions;
d) Provide log and audit functions.
7.4.5 Software-level vulnerability analysis
The organization should conduct vulnerability analysis and establish a threat
model based on the software architecture design, which may include the
following steps:
b) Assess the risks that may be introduced by development tools;
c) Evaluate the consistency of data transmission between software units
such as functions, classes, modules, etc.;
d) Analyze the vulnerability of third-party software libraries.
7.4.8 Software unit testing
It shall follow the following requirements when the organization carries out
software unit testing:
a) Starting from the bottom of the software, test all software units, including
testing the software’s input, output, data flow/critical path, boundary
conditions, error handling, exception handling, failure and recovery
handling, etc.;
b) Consider the test content related to security;
c) Once a software unit fails the test, it shall take corrective measures
immediately, carry out regression testing after the software unit is modified,
to ensure that the modified software unit does not adversely affect other
units (including security effects).
7.4.9 Software integration and testing
After the software integration is completed, the organization should check
whether the corresponding cybersecurity needs are met, including the following:
a) Fuzz test all data access points (for example, wireless interface, Ethernet
interface, USB interface, CAN interface, etc.);
b) Conduct penetration testing and vulnerability testing, which can be
implemented by independent internal teams or external third-party teams;
c) Record test results and residual risks;
d) Develop an action plan to deal with residual risks;
e) Compile software operation guide.
7.4.10 Cybersecurity verification
The organization should check and verify the effectiveness of software-level
cybersecurity needs based on the results of software testing and other relevant
information. This verification activity should be conducted by an independent
cybersecurity evaluation team.
7.4.11 Detailing cybersecurity evaluation
In response to possible or existing cybersecurity incidents in the vehicle, related
infrastructure, application services, the organization should formulate relevant
content for incident response, to limit the impact scope of the incident, reduce
the degree of cybersecurity threats to the incident, minimize loss and damage,
avoid the recurrence of similar security incidents.
The incident response can specifically include the following activities:
a) Set up a special agency responsible for checking and analyzing incident
data, managing events (determining the priority of various incident,
sending incident warnings to relevant personnel, reporting problems in a
timely manner) and handling incidents;
b) Define the priority of the incident through written documents;
c) Create an incident response strategy and plan, which can include incident
handling and reporting processes; methods to confirm the authenticity of
threats; analysis of the causes of the incident and record evidence;
determination of the impact of the incident on the organization's
operations; the methods to correctly handle sensitive information;
recording of the actions taken in response to the incident; channels and
contents of communicating with relevant parties; summary of experience
and lessons learnt; consideration of applying it in subsequent product
development and design;
d) Once the incident response plan developed by the organization is
approved by management, the organization shall ensure that it is
implemented and reviewed at least once a year, to ensure its maturity and
ability to achieve incident handling goals;
Note: It may verify the feasibility of the drill of incident response plan.
e) The incident response team should use standardized operating
procedures, professional technical procedures, checklists (see Appendix
C) and forms, to minimize possible errors in the response.
Example:
In response to cybersecurity breaches in automotive electronic systems, it may
use such methods as remote software upgrades to repair vulnerabilities, to
ensure the security of the upgrade process itself, meanwhile carry out strict
security test verification and evaluation of the software before the upgrade.
7.5.3 Incident tracking management
In response to the cybersecurity threats and security incidents that have
occurred, organizations should record and track the entire process of incident
cases, to ensure that each demand does not contradict itself, that there is
no conflict between each demand and other demands, that there are no
duplicate demands;
b) Create a test process, to confirm that the demands are met;
c) Maintain the traceability of the cybersecurity objectives to their realization,
so as to check and verify the demands;
d) Ensure the clarity (no ambiguity, easy to understand), consistency,
completeness, achievability, testability of demand attributes and content.
8.3 Change management
The goal of change management is to analyze and control the changes of the
system or product in the life cycl......
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|