Automotive Functional Safety = Safety + Security
Simon Burton Jürgen Likkei1
ETAS GmbH Priyamvadha Vembar2
Atlas House Robert Bosch GmbH,
Osbaldwick Link Road Postbox 30 02 40,
York, YO10 3JB 70442 Stuttgart
United Kingdom Germany
+44 1904 56 2642 +49 711 811 49831
simon.burton@etas.com +49 711 811 34530
juergen.likkei@de.bosch.com
priyamvadha.vembar@de.bosch.com
ABSTRACT
Standard approaches to functional safety as described in the
automotive functional safety standard ISO 26262 are focused on
reducing the risk of hazards due to random hardware faults or
systematic failures during design (e.g. software bugs). However,
as vehicle systems become increasingly complex and ever more
connected to the internet of things, a third source of hazard must
be considered, that of intentional manipulation of the
electrical/electronic control systems either via direct physical
contact or via the systems’ open interfaces. This article describes
how the process prescribed by the ISO 26262 can be extended
with methods from the domain of embedded security to protect
the systems against this third source of hazard.
General Terms
Management, Design, Reliability, Security, Standardization.
Keywords
Automotive Functional Safety, ISO 26262, Embedded Security,
Common Criteria
1. INTRODUCTION
During the last 25 years, the automotive industry has seen an
exponential rise in the number of safety-relevant
electrical/electronic (E/E) enabled vehicle functions [1]. These
functions are not only increasing in number, but also in
complexity, authority over the control of the vehicle and the level
of interaction between them. Consider for example, a lane assist
function, variants of which are already available in a number of
vehicles currently in series production. This function uses visual
inputs correlated with a number of other vehicle parameters to
determine whether an unwanted change of lane is being
performed. The system then warns the driver and corrects the
direction of the vehicle, e.g. through applying force on the
steering column. To perform this function safely, the system
depends heavily on the reliability of inputs from a diverse set of
sources, the timely and correct activation of actuators to perform
the corrective and warning actions and the coordinated interaction
with other systems. The safety implications associated with this
type of function are obvious, with the risk of hazards such as
unwanted steering, suppression of evasive maneuvers and over-
steering associated with failures in the components or the design.
The introduction of the ISO 26262 [2] international standard for
functional safety in passenger vehicles has greatly increased the
awareness within the industry for the issues involved in functional
safety and has driven significant improvements in the
development practices accordingly. While the process prescribed
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SecurIT’12, August 17-19, 2012, Kollam, Kerala, India
Copyright 2012 ACM 978-1-4503-1822-8/12/08... $15.00
Marko Wolf
ESCRYPT GmbH
Leopoldstraße 244,
80807 München,
Germany
+49 89 208039131
1 marko.wolf@escyrpt.com
2
by the standard helps to develop systems that are protected against
hazards arising from random hardware failures or systematic
failures in the design (e.g. software bugs), the potential for the
safety of the system to be compromised by deliberate
manipulation is currently considered outside the scope of the
standard. In other words, additional measures are required to
prevent hazards occurring either deliberately as a malicious attack
or unintentionally as a side effect of manipulations performed
with other motivations in mind (e.g. “chip tuning” to improve
engine performance).
Figure 1: Lane departure system architecture with potential
points of attack
That this threat is real, and that it can cause considerable damage,
is evidenced by a number of successful attacks – although at this
point most of them were instigated by research teams. In 2010, for
example, a production vehicle in the U.S. was subject to
successful manipulations of the vehicle electronics that included
individually braking the wheels and even disabling the brakes
altogether. [3]. As the vehicle functions become ever more
complex and the market pressure to integrate the vehicle into a
modern “internet of things” increases, so do the potential attack
vectors. These include direct physical access to vehicle networks,
for example via the On Board Diagnostics connector under the
dash or a CAN (Controller Area Network) network routed through
the external mirrors. It is also increasingly possible to gain access
to the vehicle systems without physical access, whether using
software installed onto smart-phones, Bluetooth-enabled hands-
free telephone functions, wireless tire pressure sensors, direct
internet access through the infotainment systems and in future
vehicle-to-vehicle and vehicle-to-infrastructure systems. Figure 1
describes a typical vehicle network architecture with the set of
ECUs (Electronic Control Units) involved in coordinating a lane
150
departure function and potential points of security attacks (not all
electronic control units are shown for brevity, a typical modern
vehicle will have between 60 and 100.)
The security evaluation methodology ISO 14508 (Common
Criteria) [4] defines a set of criteria for evaluating and certifying
security-critical applications. These criteria consist of a catalogue
of pre-defined security functional requirements that the evaluation
target claims to fulfill as well as pre-defined levels of assurance
that give insight on how deep the evaluation of this claim has
been done. The evaluation is carried out by an evaluation
laboratory and supervised by a governmental institution. As such,
evaluations up to a certain evaluation assurance level (EAL) are
internationally accepted [5]. The criteria are accompanied by the
Common Methodology for Information Technology Security
Evaluation [6] describing the methodology behind a CC security
evaluation.
The authors believe that the ISO 26262 framework can be
extended, inspired by guidelines such as Common Criteria, to
provide a solid basis for protecting against functional safety
hazards that are not only caused by random hardware failures or
systematic failures in the design, but also as a result of direct
attacks on the system. The paper will describe an integrated,
holistic approach to integrating security techniques into the safety
process.
To clarify our aims, we distinguish between several primary
motivations for engineering secure systems. On the one hand the
customer requires the security features for a product (motivated
for example by privacy, anti-counterfeiting, theft-protection
market/regulatory requirements, etc.). The Common Criteria
represent a framework for determining whether and how far a
product’s security goals have been met by design and
implementation. In a broadly accepted taxonomy given in [7],
security and dependability are considered as properties of a
computing system, with safety classified as an attribute of
dependability. On the other hand, the security features could be
motivated primarily by safety needs. The ISO 26262 definition of
functional safety as “absence of unreasonable risk due to hazards
caused by malfunctioning behaviour of E/E systems” [2] could be
extended to define hazards also as “potential sources of harm
deliberately caused through intentional manipulation of system
behaviour with respect to its design intent”. Security would then
be considered as a measure for achieving these extended goals. In
this paper, we will be focusing on this second objective as a
means of integrating security approaches into the (automotive)
safety process. The resulting approach is a rigorous safety analysis
including consideration of security threats in the safety concept.
The proposed security analysis, of course, could be extended to
protect against non-safety relevant security threats such as loss of
privacy, circumvention of legally mandated restrictions, etc. to
derive a general security concept for the system with a wider
scope than just safety relevant threats.
The paper is structured as follows: Section 2 begins with an
overview of the process and methodology described by the ISO
26262 safety standard. The following section summarises the
adaptations to the process that are required to additionally prevent
hazards occurring from direct manipulation (the embedded
security cases) and discusses several of the extensions to the
process in more detail, focusing on the analysis methods, giving
examples of how techniques from the security domain can be
integrated into the safety process. Section 4 then goes on to
discuss another significant area of the safety process where an
integrated approach to security is required, that of the safety case.
The paper concludes with a summary of the main findings and
recommendations of the paper.
2. OVERVIEW OF THE ISO 26262
METHODOLGY
The approach to functional safety as described in ISO 26262 can
be broadly summarised as a risk-oriented one. During the concept
phase of the development of the item, hazard analysis techniques
are used to assess the safety risk associated with failures of the
system. Based on these hazard scenarios, safety goals with an
associated target ASIL (Automotive Safety Integrity Level) are
derived and used to drive the development of a system safety
concept that includes measures for mitigating against the risk of
failures causing hazards (e.g. use of redundancy or monitoring
mechanisms). The ASIL level can range from “QM” meaning no
additional measures above and beyond standard quality
management techniques are required through to “ASIL A”, the
lowest safety-relevant level and “ASIL D”, the highest. This
system safety concept is in turn used to iteratively derive more
detailed system, hardware and software technical requirements
supported by the application of analysis techniques such as
FMEA (Failure Mode and Effects Analysis) and FTA (Fault Tree
Analysis). These analysis techniques are used to analyse the
effects of faults in the system (either inductively or deductively
respectively) and are used to identify additional safety measures
and confirm the robustness of the design. The development
lifecycle as described by ISO 26262 can be summarised as shown
in Figure 2.
Figure 2: An overview of the functional safety development
process
The measures described in ISO 26262 are targeted towards
reducing the risk of hazards caused by random hardware faults
and systematic failures. The scope and strength of these measures
is dependent on the ASIL derived from the hazard assessment and
risk analysis. These measures can be categorized into product and
process measures. Examples of process measures for protecting
against random hardware failures are the use of qualified
151
Table 1: Excerpt of an example hazard analysis and risk assessment according to ISO 26262: 3-7
Hazard Situation Severity (S) Exposure (E) Controllability ASIL Safety Goal
(C)
Hazard 1: Inadvertent Motorway S3: Loss of E4: Very C3: Difficult to D Safety Goal 1: The counter
activation of counter Speed>120 control of typical driving control or steering shall only activate if
steering km/h vehicle could scenario (e.g. uncontrollable a significant risk of straying
Heavy traffic lead to fatal daily commute) from lane has been
injuries confirmed and traffic
conditions imply this was
unintentional.
Safety Goal 2: On detecting
an incorrect behaviour, the
lane assist function shall be
immediately deactivated.
Hazard 2: Motorway S3: Loss of E4: Very C3: Difficult to D Safety Goal 3: The amount
Overreaction of the Speed>120 control of typical driving control or of counter steering that can
lane assist function km/h vehicle could scenario (e.g. uncontrollable be applied shall be limited to
(too much counter Heavy traffic lead to fatal daily commute) a maximum of 5 degrees
steering) injuries from the current position.
… … … … … … …

