Especially in the automotive sector, there is currently a great upheaval in the field of security risk assessment. Vehicles are becoming more and more complex and are increasingly connected with each other. Technologies such as autonomous driving require a detailed consideration of possible risks. The advent of new norms and standards, such as ISO/ SAE 21434, also places special demands on the assessment of risks.

For this reason, we took a practical look around and asked an expert from the IT security sector about risk assessment. Ms. Lena Steden is a Team Leader in the field of IT Security at ESCRYPT GmbH in Bochum, Germany, as well as Topic Leader for Security Risk Analysis.

Ms. Steden, you are an expert in IT security and security risk analysis at ESCRYPT GmbH.

What questions do you face in your everyday work?

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?”.

What do you see as the greatest challenges in this area?

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.

Is security now an integral part of development projects?

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.

In your experience, do customers realistically assess the security risks to which they are exposed?

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.

ESCRYPT has specialised primarily in the field of automotive security.

Why is the implementation of a risk analysis particularly important here?

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.

Is it possible to identify trends in the field of automotive security that have a lasting effect on the way previous risk analyses have been conducted?

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.

What specific challenges are car manufacturers and suppliers facing now?

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.

What should I do now, as an OEM or supplier, to anchor the protection of vehicles in my organisation in the long term?

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.

What is the basic procedure for risk analysis at ESCRYPT?

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.

What procedures/methods do you use at ESCRYPT when conducting a risk analysis?

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.

Can and must all identified risks be eliminated?

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.

Currently, there is a tendency for safety and security, especially in the automotive sector, to move ever closer together and can no longer be considered completely independent of each other.

Where are there still difficulties at present?

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.

In your opinion, how could a synergy between these two areas of expertise be achieved?

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.

Franziska conducted this interview in June 2020.

About ESCRYPT

ESCRYPT GmbH is a provider of IT security solutions in embedded systems, as well as consulting and services for enterprise security and IT secured manufacturing.

About Lena Steden

Lena Steden graduated with a M.Sc. in IT Security at Ruhr University Bochum.

Since 2014, Ms. Steden is working as a Security Consultant at ESCRYPT GmbH and is currently Team Leader of a Consulting Team in Bochum and Topic Leader for Security Risk Analysis.

Her field of activity includes the implementation of risk analyses for customers, especially from the automotive industry, as well as the continuous development of the company’s own risk analysis methodology and the tools and templates used worldwide.

 

What now?

Want to discuss further? Feel free to contact the YSEC Team. Otherwise, read more on How we aim at enabling a whole-car analysis using openXSAM.