Security by design in the automotive development process

In the automotive domain, security is becoming more and more important – especially for the new generations of connected, (semi-)autonomous vehicles. In this article, I’ll explain the basic concept behind the term “security by design”. You will also learn how to develop a secure system design and which additional security challenges may arise. Let's go!

Cars have become “computers on wheels” with a multitude of external interfaces like NFC, Bluetooth, Wi-Fi or USB connectors. Already now, the majority of functions is implemented in software. As a result, the entire system becomes susceptible to malicious security attacks, including theft or tampering with data.

The integrity and ultimately the safety of the vehicle can easily be compromised without adequate security concepts in place. In order to develop and ship secure vehicles, manufactures need to pay attention to security aspects, starting from the early phases of the automotive development process.

What is security by design?

Let’s have a look at the basic concepts and ideas behind “security by design”.

Applied to the development process of vehicles, the security design needs to be considered in the early phases of the development that define the core functions and the structure of the vehicle.

A common approach to structure the phases of the automotive development process is the V-model:

Requirements are the starting point of the development process. Requirements can include functional and non-functional aspects, defined by the stakeholders of the system.

An example could be the requirement for a remote software update of an ECU via a 4G mobile communication channel (= functional) with a maximum duration of the remote update of 30 minutes (= non-functional).

Some requirements might be of a very technical nature and describe, e.g., existing interfaces or run-time environments that have to be taken into consideration when developing new functions. Other sources of requirements can be of normative origin, like safety or data privacy regulations.

Based on the initial set of requirements, the design of the system evolves.

A model-based design approach supports this process by breaking down the system under development (SUD) into functions, components, connections and data flows. Relevant assumptions, e.g., about the operational environment of the system, are also part of the design process.

While the level of abstraction in the design phase is still relatively high and often informal, the specification defines all aspects of the basic design in a more detailed fashion. This includes, e.g., the mapping of functions to components, specific protocols for data transport (e.g., CAN or Bluetooth), and specific aspects of software interfaces. The result of the specification phase has to be detailed and formal enough to become the basis of the implementation process for all hardware and software components.

The automotive security risk assessment

How do I know that a design is sufficiently secure?

As there is no such thing as absolute security, the designed system always involves a certain risk that needs to be assessed. This risk has to be at or below the threshold that is deemed acceptable by the manufacturer.

The risk level of a system design can be established by performing a security risk assessment, based on the first 3 phases of the development process. The requirements typically already include references to security, safety, or privacy-related norms, like ISO27001, ISO26262, or GDPR.

In the near future, ISO/SAE 21434 will apply to the secure development of passenger vehicles. Most norms recommend or even prescribe performing a security risk assessment at this stage of the development process. The security risk assessment looks into potential damages coming from violations of security aspects of the elements of the SUD.

Security aspects typically include the security goals of confidentiality, integrity and availability.

But what exactly are the potential damages that we have to take into consideration?

While data privacy focuses on legal aspects, safety consideration purely focus on potential injuries or death of driver or passengers. As security can affect both data privacy and safety, the security risk assessment must take into consideration legal damages and potential injuries.

Additional damages resulting from a poor security design might also be of financial nature, e.g., if valuable data is stolen.

Security issues might also lead to severe service degradation such as a vehicle with functional limitations or even being unable to drive at all. From a safety perspective, this stationary “safe state” is not problematic. From a manufacturer and passenger perspective, however, being unable to start the car is highly undesirable and should be taken into consideration.

Besides looking at potential damages, the likelihood of the negative consequences to materialize has to be considered. When looking at safety aspects of a system, the likelihood can often be expressed as a statistical probability, e.g., the mean time between failures of a component (MTBF) in defined operating conditions.

These likelihoods are often based on the laws of physics and remain rather stable over the lifetime of the system. Unfortunately, this approach does not work when determining the likelihood of cyber attacks.

In order to gain a sense of probability in security, potential attacks and countermeasures come into play. The easier an attack can be performed successfully, the more likely the resulting damage will occur. At the same time, controls or countermeasures can be put in place that make successful attacks harder and hence less likely.

