Success Factors for Security Engineering

1 / 17

2015, Vector Consulting Services GmbH

Success Factors for Security Engineering Dr. Christof Ebert Vector Consulting Services GmbH, Stuttgart

Abstract

Security is of a growing concern across industries. It is today not anymore nice to have, be-

cause systems are interconnected, and in one way or the other open for external penetration.

Even worse security directly impacts functions and thus has become subject to product liabil-

ity. For instance, functional safety is not feasible without a concise approach to cover infor-

mation security. Based on the specific challenges of automotive security, OEMs and suppli-

ers have to realize an effective protection against manipulations of automotive E/E systems.

Key points in the development of protected E/E systems are the proper identification of secu-

rity requirements, the systematic realization of security functions, and a security validation to

demonstrate that security requirements have been met. Based on our experiences in several

client projects, we show which security engineering activities are required to create secure

systems and how these activities can be performed efficiently in the automotive domain.

This article is continuously updated and is in its latest version available through Vector Con-

sulting Services: mailto:[email protected]

2 / 17


Vector Consulting Services is a globally active consulting firm with focus on optimizing

technical product development. Renowned companies from automotive, information technol-

ogy, healthcare, transport and aerospace rely on the professional solutions for improving

product development, product strategy and in organizational change management and inter-

im management. A subsidiary of the Vector Group with 1300 employees, Vector Consulting

Services supports its clients worldwide with sustainable consulting solutions covering the

entire product life cycle and the related processes and tools. The firm is managed by part-

ners. This assures independent and customer-oriented consulting.

Details and further information: www.vector.com/consulting

Dr. Christof Ebert is managing director at Vector Consulting Services. He supports clients

around the world to improve product strategy and product development and to manage or-

ganizational changes. He sits on a number of advisory and industry bodies and teaches at

the University of Stuttgart.

3 / 17


Success Factors for Security Engineering

1. Introduction

Night drive on the highway. The communication display flickers and suddenly annoying whis-

tling sounds abruptly from of the speakers. The driver is surprised, looks to the display, tries

to calm down the whistling tone – and causes an accident. Reality or fiction? With increasing

complexity and networking, the use of standard components and open interfaces, the various

electronic systems, especially in the infotainment, increasingly vulnerable and must be pro-

tected.

Functional safety today needs information security. What exactly is information security (IS)?

Basically IS is a system property and relates closely to availability, functional safety, robust-

ness and performance. Quality in a system will generally mean that the system does every-

thing that is expected of him. IS goes beyond this classical definition in the sense that the

system itself in a malicious attack does nothing which is not expected.

Information security increasingly impacts today and future electronic systems. A growing

number of automotive comfort, reliability, and safety functions are realized by software appli-

cations that are executed by distributed electronic control units (ECUs). Besides the further

development of innovative sensors like radar and camera systems and highly complex info-

tainment and assistance systems, connected cars are pushing tomorrow‘s innovation. Inter-

net connections will not only provide the need for information to the passenger. Functions

like eCall or communication between cars or car to infrastructure (car2x) will evolve traffic.

This includes improved traffic flow controlled by intelligent traffic lights, OEM backend sys-

tems to provide latest mapping data, warnings from roadside stations or brake indication of

adjacent cars. Enhanced driver assistant systems and automated driving are gradually ap-

pearing on our streets.

More connectivity bears also the risk for attacks to the car. From painful experiences in

standard IT and communication domains it is known that distributed systems and communi-

cation are subject to unauthorized manipulations, such as eavesdropping, manipulation of

message contents, use of resources, etc. The data processing and communication activities

4 / 17


in automobiles are no exception – in fact, the properties of vehicles and their E/E architecture

can make unauthorized manipulations even easier than in many other systems.

ITS RoadsideStation

Car2x

OEMBackbone

NFC

Distributed onboard

communication across ECUs and

sensor fusion

ISO 15118 –Vehicle to grid communication

BlackBox (data collector) for

insurance, etc.

Off-BoardTester

Tire pressure monitoring via

near field communication.

Passengers internet(Google, E-Mail, ..)

Car Information (weather, traffic,

map, ..)