hardware components with a known failure rate, application of
redundancy in the design, diagnostics (e.g. short cut detection)
and self-test. Examples of product measures for protecting against
system failures are the use of modular designs, programming
guidelines and defensive programming techniques. Additional
process measures further reduce the risk of systematic failures
being introduced into the product as well as ensuring that all due
diligence is taken when applying the safety measures. ISO 26262
also defines the concept of a safety case for the system as an
argument built upon evidence created by the development process
that all safety goals of the system have been sufficiently met.
derive additional security goals focused on preventing and
detecting such attacks. These security goals are then used to
derive a combined system safety and security concept. This in turn
leads to a number of technical security measures that are mapped
at the system, hardware and software level. More detailed safety
analyses performed at the technical system, hardware and software
level are then equally extended with a security perspective to
derive further detailed technical security requirements and
validate the system design. These extensions are summarised in
Figure 3.
The following sections illustrate these extensions with some
examples based on the lane departure system introduced in
Section 1.

3.1 Combined safety and security goals

Figure 3: Safety process extended with security activities
3. A COMBINED SAFETY AND SECURITY
ANALYSIS
The integrated approach to safety and security described here
closely follows the risk-oriented process already defined by the
ISO 26262 as described above. The possibility of hazards
occurring as a result of direct attacks or manipulation of the
system is considered during the hazard analysis phase and used to
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
Conference’10, Month 1–2, 2010, City, State, Country.
Copyright 2010 ACM 1-58113-000-0/00/0010…$10.00.
ISO 26262 requires a hazard analysis and risk assessment to be
performed during the system concept phase. The purpose of this
analysis is to “identify and categorise the hazards that
malfunctions in the item can trigger and to formulate safety goals
related to the prevention or mitigation of the hazardous events, in
order to avoid unreasonable risk” [2]. The analysis method has
its focus on the intended function of the system rather than its
technical implementation and it is typically performed by
combining hazardous events with a situation analysis of when
these hazardous events can occur. Depending on the risk
associated with the combination of hazard severity (S), probability
of exposure to the situation (E) and likelihood of the situation
being controlled in a manner to avoid the hazard (C), an
Automotive Safety Integrity Level (ASIL) is assigned. Safety
goals are then derived to prevent or reduce the risks associated
with the hazard. This analysis is often performed in a series of
moderated workshops with attendance from a broad range of
system and safety experts. The results are typically recorded in
tabular form. An example excerpt of a hazard analysis and risk
assessment for a lane assist function is shown in Table 1.
The hazard analysis and risk assessment method does not lead
directly to the identification of specific security goals for the

