A cybersecurity management system (CSMS) is understood to be all the necessary actions at company level for a product to meet relevant cybersecurity standards. The related UN regulation R155 extends the type of approval for vehicles to a management of cybersecurity over the entire life cycle. The standard on cybersecurity in the automotive industry is ISO/SAE 21434, which provides concrete guidance on how to meet the certification for UN Regulation R155. Both UN Regulation R.155 and ISO/SAE 21434 are expected to apply to new type-approved vehicle types from mid-2022 and to all newly produced vehicles from 2024. A summary on the scope and context of the introduction of the UN Regulation can be found here.
This article discusses concrete steps for implementation. To get an overview of the requirements in terms of content, the individual sections of the ISO/SAE standard are described below. While the first four sections cover general information, such as the scope and terms, the requirements for a CSMS are divided into the following areas:
- Section 5: Management of cybersecurity systems
- Section 6: Risk determination methods
- Section 7: Concept phase
- Section 8: Product development
- Section 9: Production, operation and maintenance
- Section 10: Supporting processes
Management der Cybersecurity Systeme
The ISO/SAE 21434 standard differentiates between a CSMS for the organization and the application of the CSMS at product level. At product level, a differentiation is made via the product life cycle. This is because this kind of system (section 5) must cover the entire cycle of a vehicle, starting with the design phase, planning of production, development, through the supply chains, to commissioning and ultimate scrapping.
In the organization, responsibilities for cybersecurity activities must be clarified at the project level and communicated to authorities. For each item, a cybersecurity plan must be designed that reviews a product in the portfolio for its relevance to cybersecurity, as well as whether it is a new development or reuse. Once a process is established at the organizational level, it must pass a cybersecurity audit by an independent auditor.
Risk determination methods
An essential part of ISO/SAE 21434 is risk analysis. The standard offers several methods (section 6) for the analysis, such as EVITA ("E-Safety Vehicle Intrusion Protected Applications"), HEAVENS ("HEAling Vulnerabilities to ENhance Software Security and Safety"), TARA ("Threat Analysis and Risk Assessment") and others. The TARA method is used to identify critical areas that are exposed to risks. It falls to the specialists to select a suitable method.
Considering a chronological order, the first step is a (7.2) item definition, which can be performed using an attached questionnaire. The (6.2) asset identification is about the determination of values (e.g., product characteristics) and the (6.3) threat scenarios (e.g., a data-relevant, financial or operational damage). The threat scenarios are measured by a threat level (TL) according to four parameters: Expertise, knowledge of the attack target, "Target of Evaluation" (TOE), the opportunity factor and the available equipment. Based on the threat scenarios, the impact of the different options including (6.4) damage assessment will be evaluated. For the purpose of evaluation (6.5), damage assessment is divided into serious, significant, moderate and minor incidents.
The (6.6) attack path analysis produces a list of cybersecurity-relevant vulnerabilities. These can be deficiencies in the implementation, for example. These possible attack paths can be exploited to realize a threat. The possibility of these attack paths is classified in process step (6.7) attack feasibility.
Finally, the (6.8) risk assessment and treatment is carried out with classification of the identified threat scenarios based on the impact and feasibility of attacks as well as the selection of suitable (6.9) risk treatment options in a risk report. No specific methods are named in the risk assessment.
The "Cybersecurity Assurance Level" (CAL) is also derived from the risk assessment and is divided into four classes with different levels of criticality. In this context, the CALs represent a qualitative assessment of the product developers. Depending on the objective, certain cybersecurity activities may be redundant. If a component is assigned to the highest level four, it requires a high level of security.
Design phase of a CSMS
The design phase (section 7) addresses cybersecurity objectives that result from a threat analysis and risk assessment, and defines cybersecurity requirements to help achieve the cybersecurity objectives.
CSMS for product development
Section 8 goes into detail about the implementation and review of cybersecurity requirements specific to the product development phase. A differentiation is made between a system, hardware and software development phase. The V-model provides a basis here for simply depicting the necessary process steps, in this case the verification and validation steps. As with functional safety, traceability is particularly important. Furthermore, all physical and virtual interfaces of the hardware should be identified in terms of cybersecurity with regard to their purpose, use and parameters. After all, in the event of an attack, these also represent possible entry points.
For work on software in the cybersecurity environment, the standard specifies that the requirements are derived from the cybersecurity system and associated software modules. The specification and implementation of the software must be constant and dynamically verifiable.
Production, operation and maintenance
Section 9 focuses on the production, operation, and maintenance phases. Specifically, it requires processes for monitoring cybersecurity activities to collect and evaluate relevant data. Also mentioned are the handling and response to cybersecurity incidents, as well as cybersecurity events and basic cybersecurity requirements and capabilities.
Supporting processes
The supporting processes described in the last section (section 10) aim to define interactions, dependencies and responsibilities between customers and suppliers.
Current challenges and solutions in practice
In summary, a cybersecurity management system involves a variety of parameters and processes, with several factors to consider when implementing it. Potential problems include missing or insufficient compliance monitoring, delays in implementation, missing risk identification processes and lack of transparency. To prevent such challenges from the outset, msg supports you as a competent partner with appropriate tools, solutions and expertise. For example, with THREATGET manufacturers and suppliers have a tool available to prepare the cybersecurity of their vehicle systems for type approval in compliance with the authorities and thus remain competitive in top markets.
The IT, automotive and homologation experts at msg
msg has in-depth IT and industry expertise. Experts in the areas of cybersecurity and software update management systems as well as electrics/electronics support our customers in identifying relevant regulations, in evaluating company-specific processes and homologation procedures up to obtaining type approval. From consulting, conception, functional specification up to the implementation of IT systems – we are ready to help.
