Practical Experience with Assessing Automotive Security Risks

We are in contact with customers who want to better understand what security risks their products may pose. Other customers are motivated by new standards and norms that they want to meet and that require risk management for products. The questions and the level of experience of the customers are very diverse and range from the initial question “Why is a risk analysis useful and important?” to “What does an update of my previous analysis look like?”.

The biggest challenges often start when the first risk analysis for a customer is completed. This is the time to maintain the documents and results so that the risks can be kept current and up to date. Our experts themselves must therefore always be up to date with regard to current threats and technical developments and must constantly exchange information with each other. By doing so, they ensure that the results remain as consistent and comparable as possible for customers.

More and more customers have established security, just like safety, in their development processes. Safety naturally has a longer history and tradition, especially in the automotive industry. Security is still comparatively new here. But this topic has become a common theme.

Most clients assess the overall picture of risks realistically. But especially when it comes to the details, technical experts are sometimes surprised that the measures that are built up in Safety can be circumvented with typical security attacks, so that the safety measures are not necessarily to be evaluated as security measures.

There is an interlocking of safety and security here. In the case of an unsecure car, attacks and malfunctions can also lead to a safety problem and, in the worst case, human life is endangered.

In the more recent development, vehicles have also become data carriers in which personal data are processed, such as locations, driving behaviour or credit card information. Here the security measures must also be able to guarantee the protection of areas such as privacy and data protection.

Originally, risk analyses and methodologies were often inspired by established safety procedures. Now security has emancipated itself to a certain extent and there are requirements, e.g. with ISO/ SAE 21434 and the conditions for type approval according to UNECE WP.29, that cybersecurity must and should not only be considered systematically throughout the entire development process, also for vehicles. This is a new direction, which gives the whole area a greater focus. Risk analyses are an important aspect here as part of the overall risk management.

One challenge is that in the entire value-added chain for a vehicle, every supplier and also the car manufacturer itself naturally makes a certain contribution to the overall vehicle. In the end, however, the security for the entire vehicle must be assessed. This means that not only in the supply chain for the individual parts and for the interfaces between the parts must be coordinated, but a common language must also be found for communicating risks and security requirements. In this way, risks that may have been identified for a sub-component by one supplier can also be communicated reliably and appropriately through the chain so that other suppliers or the car manufacturer can take this into account in their overall risk assessment.

There are two paths to consider here. On the one hand, in a technical development project there is the requirement that risk analyses, security concepts and also suitable test measures, such as code reviews or penetration tests, are anchored in the development process and this is also constantly checked for compliance. On the other hand, on an organizational level we have the challenge of appointing persons responsible for certain topics and also to provide them with the appropriate authority and the necessary importance. In addition, there must be sufficient training measures for the people who are to implement the defined processes at the technical level. When thinking about the life cycle of a component or an entire vehicle, a supporting infrastructure should also be created so that, for example, weak points that are identified subsequently can be reacted to with the possibility of installing an update.

The first step is to record the current status. For this purpose, we first get an exact picture of the system/subsystem to be analysed. This means what kind of component, what kind of device or perhaps what kind of IoT device we should analyse. We record all data, interfaces and components that are available and which functions are to be implemented. Together with the customer, we then define what is worth protecting in the system.

As next step, we conduct the threat analysis. For this purpose, attack trees are created in which the individual attack steps that a potential attacker would carry out to attack the system are systematically documented. At this point it is evaluated how likely or costly these attacks are.

In the third step, we deal with the evaluation of the damage caused by the attacks on the system. For example, safety, privacy or financial damage can result from a successful attack.

The final step involves combining likelihood and impact to calculate a risk value. This subsequently serves as the basis for the client to decide which risks are acceptable in the system or which have to be mitigated. For the risks to be mitigated, High-Level Security Requirements are identified again at the end so that the customer knows, what their “main construction sites” in the system are and which points must be addressed in a subsequent security concept.

We rely on Common Criteria for the evaluation of attack paths. We are currently also working on adapting our terminology and evaluation schemes to ISO/ SAE 21434.

This can be answered with a no. The risks do not yet provide a judgement as to whether a use case is dramatic or acceptable. In the end, this is the responsibility of the customer. However, we are there to advise them. In addition, in some cases it must be said that it is not worthwhile to eliminate these risks, because that would require the complete overthrow of hardware that has perhaps already been tested. Under certain conditions, this would then be out of all proportion to the possible damage that could occur. Sometimes a use case simply requires you to take certain risks or to do without this use case completely.

Both areas can interact particularly well when it comes to assessing damage. The results of the safety analysis already provide a good indication of the extent of the damage from a security perspective. Sometimes, however, communication between the specialist areas is still difficult, for example because terms are used twice. Additionally, probabilities are often used in safety, or aspects can be directly checked experimentally. However, this cannot always be transferred to security: Sometimes, the expectations of security cannot be met in the same way.

Regarding security, a considerable amount of effort is sometimes required to obtain information about the system models. For most cases, the same models have already been recorded in safety. It would certainly be possible to fall back on the same or similar data.

The same applies to the end of a safety analysis. Here the requirements derived from the analyses and concepts for security could be managed in a similar way to the requirements from safety.