152
Table 2: Example attack scenarios and associated risk excerpt from the misuse case analysis used to derive the safety-
assessments relevant security goals of the system.
Attack Impact ASIL Security Goal There are a number of mutual effects between the two types of
Scenario/Misuse cases on analysis techniques described above that are of benefit to the
safety overall integrity of the system. Both methods rely on an
goal(s) understanding of the function from a total systems point of view,
including all interfaces to external systems as well as assumptions
Maliciously control Safety D Security Goal 1:
about the behaviour of all actors in the system, e.g. reaction of the
steering through Goal 1 The Lane
driver in critical situations, ease of access to the system by non-
manipulation of the Departure
expert attackers, etc. By explicitly documenting these assumptions
Lane Assist Function System shall
during the analysis, targeted tests can be performed to validate
prevent
that the assumptions hold in the target environment and can
maliciously
therefore be used as a valuable input into the test and quality
hidden function
planning phase. In addition, applying these two differing
activation.
approaches to system analysis at this phase increases the chances
Inadvertently cause Safety D Security Goal 2:
of critical risks being identified as the security threat analysis may
oversteer through Goal 3 Prevent
lead to hazards being identified that were not yet discovered
manipulation of system tampering with
during the hazard and risk analysis. However, the analyses may
(e.g. installation of or installation of
also lead to conflicting requirements. Examples of potential
counterfeit parts) counterfeit parts
conflicts are the trade-off between performance overheads for
associated with
process security functions vs. hard real-time safety requirements
the lane assist
to respond to hazards within a fixed period of time or the conflict
function.
between “fail safe” and “fail secure” states.
… … … …
From this point onwards in the process the set of combined safety
system. However, when designing the system concept it is and security goals can be treated in the same way in terms of the
important to take both the safety and the security goals into level of rigour in documenting and tracing the goals as they are
account. Therefore, we recommend extending the hazard analysis iteratively refined and validated throughout the process. The
and risk assessment phase with a security threat analysis. From a associated ASILs of the goals determine which additional process
functional safety perspective the security analysis must only be measures as defined by the ISO 26262 should be applied when
performed if the hazard analysis has identified safety goals and the implementing and testing the gaols and their derived
system has the potential for security threats that may violate these requirements.
goals, i.e. it is not a closed system (has communication interfaces, Obviously there may be other motivating factors (economic,
update possibilities etc.). reputation, privacy, etc.) apart from safety why a security threat
The purpose of the security threat analysis is to identify the analysis may be prudent at this phase. Automotive misuse cases
security goals used to derive the security requirements on system heavily depend on the actual application analysed and the
design, implementation, and evaluation. A typical approach to corresponding attacker model (e.g., vehicle owner vs. competing
performing security threat analysis is to first determine the manufacturer). Next to potential encroachments on safety-relevant
attacker model in terms of primary motivation, skill level, possible functionality, automotive security misuse cases can be, for
access to the system, and equipment available. The next step is to instance, circumvention or manipulation of warranty or legal-
determine the attacker’s goals based on the target of the attack, the driven protection functionality such as installing counterfeits, chip
motivation and goal attractiveness. Typical attacker models in the tuning, or mileage adaptations. Other misuse cases are related to
automotive domain can be for example, criminals with the intent unauthorized access to protected information such as IP theft by
to bypass theft prevention systems or with the aim of blackmailing competitors, theft of infotainment data by the vehicle owner or
a premium OEM with the leverage of loss of reputation, potential privacy intrusions by a third party (e.g., stealing address books).
liability suits, etc., or highly skilled experts from the academic Attack scenarios could also be derived from existing security
community with the goal of achieving prestige and reputation for policies, legal requirements, related business cases, or historical
novel security research. The application of Misuse Cases [8] is a security issues. These motivations however are out of scope of
common technique for identifying and analysing such attack this paper.
scenarios based on an actor-based model of the system. A Misuse
Case for the lane assist function “Activate Lane Assist Function” 3.2 Functional Safety (and Security) Concept
may be for example, “Maliciously control steering through The next step in the ISO 26262 methodology is to iteratively and
manipulation of the Lane Assist Function”. After the misuse cases in a traceable manner refine the safety goals into a detailed system
have been identified, they are analysed to determine whether they design and a set of technical requirements on the individual
pose a potential safety risk. This is performed by determining the system components. The purpose of the functional safety concept
safety goals that may be violated as a result of the attack. A result is to derive the functional safety requirements on the item from
of this analysis may also be that additional hazards and associated the safety goals and allocate these requirements to architectural
safety goals are identified that were not yet considered in the elements in the system. It is at this level that the safety measures
hazard analysis and risk assessment. For those misuse cases and integrity requirements of the system are defined and mapped
identified with a safety risk, a security goal is defined and to components. These measures could include, for example,
assigned the ASIL of the associated safety goal. Table 2 shows an redundancy and diagnostics. It is in this phase of design also, that
the safe states of the system are defined. That is, the state which

