Why is Security by Design at risk of failing in automotive development?

To be honest, security by design is currently more of an ideal idea than an established working principle in most product development processes across all industries. Especially in the intertwined supply chains of the automotive industry, even the most ambitious OEM quickly realizes: Security-by-Design fails due to the complexity of vehicle development. In this article, we will explore why this is the case and what can still be done.

For this, let’s start with a basic definition of Security by Design.

What is Security by Design?

The idea of “Security by Design” is actually quite simple to explain. Basically, it is an approach that ensures that security requirements are defined and taken into account from the very beginning in all phases of product development.

In concrete terms, this means that already at the design stage, i.e. in the earliest phases of development, the highest attention is paid to fully considering the security requirements in the development process from the very beginning and to taking appropriate measures to reduce vulnerabilities as early as possible.

What at first sounds absolutely desirable often fails in the automotive supply chain due to very different business logics, which we would like to highlight in the following.

What sounds trivial is a real problem: Lack of awareness as a significant obstacle

What the customer doesn’t explicitly ask for or clearly has defined as a requirement won’t get done for the time being. This or similar arguments are used by many companies, teams, and individuals around the world to drive their business in a resource-efficient way and even with specific cybersecurity responsibilities, the situation remains unchanged. In our experience with development teams and project-level decision makers, you can’t blame them for these business practices.

However, such a situation is often intensified by insufficient cybersecurity-specific awareness and inadequate professional qualification.

At the same time, operational responsibility for the areas of action in vehicle cybersecurity is located far too low in the organization, especially in the downstream supplier structure. (see also next point)

Frequently, decision-makers are confronted with completely unrealistic information that is supposed to serve them as a basis for making a meaningful decision.

Especially at the organizational level, there is a risk of having an inadequate or non-existent conceptual objective for cybersecurity efforts. This grievance, which starts at the top, cascades downward.

Lack of structure to even enable security by design in the first place

The consequence: The existing structure in the organization, in the project or in the actual working environment simply does not allow the consideration and consistent application of security-by-design.

The following shortcoming is common and, above all, quite easy to identify: The existing process landscape (and especially with regard to the processes actually applied in practice) takes security-by-design into account completely inadequately.

Logically, smaller organizations with limited resources have a particularly hard time with this, but it is also often the large organizations where a notably high discrepancy between the defined process landscape and the working reality can be observed. You can write a lot of things down, but you can’t necessarily expect a concrete impact as a result.

Deficits are usually found as follows:

• Inadequate governance: principles, guidelines, mission statements and, in particular, their assured application are often absolutely neglected in the area of cybersecurity implementation.
• Responsibilities and the associated authority are inadequately placed in the organizational structure.
• Global lack of objectives related to the organization-wide application of cybersecurity – If they do exist, there is a lack of concrete systematics for sustainable enforcement and control.
• Accordingly, budgets and resources are inadequately allocated and/or the necessary support and commitment on the part of decision-makers are insufficient.

Parallel to these organizational difficulties there are the concrete framework conditions in a project: Does the development plan even offer sufficient feasibility to realize security-by-design? What do the conditions look like in practice?

In the efficiency-driven automotive world, delivery-oriented directions with a focus on output are a particular reason for insufficient resources in the implementation of cybersecurity.

Ultimately, there is simply a lack of time to set up and apply an integrated security-by-design approach.

The concrete business case does not take security sufficiently into account

Another major obstacle is a classic problem: Sales is selling, development is developing, and all of a sudden cybersecurity has missed its entry.

Fortunately, it’s often not quite that bad, but it’s still often the case that cybersecurity (and the scale of the impact behind it) is not sufficiently considered when it comes to driving new opportunities and concrete elaborations in the core business.

Questions that should be asked much more frequently here:

• What needs to be done in terms of cybersecurity?
• How much of it really needs to be done effectively?
• What specifically needs to be accomplished at all?
• What are the concrete consequences of this?

Often, this leaves unclear definitions and vague instructions, resulting in insufficient resources for cybersecurity in specific development projects.

To make matters worse, the cost-benefit factor of cybersecurity is all too often misjudged, opening the door to the familiar “business need vs. cybersecurity need” scenario.

Cybersecurity always has a political dimension in organizations as well

From the perspective of the end user of a vehicle in particular, one demand is absolutely legitimate: the necessary measures to mitigate cybersecurity risks must be implemented down to the last detail.

To be fair, it must be said: As a rule, companies also pursue this claim. In general, people know what the right thing to do would be.

Nevertheless, there are often very specific conflicts of interest at the organizational level that can lead to a blockade in implementation.

For example, there are people formally responsible for the realization of cybersecurity issues who would be responsible in themselves, but who do not get the concrete implementation started.

Let’s face it, the automotive industry is extremely hierarchical.

Starting with minor issues and ending with very large structural decision-making processes, power games, intrigues and self-interests can be observed time and again in both small and large organizations, which can massively hamper the implementation of cybersecurity at the organizational and project level.

Not funny, because it’s true: products are already in development, or in use in the field

Information events, webinars, panel discussions – regularly, one question comes up again and again: How are all the growing cybersecurity requirements actually being implemented in the millions of vehicles already in development or on the road?

Yes, the question is justified.

With transitional periods, for instance by UN Regulation No. 155, it is to be ensured that at a later point in time the measures that require mandatory cybersecurity will take effect in their entirety. At the moment, we are still a long way from that.

And yes, logically, the principles of security-by-design can no longer apply as soon as products have reached the correspondingly advanced phases in the lifecycle.

This is precisely why, after the penny has dropped, immense resources are currently being spent to counteract this, at least for the future, and to be able to work more in the direction of security-by-design.

In this context, the long lifespans in the vehicle industry should not be underestimated: It is almost certain that new threats and changed risk situations will arise at any time during a product life cycle of around twenty years, making continuous further development of cybersecurity indispensable far beyond the development process.

Also difficult for Security by Design: Region-specific differences

Let’s take UN Regulation No 155, which is supported by the 64 member states of UNECE WP.29. If vehicles are sold in these markets, compliance with UN R155 is mandatory.

However, if we take the sales markets of the USA and China, UN R155 does not officially apply here.

If you start researching what exactly the Chinese market or the United States require as a counterpart here, things get complicated right away.

This shows that regionally different requirements make a stringent security-by-design approach extremely difficult.

Suppliers who are beginning to gain a foothold in the complex automotive industry with their (new) developments find a similar situation. Global suppliers sometimes have to fulfill completely different requirements with their products. It is not uncommon for there to be a complete lack of awareness of this heterogeneous requirements structure in the early development phases.

These situations make it difficult to claim to be able to consistently implement security-by-design, even if the ambition and organizational skills were there.

Conclusion

In summary, it can be said that the points listed are each deliberately intended to highlight extremes. At the same time, however, the industry is still a long way from holistic and consistently standardized security-by-design approaches. Specific methods are not required here even by UN Regulation No. 155 and ISO/SAE 21434:2021.

Accordingly, it is still necessary to find organization-specific answers in order to set the right course at an early stage at the level of the organization, in the project and in engineering

Sign up for our CYRES Consulting Automotive Cybersecurity Newsletter

Stay informed! Receive regular insights into current topics related to cybersecurity in the automotive industry directly to your inbox.

Sign up here for the newsletter, free of charge and with no obligations.

I accept saving my data by CYRES Consulting to contact me. More information in our Privacy Policy.

Leave this field empty if you're human: