Success Factors for Security Engineering
Transcript of 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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
“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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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
2015, Vector Consulting Services GmbH
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