153
Table 3: Excerpt from the functional safety concept
Safety Goal ASIL Safe state
Safety Goal 1: The counter D Lane departure
steering shall only activate if system is inactive.
a significant risk of straying
from lane has been confirmed
and traffic conditions imply
this was unintentional.
… … … …
The system shall maintain to prevent hazards from occurring or
the state that should be transitioned to if a potentially dangerous
failure is detected. Table 3 shows an excerpt from the functional
safety concept for the lane assist function based on a derivation of
the functional safety requirements and safe states based on the
safety goals. Model-based approaches to modelling and analysing
safety and security concepts based on models of the functional
system architecture and technical system architecture [11]
demonstrate much potential for supporting automated analysis and
validation of the safety and security concepts.
The authors suggest deriving a combined safety and security
concept to ensure a consistent implementation of the safety and
security goals, resolving potential conflicts in the design. The
extensions to the safety process described here involve analysing
the security goals in more detail to identify the potential attack
paths through the system. These are then in turn analysed
according to their attack potential (the amount of effort required
to successfully mount the attack). The attack potential is then used
as the measure of the level of additional security measures
required to protect the system against these potentially hazardous
attacks. While refining the safety and security goals into technical
requirements at the system design level, additional hazards and
threats can also often be identified and fed back into the hazard
and security threat analysis phase.
To derive the system security concept from the security goals, the
system structure is first analysed to define the trust boundaries,
identify the system security assets and system entry points so that
the threats on the system security assets can be identified and the
attack scenarios/misuse cases mapped accordingly. Figure 4
shows a system structure analysis for the lane assist function for
the misuse case “Maliciously activate the Lane Assist Function
under hazardous conditions”. As shown in the diagram, for this
example, the assumption has been made that the sub-networks for
chassis control and driver assistance, powertrain and body
functions are trusted, that is, no threats are anticipated from within
these boundaries. These assumptions can be made, for instance,
by excluding certain attacker models (e.g., internal attacker) or by
referring to other independent protection measures (e.g., physical
protection).
Functional Safety Requirement Allocated to
component
FSR 1: The lane assist function shall Driver assistance ECU
only activate after travelling at > 100
km/h for 3 minutes without a change of
lane.
FSR 2: The lane departure recognition Driver assistance ECU
shall be implemented using two
distinct, separately developed
algorithms. The function is only
activated if both algorithms agree.
FSR 3: Counter steering shall only be Steering Column ECU
applied while no other steering force is
being applied by the driver. If steering
force is applied by the driver after
counter-steering has been activated,
then the counter-steering shall be
cancelled with 0,1 seconds
…
The security system assets of the Lane Assist function are as
follows:
 Firmware: Executable functional code and configuration