The so-called risk factors for attacks and countermeasures are dynamic in nature as new vulnerabilities are discovered on a regular basis (e.g., the “heartbleed” vulnerability of the OpenSSL protocol) and hacking equipment becomes more powerful and affordable over time. 

The combination of potential damages and the likelihood of successful attacks, mitigated by some controls, deliver the overall risk potential of the system under development.

The overall process of the security risk assessment can be depicted like this:

Security by design – a model-based, iterative process

In systems engineering – and that includes the automotive development process – modeling systems has become the “weapon of choice” in order to deal with increased complexity. The proposed methodology for security risk assessment is therefore also a model-based approach, taking relevant security specific aspects into account.

However, the need for an iterative process in the modeling of security aspects is more pronounced than in other areas. Mitigating identified risks by controls and countermeasures has to reduce the remaining risk to an acceptable level.

At same time, controls like encryption, key management, or secure hardware elements have to be cost-effective. Thus a security risk assessment and a security by design process include the task of finding the most cost-efficient way to reach the security goals.

This can only be achieved in an iterative process by comparing the impact of various combinations of countermeasures and adjusting the requirements and the design accordingly.

System model and countermeasures influence each other. Encryption makes an attack harder to perform and can therefore be an effective countermeasure. At the same time, encryption introduces symmetric or asymmetric keys to the solution. Those keys then become part of the system model and therefore also of the design.

As a result, generation, protection and management of keys become an integral part of the system model and the security by design process.

Additional security challenges in the automotive domain

Let’s assume the design process was successful, and a secure system model (requirements + design + specification) with sufficient controls and countermeasures for a secure system evolved. Let’s also assume that the implementation was performed in a secure manner following, e.g., secure coding guidelines. No additional vulnerabilities were added to the system in the development process. All subsequent tests were successful, and the vehicle was introduced to the market.

In contrast to safety aspects of technical systems, the security environment is highly dynamic. Attackers are creative and resourceful. New vulnerabilities are discovered and reported on a daily basis. As a result, the security risk level of a vehicle or component is not stable over time but has to be re-evaluated periodically over the lifetime of the system.

For a particular vehicle model, this can easily mean 12 or 15 years of continuous risk assessment work!

Once risks are identified that are higher than the accepted risk level, new countermeasures have to be introduced, or existing controls have to be updated. This is a massive challenge for the automotive industry!

A model-based security risk analysis approach is therefore not only crucial in the design phase of a vehicle model or component, it becomes the basis of an ongoing security risk assessment throughout the lifetime of the vehicle.

Summary

In the automotive development process, security by design already begins in the requirement phase. In an iterative process that also includes the design and the specification phase, a secure system design evolves.

During several iterations, potential damages and threats are identified as part of a model-based security risk assessment. Suitable countermeasures are added to the design, ensuring that the desired risk levels are achieved using the economically and technically most viable set of controls. Based on the secure design, the system is then implemented, tested, and introduced to market.

Suitable tools support security analysts throughout the modeling process and ensure that all dependencies of assets, damages, threats, and controls are considered and that the resulting risk levels are calculated automatically.

Throughout the lifespan of the vehicle, the original system model and security risk assessment model can be used to apply updated vulnerability information as well as the most recent threat and control data.

The continuous monitoring of current risk levels can be used to plan software updates or introduce alternative interventions, if required. With suitable tooling support, the vehicle is designed in a secure manner right from the start and kept secure over the entire lifespan.

Want to read more about security engineering in the automotive industry?
The linked article gives further insights in the methodology of security risk assessments and tool support.

With YAKINDU Security Analyst (now itemis SECURE), itemis provides a model-based tool for performing security risk assessments during the design phase as well as throughout the lifetime of the vehicle model.

If you would like to find out more about how you can establish security by design in your organization and for your products, please contact us and request more information including a free webinar.

Information: YAKINDU Security Analyst Is Now itemis SECURE