Figure 1: Modern car connectivity

Figure 1 shows car connectivity on-board in the distributed systems as well as from the car to

its environment. Each connection has a potential risk for an attack, regardless if it is wireless

or wired. Just the threat is different. The access through a connector shows limited risks,

because it is only possible for single cars, whereas a far field connection is much more dan-

gerous because it can be accessed from anywhere in the world. But also near field connec-

tions play an important role, such as tire pressure monitoring system, Bluetooth and wireless

LAN which is accessible from passing by or parked cars.

Anything that can be exploited by an attacker will be if the gain is significant enough. There-

fore, it is required to ensure that automotive systems can either not be exploited or the gain

of manipulations is reduced below profitability. Security and reliability will be essential for the

acceptance and success of modern automotive IT and electronic systems. In the standard IT

and telecom domains, a plethora of methods, techniques, best practices, and patterns have

been created in order to develop IT systems that are less vulnerable to unauthorized manipu-

5 / 17


lations. This discipline of security-aware development is referred to as security engineering –

it deals with processes, methods, and tools for designing, implementing, and testing secure

IT systems.

In this paper, we depict how security engineering can be successfully incorporated into au-

tomotive systems development. Section 2 therefore summarizes the challenges that are spe-

cific to automotive security. In section 3 we present solutions that proved valuable in several

automotive security engineering projects. Based on our experiences with these solutions we

have identified several activities that leverage the successful application of security engineer-

ing – these are outlined in section 4. This article is continuously updated and in its latest ver-

sion available through Vector Consulting Services1.

2. Challenges of Automotive Security

Security directly impacts safety, and thus is crucial to protect the driver and its environment.

Automotive OEMs and suppliers today are well aware that insufficient security engineering

has direct and immediate effects on product liability. Figure 2 shows how security attacks

impact safety by creating hazards, either by intended malfunctions like in our introductory

story, or by unintended malfunctions for instance due to DOS attacks. Security engineering is

not rocket science and thus with sufficient competence and willingness can be implemented

– and must be maintained throughout the lifecycle of any vehicle.

Automotive security has to deal both with coincidental events (e.g. defective ECUs becoming

babbling idiots) and, especially, with events that are intentionally caused by persons with

certain motivations, such as:

Activation of features that can be enabled by software settings, e.g. “chip tuning”.

Car and vehicle parts theft.

Component plagiarism.

Manipulation of remote key systems, immobilizer systems.

Manipulation of telematics systems, e.g. to obtain navigation systems’ maps.

1 Contact us on the entire Vector security portfolio: mailto:[email protected] or www.vector.com/security

6 / 17


Furthermore, new features such as car-to-X services might provoke further motiva-

tions for attacks.

Attack Hazard

People and environment attack the system thus creating malfunctions.

Security: Prevention of unintended behaviors

People and environment can be harmed by malfunctions.

Safety: Prevention of harm and injuries

Figure 2: Security Directly Impacts Safety

The exposure of automobiles and their E/E architecture provides several access points for

attackers to mount an attack. It is often possible to physically access the E/E buses that pro-

vide for data transfer inside of the vehicle. Many of the relevant bus technologies are inher-

ently insecure. Due to the growing connectivity of modern vehicles (e.g. car-to-X concepts,

Internet connection), external communication interfaces such as LTE, Bluetooth, WLAN, and

USB that allow for access to the E/E components might be used for manipulation. Additional-

ly, the exposure of vehicles enables attackers to physically access the ECU hardware, which

makes possible a wide range of manipulations, including passive (side-channel) attacks and

active (non-) invasive attacks to compromise existing protection mechanisms.

Additional to the vulnerabilities of the automotive system, there is also a severe disproportion

between the resources of an attacker and the resources of the vehicle, which places a strong

disadvantage on software-based automotive protection mechanisms [2,3]. To compromise

these mechanisms, an attacker has an arbitrary amount of time, whereas the time available

for the execution of the protection mechanisms is short (e.g. for the encryption of a mes-

sage). The same holds true for computational performance and memory capacity: an attack-

er can employ one or more high-performance computers while automotive ECUs possess

only comparatively low processing and memory resources.