(calibration) parameters
 Communication messages to and from neighbouring
functions and between sub- functions
 Hardware resources for executing of the function
 Network resource (delay, bandwith) for communication
between the components involved in the function.
Figure 4: Analysis of system structure of the Lane Assist
Function.
Attack Trees [9] are a useful method for finding the particular
paths of attack for certain security assets and thereby derive the
attack potential and functional requirements on the security
concept required for protecting against these attacks. Figure 5
shows an (incomplete) attack tree for compromising the Security
Goal “Prevent activation of the steering function through
malicious manipulation.”. The attack tree analyses the system in
terms of its security assets, trust boundaries and access points to
identify possible chains of events that can lead to security
breaches. This analysis is then used to identify the attack potential
for each attack path, i.e. the effort required to successfully
complete the attacks.
154
 Figure 5: Attack tree for Security Goal 1 of the Lane Assist function

Table 4: Analysis of the attack potential for Security Goal 1 based on the common criteria evaluation
Security Goal Safe state ASIL Attack Path Common Criteria Evaluation Attack
(CEM, B.4.2.3) Potential
Security Goal 1: Prevent Lane Assist D Remote manipulation, Elapsed time: Weeks (3) 12
activation of the steering system is  Manipulated Specialist expertise: Expert (6)
function through malicious inactive. communication, Knowledge of target: Restricted
manipulation.  Additional messages, Information (3)
 Manipulation of SW Access: Unlimited, App download (0)
functions of other Equipment: Standard (0)
devices…
Physical manipulation, Elapsed time: Days (1) 22
Software update through Specialist expertise: Expert (6)
debug pin before Knowledge of target: Sensitive
execution such that Information (7)
functional behaviour Access: Moderate (4)
violates safety goal Equipment: Specialized (4)
… … …

The risk associated with the security goal is calculated as a
function of attack potential and damage potential. The Common
Criteria can be used to determine the attack potential, i.e. the
difficulty of the attack path as described. Wolf and Scheibel [10]
describe a method for quantifiable the security risk associated
with such systems as a means for identifying a suitable amount of
risk reduction measures. In the case that attack scenarios can be
related to the violation of safety goals, the damage potential of
these are directly derived from the ASIL of the associated safety
goal. The combination of attack potential and ASIL defines the
amount by which the risk shall be reduced to an acceptable level.
This can be achieved by reducing the attack potential of critical
attack scenarios by defining measures that hinder the attacker,
prevent the threats altogether or by reducing the severity of the
attack by redesigning the function to result in a lower ASIL. Table
4 demonstrates the application of this technique and how it can be
used to derive a set of attack potentials for a given security goal.
The common criteria are used to assess the attack potential of the
attack scenario and with the attack potential being calculated as
the sum of the individual criteria factors [10]. Additional security

