Cybersecurity, ASPICE, functional safety, etc. – in the automotive sector, many terms, and topics surface. This article gives you a concise insight into Automotive SPICE’s® new cybersecurity maturity model (ASPICE® CS), how it relates to ASPICE’s® general maturity model, and what the consequences are for automotive organizations. In addition, we shed light on why cybersecurity is becoming increasingly important in the automotive industry. We conclude with impulses for organizations that want to implement ASPICE® CS.
Background
Vehicles are increasingly becoming computers on wheels. Starting with the infotainment system, through “steer-/ brake-by-wire” to highly automated driving, vehicle computers sometimes take on safety-critical tasks.
At the same time, the digital networking of vehicles with their environment (Car-to-X) is growing. The X can stand for communication with other road users, e.g. in “platooning” – a system under development that enables convoy driving at a very short distance – or for communication with stationary infrastructure, e.g. radio and transmission masts for Internet connection with “over-the-air” updates.
The implementation of these functions sometimes requires extensive access rights to the vehicle functions. Each interface is also a potential target and represents a risk for the vehicle occupants and other road users: Conceivable damage of a successful attack ranges from reading personal data, to changing (safety-relevant) settings and functions, to taking over the vehicle.
The challenge for manufacturers of connected products (especially vehicles) is therefore to ensure digital attack security – commonly referred to as cybersecurity (CS) – along the entire value chain. In addition to project risk management, it is the task of the vehicle manufacturer to carry out risk management for digital attacks on the vehicle and its infrastructure over its entire service life – from development to placing on the market to decommissioning.
Relationship between ASPICE® and ASPICE® CS
ASPICE® (Automotive Software Process Improvement and Capability Determination) is a structured collection of best practices for development in the automotive industry. This standard allows an assessment of the performance of the development processes within the framework of assessments. In addition, the “Automotive Special Interest Group” in cooperation with the “Quality Management Center of the German Association of the Automotive Industry (VDA QMC)” published the “Automotive SPICE® for Cybersecurity – Process Reference and Assessment Model” (ASPICE® CS) in July 2021. It takes the contents of ISO/SAE 21434:2021 (Road Vehicles – cyber security engineering) for automotive development projects and derives a process maturity model with regard to CS for vehicle manufacturers analogous to ASPICE®. Like ASPICE®, ASPICE® CS is based on ISO 21434 but only deals with product development – excluding both the transfer to production and continuous support over the entire product life cycle.
ASPICE® CS is to be regarded as an independent maturity model, accordingly the maturity level of an organization is assessed in an independent assessment.
Compared to ASPICE®, ASPICE® CS contains a completely new “primary” process group “Cybersecurity Engineering Process Group (SEC). In addition, the “Aquisition Process Group” is supplemented by the new process core “ACQ.2 Supplier Request and Selection” for the selection of suppliers based on their CS qualification (Fig. 1). Furthermore, the process core “MAN.7 Cybersecurity Risk Management” is added to the Management Process Group (MAN).
Fig. 1: ASPICE® process groups, petrol drawn the new process groups from ASPICE® CS. [Source ASPICE® CS]
Dealing with (technical) risks
In practice, it is generally difficult to carry out the activities of risk management strictly chronologically in relation to the run of the V-model (see Fig. 1). This adversity is independent of whether it is a project risk, a functional safety risk, or a cybersecurity risk.
Risks are generally in natural competition with the project content. If content requirements are accompanied by an intolerable risk to the aspects to be protected (persons, environment, data, etc.), this content may not be implemented, or not in the desired form. This results in increased management efforts in the project from the addressed risks, which affect the entire project management triangle (quality, time and costs).
This inevitably results in an iterative approach: After planning the content with regard to requirements and architecture across the various levels (system level, SW level, HW level, etc.), the risks must be assessed. If these are not tolerable after their evaluation, risk measures must be derived and the planning adjusted accordingly, as well as the compatibility with the project schedule and the project budget must be compared. Only when content, costs, time and risk are consistent with each other can the implementation begin. This reconciliation must take place again in the course of the project with each plan change.
Integration of ASPICE® into the Development V
ASPICE® CS takes this iterative approach into account in the sense of risk-driven development. The relative assignment of the ASPICE® CS processes with those of ASPICE® are shown in Figure 2:
Fig. 2: Classification of the process groups from ASPICE® CS into the development V from ASPICE®. © Scharnhorst, Nils.
In Cybersecurity Risk Management (MAN.7), all known CS risk scenarios for the development under consideration are determined and evaluated along the entire chain of action, i.e. vehicle, infrastructure and backend (server/cloud). MAN.7 monitors and controls all CS-related risks over the entire development period, analogous to project risk management (MAN.5) for project risks.
In Cybersecurity Requirements Elicitation (SEC.1), functional and non-functional cybersecurity requirements are derived from the general CS risk scenarios. These supplement the general requirements from the system requirements survey (SYS.1) and are incorporated analogously into the (technical) requirements specification at system and software level (SYS.2 and SWE.1).
The Cybersecurity Implementation (SEC.2) describes the implementation of the Cybersecurity requirements specifications at the system and software level in the respective architecture design (parallel to SYS.3 and SWE.2). Cybersecurity requirements must be explicitly assigned elements of the architecture and specific solutions for prevention, detection and risk minimization. This applies in particular to safety-relevant interfaces to the (operating) environment. The CS solutions are implemented parallel to SWE.3 in the software elements, either by adapting software units or by designing additional new software units in addition to the “purely functional” software elements.
After implementation, it is necessary to check the fulfillment of the previously set requirements on the right side of the V-model. For this purpose, ASPICE® CS requires a risk treatment verification (SEC.3) for each level (software, system) to check the requirements of SEC.1 against the tests and test criteria defined there. In order to uncover previously unconsidered risks, ASPICE® also provides for validation tests (Risk Treatment Validation, SEC.4), such as penetration tests. These make it possible to check the achievement of cybersecurity goals independently of the identified risks. As part of the validation, undetected CS risks can be detected. These are to be included and evaluated within the framework of SEC.1. If the assessment shows that the new CS risks must be addressed, this requires a new run of the development VS (ASPICE® & ASPICE® CS).
Suppliers for cybersecurity projects must be checked so that they in turn manufacture their delivery items according to ASPICE® CS and are generally trustworthy. These requirements are explicitly set out in the new process core ACQ.2 Supplier Request and Selection in the procurement process group and thus supplement ACQ.3 (Contract Agreement), ACQ.11-13 (Technical, Legal & Administrative, and Project Requirements) and ACQ.15 (Supplier Qualification).
Outlook
In contrast to ISO 21434, ASPICE® CS only deals with product development, but not with continuous support throughout the entire product life cycle until the end of the product life. As with security updates of mobile phones, for example, the protection of connected vehicles must also be constantly checked and improved in the light of newly detected security gaps. Due to the high rate of innovation in cyber attacks compared to functional safety, this will require closer control over time.
The fast, effective and cost-efficient response to new attack scenarios and vulnerabilities during the product lifetime places additional demands on the product. In order to partially compensate for the more complex product development and maintenance, a modular and standardized product architecture (“secure-by-design”) is recommended. The quick encounter of future security vulnerabilities in existing systems in combination with long-lasting backward compatibility leads to a long product life. If no updates are provided at a certain point in time (due to technical or economic aspects), the use of the vehicle becomes potentially dangerous and, in the worst case, can be prohibited by law. Will there be a defined product lifetime in the future and how to deal with “end-of-life vehicles”? This is followed by many questions, which, however, would go beyond the scope of this article and still offer a lot of discussion potential for e.g. product management.
For the implementation of the content from ASPICE CS, an extension of existing roles in the area of requirements development and architecture to include cybersecurity expertise is necessary, as well as the creation of new roles, in particular for the validation of cybersecurity measures (“hackers”). Especially the latter requires a staffing of specialists, who will be increasingly in demand in the future.
The validation tests for cybersecurity are less clearly definable compared to verification, as previously unknown vulnerabilities are to be identified and creative test methods are required accordingly. Equally unclear is the right balance between a standardized approach (and thus controlled expenditure of time and resources) and free testing (how long does it make sense to try it out? How does the probability of a successful hack scale to the time required? When is a validation over?). ASPICE® CS makes no statement about this and it is up to the organizational units to define answers with the help of additional standards and regulations such as ISO/SAE 21434:2021.
Conclusion
With ASPICE® CS, the Quality Management Center of the German Association of the Automotive Industry (VDA QMC) complements the process reference and assessment model ASPICE® with an independent model for cybersecurity content, which is used in independent assessments. However, both models can be related to each other, as shown in Figure 2 above. In contrast to the underlying ISO/SAE standard 21434:2021, ASPICE® CS only considers product development. However, there is no consideration of how cybersecurity should be handled over the entire product life cycle and how the processes can be evaluated.
Avoidable stumbling blocks
Together with our customers, we engage in challenging projects every day in order to raise “old” approaches in product development to the latest state of the art, to set new impulses and to design and implement tailor-made solutions. This often reveals avoidable stumbling blocks, which we would like to advise you against at this point:
- The consideration of the latest state of the art only when it is demanded by external stakeholders. In most cases, the implementation times are no longer sufficient and task forces have to be established.
- The use of a team with insufficiently experienced team members, as the internal experts are used for higher priority day-to-day business. In this case, trend-setting decisions are made incorrectly, the projects are delayed and the grievances are usually only noticed at 3/4 project duration. A correction is hardly possible here.
- The attempt to transfer the requirements 1:1 from the exemplary process architectures into your own organization. If no premature pilots/simulations take place, this error is only noticed in the rollout, the users show incomprehension and the acceptance fails. The process model is only of little use and it is not uncommon for an almost complete re-attachment of the project to be required.
Do you have any questions or would you like to exchange ideas with us on topics without obligation? Feel free to contact us, we will support you in identifying your needs, the process concept up to the sustainable implementation. In doing so, we build on our many years of experience in the field of product development, the design of processes and organizations together with our partner network.
