Cybersecurity as a plugin into ASPICE and V-model

Before we dive in into the topic of combining V-model with cybersecurity, let’s face the facts. 

The automotive industry has not viewed cybersecurity as an essential consideration in the past 40 years, so the industry is lacking in this area compared with almost any other sector. Telecommunications introduced cybersecurity regulations in the 90’s and early 2000’s and the medical sector even earlier than this. Since then, vehicles have become connected to the internet, and some of the manufacturers (e.g. Tesla) have over-the-air software updates. We also have communication buses like CAN or LIN or even Ethernet, that are now widely used in the car production industry and that allow for steering vehicles remotely. 

So, it’s about time for the automotive sector to make a huge shift from focusing only on mechanics to thinking about the electronic and cybersecurity aspects of car production. Not doing so would result in a constant threat of a third-party taking control of the car while it’s being driven for all new models.  

How is cybersecurity regulated in the automotive sector? 

Cybersecurity has been a part of different directives over the years, but never the focal point. Responsibility has fallen to a skilled System Architect who would design the system and make changes to ensure the safety of a certain project. It has usually been done through mapping the automotive network of in-vehicle devices and components and then limiting access between them.  

That changed last year with the Society of Automotive Engineers (SAE) issuing their ISO/SAE 21434:2021 – Road vehicles – Cybersecurity engineering norm. There’s also ISO/TR 4804:2020 Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation as well as a TISAX standard which regulates information security in the automotive industry. 

Automotive SPICE for Cybersecurity 

Although the topic of cybersecurity was overlooked in the automotive industry for many years, it’s no longer true to say that it hasn’t changed. The renowned German Association of the Automotive Industry (VDA) issued the Automotive SPICE for Cybersecurity guidelines last February. They now serve as a baseline for any company working with OEMs and for the car manufacturers themselves. 

The guidelines are an extension of ASPICE and Functional Safety can be used indirectly to cover every stage of the V-model when it comes to cybersecurity. Our Automotive Engineers at Spyrosoft have created a process template that allows them to operate more efficiently and apply the guidelines to real-life projects developed for our clients.  

For more information on what ASPICE is, check our introductory guide >>>> What is ASPICE

 Although the guidelines are based on the traditional V-model where certain tasks are grouped into processes, they add another layer to the well-known levels covering: 

• Acquistion Process Group (ACQ) 
• Supply Process Group (SPL) 
• System Engineering Process Group (SYS) 
• Software Engineering Process Group (SWE) 
• Supporting Process Group (SUP) 
• Management Process Group (MAN) 
• Reuse Process Group (REU) 
• Process Improvement Process Group (PIM) 

The group of activities related to cybersecurity was named Cybersecurity Engineering Process Group (SEC) and it includes 4 elements.  

Let’s go through them one by one and decipher them together. 

SEC.1: Cybersecurity Requirements Elicitation 

This is the first step of the process, and it requires the identification of cybersecurity requirements and goals based on the risks that need to be mitigated in the Standard Risk Management is MAN.5 where MAN.7 is Cybersecurity Risk Management. At this stage, we need to assess what would be the acceptable level of risk for any threats that cannot be avoided. To achieve this goal, a set of non-functional and functional requirements needs to be established.  

The guidelines also specify certain rating rules when it comes to risks and requirements, so they would be addressed and identified to ensure safety. 

SEC.2: Cybersecurity Implementation 

The next step is all about implementing actions aimed at mitigating the risks. The best way to do that is by refining the architecture elements of a product or system in line with the goals and requirements established at the previous stage. To do that, you need to analyse the architecture first and look for vulnerabilities that have not been identified previously. 

This may also involve installing cybersecurity controls to limit the risks and warn you and your team if anything goes wrong. These controls can include for example, mechanical alarm elements, advanced software algorithms, hardware solutions and/or encryption.  

SEC.3: Risk Treatment Verification 

Once you have identified cybersecurity goals, requirements and vulnerabilities, and implemented elements aimed at mitigating the risks, it is time to evaluate the process so far and check if you have been doing enough. This can be achieved at the Risk Treatment Verification stage by ensuring that the previous phases of the process have been implemented correctly and that they do – in fact – minimise the risks.  

Some of the verification methods specified in the guidelines include: 

• static software analysis, 
• software unit testing, 
• software integration and acceptance testing, 
• system integration and acceptance testing.  

It is important to note here that the verification cannot prove that the correct risk management measures have been specified and implemented. This is what the next stage is for. 

SEC.4: Risk Treatment Validation 

The Risk Treatment Validation phase focuses on ensuring that the system that you have integrated is successful at addressing the previously specified cybersecurity goals. 

Once again, there are specific validation methods – as follows: 

• vulnerability scanning, 
• penetration testing, 
• interface testing 
• fuzz testing. 

The validation process ought to be precisely and extensively documented to ensure that it’s completed and managed correctly. 

It’s worth remembering that cybersecurity is not only about processes but also about analysing potential risks, penetration testing and coding standards that identify the best practices for writing understandable and coherent code.  

There are also certain checkers such as Computer Emergency Response Team (CERT) Coding Standards and Open Web Application Security Project (OWASP), rules that ensure security within a project. We can then check the code not only dynamically by launching scripts that will be able to test it, but also do it statically by ensuring that the code is aligned with the guidelines. 

The security risk assessment called the Threat Assessment and Remediation Analysis (TARA), that allows for the identification of cyber-vulnerabilities and mitigates them, should not be overlooked. 

Over to you 

If you’re not sure how to run tests and validation processes to ensure the safety of your automotive project, then we can help. Our Automotive Engineers are ready to support you and your team by managing Automotive SPICE, Functional Safety and cybersecurity requirements, addressing vulnerabilities and designing solutions aimed at limiting risks. 

Check out our Automotive Safety offer for more information and contact us if you have any questions. 

Automotive Safety at Spyrosoft