155
Table 5: Excerpt from the functional security concept containing security requirements derived from the attack tree analysis
Security Goal Safe state ASIL
Security Goal 1: Prevent Lane departure D FSecR 1: It shall not be possible for
activation of the steering system is
function through malicious inactive.
manipulation.
… … … …
measures are then added to the system design to increase the
attack potential to a level appropriate with the to the damage
potential (ASIL). For an ASIL D function as in the example, a
typical target level of attack potential will correspond to a highly
skilled attacker, requiring months of effort with specialised
equipment and “insider” knowledge of the system.
Table 5 shows an excerpt from the functional security concept
detailing how the functional security requirements derived from
the attack tree analysis are traceably refined from the security
goals and allocated to system components. As part of the system
design, these functional security requirements are further refined
into detailed technical requirements at the hardware and software
level. For example, the functional security requirement: “FSecR
3: It shall not possible to update the software ECUs associated
with the lane assist function without the explicit authorisation of
a trust center (secure software download and activation).” can be
refined into a set of technical requirements on the method of
encrypting and activating software downloads to the ECU,
hardware security modules within the ECU for storing private
keys as well further requirements on the communication medium
used to connect to the ECU and organizational constraints
including key management during production, workshop
processes etc. Once the functional security concept has been
defined, the analysis can be repeated to validate that an
appropriate level of attack potential has been reached and further
enhancements to the concept added if required.
ISO 26262 places a number of conditions on the way safety
requirements are documented, traced, maintained and quality
assured. These constraints should be directly applied to the
functional security requirements derived using the method
described above. In particular, the ISO 26262 demands that all
safety-related requirements are clearly identified as such in the
documentation. The method we have described here clearly
fulfills this constraint. By relating the security goals directly to the
impacted safety goals as well as to the derived functional security
requirements and the allocated system components, these
traceability conditions are fully met.
3.3 Analysing the technical safety and
security concept
ISO prescribes the use of safety analysis methods at the system,
hardware and software design level. The primary goal of these
analyses is to validate the technical design of the system with
Functional Security Requirement Allocated to component
Head Unit,
untrusted applications to trigger the Phone Interface
transmission of messages over the vehicle
bus.
FSecR 2: The lane assist function shall Driver Assistance ECU,
detect if messages are sent from an Steering Column ECU
unauthorised device
FSecR 3: It shall not possible to update Gateway,
the software ECUs associated with the Camera ECU,
lane assist function without the explicit Driver Assistance ECU,
authorisation of a trust center (secure ABS ECU,
software download and activation). Steering Column ECU,
Engine Control ECU
…
respect to its robustness with regard to the safety goals. In other
words, the ability of the system to maintain a safe state despite the
presence of hardware faults or systematic design errors. The most
popular of these analysis techniques is FMEA (Failure Modes and
Effects Analysis) [12] which is prescribed for all ASIL levels
from A to D. FMEA is categorised as an inductive analysis
technique as it analyses effects of failures in a “bottom-up”
approach by considering how failures in individual components
can propagate through the system to become a hazard. ISO 26262
prescribes the use of inductive safety analysis techniques for all
ASIL levels during the system design, hardware design and
software design phases, with the depth of detail in the analysis
being chosen accordingly. Deductive approaches such as Fault
Tree Analysis as a complementary approach are prescribed for
systems with an ASIL of C or D. The attack tree approach
described in Section 3.2 is an example of a deductive analysis
approach and is roughly analogous to fault trees.
An FMEA analysis is particular effective at validating the
effectiveness of the technical implementation of safety concept. It
achieves this by analysing, for each component in the scope of
analysis (e.g. system level components such as ECUs, sensors,
actuators, etc. or hardware level components such as memory,
power transistors, microcontrollers, etc.), the set of possible
failure modes. For each failure mode, the possible effects and
associated severity (S) and potential causes are identified as well
as the probability of prevention (P) and detection (D) based on
existing measures in the system. These criteria are assigned
numerical values (typically between 1 and 10) based on
predefined criteria such as those defined by the VDA [13]. Each
value mode is then assessed according to its Risk Priority Number
(RPN) calculated by multiplying the severity, prevention
probability and detection probability values. If failure modes of
components are identified that lead to a RPN above a certain
threshold (e.g. dependent on the ASIL), then additional measures
in the form of further technical requirements, tests etc. are defined
until the analysis leads to an acceptable set of RPNs.
Key to a systematic and complete FMEA is the identification of a
suitable set of criteria for identifying failure modes. Standardised
hardware component failure modes are defined in Annex D of
Part 5 (Development at the Hardware Level) of ISO 26262. For
system and software level analyses the identification of failure
modes is typically performed based on a set of keywords.
Example keywords for identifying functional failures of
components are: “no output”, “unexpected output”, “course
156
Table 6: Excerpt from a software level FMEA performed for the Camera ECU
SW Function Failure mode Effect S Potential cause Prevention P Detection D RPN
measures Measures
Calculate lane Lane position Counter-steering 10 Camera ECU Calibration can be 8 No possibility 10 800
position data is plausible is applied as soon  software is performed using to detect
but deliberately as the speed deliberately re- standard incorrectly
incorrect. E.g. threshold for calibrated to workshop calibrated
Offset from activating the give incorrect equipment, no system if
center. (Subtle function is results. encryption of manipulated
wrong) reached. (Safety calibration data. in the field.
Goal 1, Security Masquerading Remote 5 Communicati 2 100
Goal 1). of valid message intervention (e.g. on between
IDs by an via Phone Camera and
“intruding” interface) Driver
ECU. prevented by Assistance
firewall concept ECUs is
between encrypted.
infotainment and
chassis busses
implemented in
the Head Unit and
Gateway ECUs.
Physical
intervention still
possible.
… … … … … … … … …
Transmit lane Lane position Lane position data 10 Weaknesses in Rigorous review 4 Hardware 2 80
position data is is not the scheduling and schedulability watchdog
transmitted with synchronised with concept of the analysis of SW mechanism
a delay (result other vehicle data SW are used to reset
too late) used by the lane exploited in a ECU if task
assist function to targeted attack misses its
identify a “lane to cause the deadlines.
straying” communication If no camera
situation. task to miss received, the
Counter-steering deadlines. lane assist
is applied when function
not required. deactivates
(Safety Goal 1,
Security Goal 1)
… … … … … … … … … …