7 / 17


Automotive security is a relatively new issue. Hence there are not many experts available

with expertise in both information security and automotive systems engineering. Moreover,

the adaptation of the basic security building blocks (such as cryptographic algorithms) to the

automotive environment and the composition of these building blocks to secure protocols are

difficult.

To make matters worse, automotive E/E systems are not only complex but typically also de-

veloped and produced across different organizations. The car manufacturer (OEM) provides

specifications of the system architecture and of the requirements on the different compo-

nents. Multiple suppliers develop and manufacture the components. However, security itself

is an emerging property of the entire system that cannot be overcome by one party alone.

3. Successful Solutions for Automotive Security Engineering

Automotive E/E systems comprise many different functions, ECUs, and communication sys-

tems, which can be attacked with different methods. The impact of an attack depends on the

concrete function that is attacked. To reduce the complexity that is created by the huge num-

ber of targets, attack methods, and impacts, we suggest taking three different perspectives

on automotive security, which each address a manageable, coherent set of questions. These

perspectives and the corresponding questions are [2]:

The product and its architecture: What can be compromised? What risks arise from

potential manipulations? What has to be protected?

Engineering for security: Which activities have to be performed to protect the vehicle?

Which technical solutions exist for automotive security? How can these solutions be

implemented according to the specific constraints? How can the security of the sys-

tem be demonstrated?

After sales: How are diagnosis, parts exchange, etc. affected by protection mecha-

nisms? How to cope with vulnerabilities that are detected not until SOP?

These perspectives (see Figure 3) along with techniques that we successfully employed in

client projects are depicted in the next sections.

8 / 17


Product /Architecture

Engineering After Sales

Figure 3: Perspectives on automotive security

3.1. The Product and its Architecture

The key to effective security is to know which assets have to be protected (and which do

not). From an automotive viewpoint one is interested in what vehicle functions can be com-

promised by attackers and in the implications that result from an attack. Therefore, the secu-

rity requirements have to be identified, before the development of security measures can

take place. Without a thorough security requirements elicitation, critical assets may be left

insufficiently protected or too much effort may be invested in protecting uncritical features.

Like any other requirements, security requirements have to be complete, consistent, com-

prehensive, and testable. Unlike most other requirements, they are concerned with what a

system should not do under any circumstances, including intentional manipulations. There-

fore, specific methods are required to identify security requirements.

In a recent client project, we had to identify and prioritize security requirements for an auto-

motive E/E component. Based on the size and complexity of the component development

project and the given capacity for security engineering, we selected an agile approach [1]

that was conducted in form of several workshops. The client’s engineers provided expertise

on the component’s functions and their implementation. We moderated the workshop and

provided expertise in security requirements analysis as well as knowledge on the used tech-

nologies’ vulnerabilities and sensible protection mechanisms.

The key activities of the selected approach consist of the formulation and evaluation of abus-

er stories and the creation of security-related user-stories. Abuser stories are brief, informal

descriptions of how an attacker might abuse the system. The abuser stories are written on

index cards in a language understandable by developers. An example for an abuser story is:

A chip-tuning firm flashes unauthorized software on the ECU. The index cards were then

pasted to a white board with their respective positions determined by the probability of the

9 / 17


abuser story and its impact, which gives a vivid impression of the risks of the abuser stories

(Figure 4) – we defined the risk as the factor of probability and impact of an event.

Impact

Probability

AbuserStory 2

AbuserStory 3

AbuserStory 5

AbuserStory 6

AbuserStory 4

AbuserStory 1

High riskMedium risk

Low risk

Figure 4: Abuser story risk evaluation

Based on the risks, the abuser stories that have to be prevented were selected and security-

related user stories were developed, which form the security requirements for implementing

countermeasures to the identified threats. An example for a security-related user story could

be: All ECU applications have to be authenticated before use.

The approach has proven valuable, because security requirements had to be identified in a

very short time frame. The approach is lightweight, its results are concise, and it is well suit-

ed for application during workshops with domain experts, i.e. automotive engineers. Howev-

er, it is less suited for complex systems because it lacks a systematic procedure – it strongly