wrong”, “subtle wrong”, “result too early” and “result too late”. have been overlooked at the level of the attack tree analysis.
The FMEA approach can be extended to include the validation of
The resulting RPNs of such a security and safety oriented FMEA
the security concept by making two key changes. First of all,
are correlated against the attack potential identified during the
when analysing the effects of failure modes, not only the potential
initial threat analysis. That is, threats that have been identified as
violation of safety goals should be assessed but also the violation
having a low attack potential figure (i.e. can be executed at a low
of the security goals (that may in turn lead to a deliberate or
cost) and nevertheless a high damage potential (ASIL of
unintentional violation of the safety goals). In particular, the
potentially violated safety goals as a result of the attack) should be
analysis should take into account the impact that failures of
counteracted by a particularly robust security concept, which will
hardware components or errors in the software may have on the
be validated by all failure modes in the FMEA relating to the
security concept, in order to identify potential weaknesses in the
security goal having very low RPN numbers. Table 6 shows an
design that may be exploited by targeted attacks. Secondly the set
excerpt of a software level FMEA for the Camera ECU
of keywords used to identify the failures shall be extended and
component with some example failure mode analyses for several
interpreted in the context of security. For example, the keyword
components. As can be seen, the second and third failure
“subtle wrong” often used to indicate faults that lead to plausible
mode/cause pairings lead to a sufficiently low RPN value and
but nevertheless incorrect data can be extended to include
therefore no additional measures are required. For the first failure
deliberately manipulated data. The keyword “unexpected output”
mode/cause pairing a weakness in the security concept has been
can be extended to include data that has been deliberately injected
identified and additional measures, in the form of revised security
into the system (e.g. additional CAN messages). By extending the
requirements are required.
FMEA analysis in this way, additional security threats and
weaknesses in the system can be identified that may otherwise