relies on the people and their knowledge both on the system and on security. Other ap-

proaches overcome these limitations, however at the cost of increased effort. An overview on

security requirements analysis methods is given in [2].

It has to be noted for any approach that is used: To identify threats that emerge from tech-

nical features, an intimate knowledge of that technology as well as an attacker mindset are

required.

3.2. Engineering for Security

While security requirements are concerned with what has to be protected, security engineer-

ing defines how the protection is realized. It affects all activities that are associated with

10 / 17


“normal” engineering, such as system design, software construction, test and after sales. We

regard each of these activities in the following paragraphs.

Design

In an ideal world, the design of a vehicle’s architecture would consider security from the be-

ginning on. Unfortunately, in reality many architectural decisions are determined by other

factors, e.g. existing architectures of predecessor models, quasi-standard technologies, and

cost factors. Additionally, security requirements are often not identified on product level but

only on function level, e.g. in the case of security-affine functions, such as remote-key func-

tions, immobilizer functions, or tachometer functions.

As a result, many automotive E/E architectures are inherently insecure, what requires adding

security as an afterthought. When designing protection mechanisms for specific functions,

one is regularly faced with the following tasks:

Ensure the operation of the function according to its specification. This requires the

protection of the function’s implementation against unauthorized change.

Ensure the right operation of the function according to the current situation. This re-

quires the protection of all information used as input by the function.

For both tasks, there are technical solutions available, such as cryptographic algorithms that

provide integrity or authenticity on the basis of conventional and elliptic curve cryptography.

However, we have to emphasize again that, even if established algorithms can be consid-

ered secure, designing a protocol that defines the communication, authentication, etc. is

considered highly difficult and susceptible to failure, what might compromise its security.

While the protection of a function’s implementation against unauthorized change usually

does not influence other functions of the vehicle, the protection of the input information by a

cryptographic protocol does. Therefore, information transmitted via the vehicle’s E/E buses

need to be secured. Because an attacker might be able to access these buses and to ma-

nipulate the messages, an implementation of a security protocol needs to be integrated into

both the sending and the receiving ECUs (Figure 5). Vector is very much engaged to orches-

trate common security solutions starting with base software and even underlying hardware,

rather than ad-hoc implementations specific to OEMs and components. For instance, Vector

11 / 17


is supplying secure communication protocols within AUTOSAR for secure end-to-end com-

munication [4].

External communication

moduleHSMGateway

Body

Chassis

Powertrain

ADAS Infotain-ment

Low security zone

Medium security zone

High security zone

ECU 2

Security protocolimplementation

Functionimplementation

ECU 1

Security protocolimplementation

Functionimplementation

Protectedmessage

Com

pany

1

Com

pany

2Dependancy

Figure 5: Security protocols have to be integrated into sending and receiving ECUs

In a project with an OEM we supported the development of a basic security architecture that

defines a security protocol on system level for security-critical communications as well as

reference implementations. A single security architecture can be tried and tested more inten-

sively than a multitude of isolated functions and should therefore provide a higher degree of

maturity and security. In the meantime we have developed and introduced a dedicated secu-

rity protocol on top of the standard component requirements specifications [4].

Implementation

Not only the design of security-critical functionality is challenging, so is its implementation.

First, there is a disproportion of the resources available to an attacker (long time span, high

computing performance) and to the ECUs (short time span, low performance). Effective cryp-

tographic algorithms are often resource-intensive and therefore usually have to be imple-

mented specifically for the target ECU. Second, the code has to be robust against manipula-

12 / 17


tions, such as inputs that result in buffer overflows. Third, a sophisticated attacker may per-

form hardware attacks such as side channel attacks or invasive attacks.

Resource efficient implementation is not specific to security, so we will not discuss it here. As

we have seen in a recent client project, the introduction of a secure coding standard can re-

veal and subsequently reduce potential software vulnerabilities. Such secure coding stand-

ards, e.g. for the C programming language, ban insecure coding practices and undefined

behaviors that can lead to exploitable vulnerabilities. As a matter of principle, we suggest the

application of the MISRA-C guidelines and to use any measure one gets “for free”, like set-