157
Figure 6: Excerpt of the safety case for Safety Goal 1
4. AN INTEGRATED SAFETY CASE
The ISO 26262 defines as an integral part of the safety process the
creation of a safety case. The standard defines the safety case in
the glossary as an: “Argument that the safety requirements for an
item are complete and satisfied by evidence compiled from work
products of the safety activities during development.” However,
the normative part of the norm is less clear about the requirements
on the safety case with the requirement that it should
“progressively compile the work products that are generated
during the safety lifecycle” implying that a simple collection of
the relevant project documents is sufficient. Luckily, the
guidelines part of the standard offer a more comprehensive
interpretation, inspired by approaches used for a number of years
already in mature safety-critical industries such as nuclear and
aerospace [14]. Here, the safety case is defined as follows: “The
purpose of the safety case is to provide a clear, comprehensive
and defensible argument, supported by evidence, that an item is
free from unreasonable risk when operated in the intended
context.”
We believe that this structured approach to constructing a safety
case has the potential for tangible benefits in terms of
demonstrating the safety of the system. In this approach, a safety
case would be constructed for each system safety goal describing
the strategies for meeting the goals and referencing assumptions
and justifications made during the analysis and development in a
top-down manner. Work products, such as analyses, reviews, test
cases, etc. are referenced to provide the direct evidence that the
assertions, justifications and assumptions are valid and to provide
the traceability in the argument between the strategy for achieving
the safety goals and effectiveness of the actual measures taken
during development. In doing so, the safety case “knits together”
the evidence contained within the development artefacts to
provide a coherent and defensible argument for functional safety.
The Goal Structuring Notation (GSN) [15] has been successfully
used in a safety-critical industries number of industries for a
number of years as a means for visualising and documenting the
hierarchical structure of the safety argument and is also attracting
increasing interest at a number of automotive manufacturers and
suppliers (e.g. see [16]).
Figure 6 shows an excerpt of a safety case for Safety Goal 1
described using GSN and how, in addition to the main strands of
argument that HW faults do not lead to hazardous situations and
sufficient measures are taken to avoid systematic faults (both lines
of argument not detailed further in the figure), the risk associated
with intentional manipulation of the system has also been
adequately addressed. Safety goals or derived assertions are
represented in the notation as rectangular boxes. Strategies for
arguing the goals are described in the trapezoids. Any
assumptions that were made during development that are relevant
to the validity of the safety case must be documented – see oval
objects annotated with A. The documentation of these
assumptions is critical as unless these assumptions can be
confirmed, the safety case argument does not hold. These
assumptions therefore form a major contribution to the quality and
test plan of the system and direct evidence should be collected
(e.g. targeted tests, analysis of driver behaviour, reviews, field
observations, etc.) and referenced at some point in the safety case.
Finally, at the “leaves” of the argument tree, direct evidence in the
form of work products are referenced (graphically represented as
circles), in combination are sufficient to confirm the referencing
158
goal or assertion. The safety case can be hierarchically
constructed referencing common parts (e.g. for justification of the
development process) or more detailed sub-arguments such as the
arguments for the effective implementation of each of the Security
Goals.
This approach to structuring the argument for safety, including
security related aspects ensures the necessary transparency to
allow for independent parties to validate that the system is indeed
adequately safe. It also is an effective means of capturing best
practice in the development of such concepts that can be reused as
safety case patterns [17] across similar projects.
5. SUMMARY AND CONCLUSIONS
In this paper we have shown how the development process
framework prescribed by ISO 26262, and in particular the
approaches to safety analysis and the construction of the safety
case can be extended to take into account a third type of fault in
addition to random hardware failures and systematic design faults:
that of intentional manipulation of the system. By exploiting the
analogous approaches to risk assessment and goal definition we
show that there are significant similarities between the safety and
security approaches that can lead to an efficient combined
approach.
Ultimately of course, the safety and security of the system
depends on a good system design, which also manages to resolve
potentially conflicting requirements of the two. The approach
described here, however ensures that sufficient rigor is applied
during the design process that all potential risks are analysed and
adequately mitigated against in a manner that is open to
professional scrutiny. The combined approach helps to identify
synergies and potential conflicts at an early design phase and
ensures that the evaluation assurance level achieved for security
threats is appropriate to the potential safety risk, measures in
ASILs resulting from those threats.
As these issues become more and more relevant to the automotive
industry we see a need to extend the ISO 26262 standard with the
consideration of embedded security issues and to standardise the
set of criteria used for assessing the risk associated with attack
scenarios that haven an impact on the safety goals. This should
include defining thresholds for aligning the required minimum
attack potential per ASIL as well as standardising an
interpretation of the common criteria for the embedded
automotive systems.
6. REFERENCES
[1] Charette, R., 2009, This Car Runs on Code,
http://spectrum.ieee.org/ green-tech/advanced-cars/this-car-
runs-on-code.
[2] International Organization for Standardization, 2011, ISO
26262 “Road Vehicles – Functional Safety”, International
Standard.
[3] Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T.,
Checkoway, S., McCoy, D., Kantor, B., Anderson, D.,
Shacham, H. Savage, S..,2010, Experimental Security
Analysis of a Modern Vehicle, 2010 IEEE Symposium on
Security and Privacy..
[4] Common Criteria for Information Technology Security
Evaluation, continually maintained as ISO 15408. Part 1:
Introduction and general model, Version 3.1, Revision 1,
September 2006, Part 2: Security functional components,
Version 3.1, Revision 2, September 2007, Part 3: Security
assurance components, Version 3.1, Revision 2, September
2007.
[5] Common Criteria Recognition Agreement, Available at
www.commoncriteriaportal.org/theccra.html, 2006. Forman,
G. 2003.
[6] Common Methodology for Information Technology Security
Evaluation, Version 3.1, Revision 2, September 2007,
Continually maintained as ISO 18045.
[7] Avižienis, A. , Laprie,J-C., Randell, B., Landwehr, C. 2004,
Basic Concepts and Taxonomy of Dependable and Secure
Computing, IEEE Transactions on Dependable and Secure
Computing, pp. 11-33, January-March, 2004.
[8] Sindre, G. and Opdahl, A.L, 2005, Eliciting security
requirements with misuse cases, Requirements Engineering
(2005) 10: 34-44.
[9] Schneier, B. 1999, Attack Trees – Modelling Security
Threats, in Dr. Dobb’s journal, available at
http://www.schneier.com/paper-attacktrees-ddj-ft.html,
December 1999.
[10] Scheibel, M.,Wolf, M., 2009, Security Risk Analysis for
Vehicular IT Systems — A Business Model for IT Security
Measures, In 7th Embedded Security in Cars Workshop
(escar 2009).
[11] Burton, S., Habermann, A., 2012, Automotive Systems
Engineering and Functional Safety: The Way Forwards,
ERTS2012.
[12] Automotive Industry Action Group (AIAG), “Potential
Failure Mode and Effects Analysis (FMEA)”, 2008.
[13] VDA: Sicherung der Qualität vor Serieneinsatz – System-
FMEA, 1. Aufl. 1996, ISSN 0943-9412
[14] Wilson, S.P., Kelly, T.P., McDermid, J.A., 1995. Safety Case
Development: Current Practice, Future Prospects in
Proceedings of 1st ENCRESS/12th CSR Workshop,
September 1995, Springer.
[15] Kelly, T.P., Weaver, R.A., 2004, The Goal Structuring
Notation - A Safety Argument Notation, in Proceedings of
the Dependable Systems and Networks 2004 Workshop on
Assurance Cases.
[16] Palin R., Habli I., 2010: Assurance of Automotive Safety: A
Safety Case Approach, in the proceedings of the 29th
International Conference on Computer Safety, Reliability
and Security (SAFECOMP), Vienna, Austria, September,
2010.
[17] Kelly, T.K., McDermid, J. A., 1998. Safety Case Patterns -
Reusing Successful Arguments, In Proceedings of IEE
Colloquium on Understanding Patterns and Their
Application to System Engineering, London, U.K.
159