ting the compiler to the highest warning level. The conventions have to be strictly checked

and enforced, preferably with automatic analysis tools, such as LDRA’s TBsecure.

For the protection against hardware attacks, one possible solution is to employ tamper-

resistant hardware. In spite of such measures, we recommend designing the system in a way

that the attack does not scale – i.e. compromised ECUs do not affect other elements. For

secure implementation, too, the bottom line is that a strong fundamental knowledge of the

language and the environment is required [4].

Verification and Validation

Security vulnerabilities can emerge both on conceptual level (e.g. insecure communications

protocol) and on implementation level (e.g. susceptibility to timing attacks). Therefore a strict

verification of the security concept is required, from the security requirements through the

design of security-critical functionality (including protection mechanisms) to the implementa-

tion. For the development of security-critical software, the same verification mechanisms can

be used that are recommended as good practices e.g. by Automotive SPICE, such as re-

views, inspections, and tests on different levels.

In a client project, we performed reviews on the security requirements and inspections of the

security architecture. The problems we identified in these early phases could be eliminated

with comparably low costs. In this project we also created a simulation based on the design

of the secure communications protocol using a widespread tool for ECU and network design

and analysis, which allowed for an early evaluation of the security properties in a complex

environment without the need for actual hardware (Figure 6).

13 / 17


SecurityProtocolDesign

Specification

Test Cases

Simulation / Test

Test Results

Figure 6: Simulation and test of the security protocol using Vector modelling and test tools

To validate system security (i.e. to check the actual system’s performance against the sys-

tem’s security requirements), two approaches have to be considered: First, the functional test

of the security mechanisms has to ensure their implementation conforms to requirements

and that all of the security requirements have been realized. This does not differ from “nor-

mal” validation tests. Additionally, we recommend penetration tests, which simulate attacks

on the system and may be independent of the security requirements. While the first approach

can be performed by regular testing staff, the second one requires specific security expertise:

the mindset of an attacker is required to design such tests and to interpret the test results.

3.3. After Sales

To enable efficient after sales activities in spite of constraining security mechanisms, several

aspects need to be addressed. How can software updates be performed in the field with both

security against unauthorized manipulations and justifiable logistical effort? Currently Vector

is heavily engaged into secure communication protocols within the AUTOSAR base software

to achieve a secure end-to-end communication on evolving protocol stacks. However, the

concrete realization of the related logistical infrastructure needs to be considered.

An important aspect of after sales activities is the way OEMs and suppliers react when a se-

curity issue is detected in a fielded vehicle. Such scenarios have to be foreseen before the

vehicle’s SOP and procedures that define actions and responsibilities have to be set up. Ac-

tions to be planned are risk assessment of the issue, elimination of critical software vulnera-

14 / 17


bilities, and update of the software in the field. To achieve an efficient issue handling, a

smooth cooperation between OEM and suppliers is required.

4. Levers for Security Engineering

Security engineering needs specifically tailored solutions. There is not one solution which fits

to all architectures, products and practical use cases. For instance we are using with many

clients a checklist which is adapted to the specific environment and security risks. The check-

list though generic in nature, and for instance adopting lots of information security common

criteria, needs to balance the risk exposure with cost for security. Some security measures

can result in exploding cost and thus must always be taken with a good business sense. Too

often we hear from clients that they had been forced to use IT common criteria or code

checkers which create massive overheads. Similarly to a MISRA standard which hardly any-

body uses without adapting to the specific environment, we need also to adjust security rules

towards risks, cost and competences.

Independent of the approach used, we noticed several activities that support the introduction

and the performance of security engineering in general (Table 1) [1,2,3,4]. We do not claim

that these are the only valid solutions. Depending on e.g. corporate culture, existing experi-

ences, and project size and complexity, other solutions may be preferred.

15 / 17


Table 1: Activities that leverage security engineering

Activity Benefits

Adapt the devel-

opment processes

to factor in security

engineering activi-

ties.

Security engineering activities are known, scheduled, and executed smoothly

within the “normal” development, not in an ad hoc way. Security is considered

from the beginning on through the complete project. Additionally, synergies can

be exploited (e.g. a configuration management process can prevent quick fixes

that have not been tested against security vulnerabilities).

Systematically elicit

security require-

ments.

Elements that have to be protected are known from the beginning on, allowing

for stringent realization of their security. Additionally, security requirements can

be used to deduce test cases for security validation.

Thoroughly review

or test any security

relevant artefact.

Reviews of security engineering artefacts such as security requirements and

security concept as well as simulations of security functionalities and code

analyses allow for the identification of vulnerabilities at the earliest possible

time.

Use analysis and

test tools.

Automated tools reduce effort and allow for efficient and comprehensive analy-

sis and (regression) testing. For instance the Vector PREEvision PLM and

modelling environment provides a strong collaborative engineering backbone

for ensuring application of above measures along the life-cycle.

Manage embedded

security competen-

cies.

Many activities of security engineering require a specific embedded security

expertise, e.g. identification of vulnerabilities, design of the security architec-

ture, secure implementation, performance of security tests, and review of secu-

rity-related work products. Without this expertise, effective security engineering

is near to impossible. Therefore, build up embedded security competence in

your organizational unit or obtain it from internal or external providers.

5. Summary

Security engineering is a challenging task for both OEMs and suppliers. While automotive

security may not yet be in the customers’ focus today, we should consider the lessons

learned in other industries, where security is now a matter of course. In this paper, we de-

picted several security engineering approaches that we applied within the automotive indus-

try.

We should take benefit from security experience in other critical domains

Apply cybersecurity principles and methods to harden distributed embedded systems

16 / 17


Adopt the IT standard “Common Criteria” for automotive IT infrastructure usage and

create protection profiles

At the same time it is critical in this market to align the approaches for safety and security

engineering to stay cost-effective

Apply threat modelling as part of hazard and risk analysis

Use security levels in relation to safety integrity levels, e.g., different security aspects,

e.g. authenticity, integrity, confidentiality; relevance of assets and access options, e.g.

attack intensity

Align underlying development methods and processes, e.g., architecture design and

evaluation, security design, coding rules, hardening, robustness and misuse testing,

life-cycle robustness; tool support for combined safety and security engineering and

consistency across the entire life-cycle

As a global market leader for many years, Vector supports all necessary automotive security

engineering domains, starting with standard software such as AUTOSAR, providing a rich

portfolio of modelling and test tools such as PREEvision, and also having the experiences to

support consulting on how to build an efficient security and safety engineering in organisa-

tions around the world. Figure 7 shows the Vector security portfolio and its levers to ramp up

security.

The Automotive world has to catch up in security engineering. Looking to our recent experi-

ences, organizations urgently need to build up some basic security expertise and obtain ad-

equate external support, specifically where security meets safety. Mature development pro-

cesses provide a good basis but need to be amended with security engineering activities.

17 / 17


Standard Software

Technical measures to protect hardware and software security

Examples: Robustness and Hardening in AUTOSAR, Security adjusted to safety integrity needs

Tools

Consistent approach for all development activities.

Examples: Threat and Hazard analysis during concept definition, consistent modeling in PREEvision

Consulting

Support for methodsand skills as well as the necessary cultural changes.

Examples: Security engineering, culture change, hazard analysis

Figure 7: Benefit from Vector Portfolio on Automotive Safety and Security

References

[1] Ebert, C.: Global Software and IT: A Guide to Distributed Development, Projects, and

Outsourcing. ISBN: 978-0470636190-368. Wiley, Hoboken, NJ, USA, 2012..

[2] S. Burton, C. Ebert, et al: Automotive Information Security. VDI, Baden-Baden, 2007.

[3] Ebert, C: Functional Safety with ISO 26262 – Principles and Practice

https://vector.com/portal/medien/vector_consulting/webinar_podcast/Vector_FunctionalSafety_BestPractic

es_Webinar_EN.mp4

[4] A.Happel and C. Ebert: Security in Vehicle Networks of Connected Cars.

https://www.vector.com/portal/medien/vector_consulting/publications/Happel_Ebert_Security_Connectivity

_2015.pdf

Success Factors for Security Engineering

Documents

Transcript of Success Factors for Security Engineering