A Case Study of FMVEA and CHASSIS as Safety and
Security Co-Analysis Method for Automotive
Cyber-physical Systems
Christoph Schmittner
Safety & Security Department
Austrian Institute of Technology
christoph.schmittner.fl@ait.ac.at
Erwin Schoitsch
Safety & Security Department
Austrian Institute of Technology
erwin.schoitsch@ait.ac.at
ABSTRACT
The increasing integration of computational components and
physical systems creates cyber-physical system, which pro-
vide new capabilities and possibilities for humans to control
and interact with physical machines. However, the correla-
tion of events in cyberspace and physical world also poses
new safety and security challenges. This calls for holistic
approaches to safety and security analysis for the identifi-
cation of safety failures and security threats and a better
understanding of their interplay. This paper presents the
application of two promising methods, i.e. Failure Mode,
Vulnerabilities and Effects Analysis (FMVEA) and Com-
bined Harm Assessment of Safety and Security for Infor-
mation Systems (CHASSIS), to a case study of safety and
security co-analysis of cyber-physical systems in the auto-
motive domain. We present the comparison, discuss their
applicabilities, and identify future research needs.
Categories and Subject Descriptors
C.4 [Performance of Systems]: Design studies, Model-
ing techniques; C.3 [Special-purpose and Application-
based Systems]: Real-time and embedded systems; D.2.1
[Software Engineering]: Requirements/Specifications—
Methodologies
Keywords
Safety and Security Co-analysis; Cyber-physical system; Sys-
tems engineering; Automotive
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 cita-
tion on the first page. Copyrights for components of this work owned by others than
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-
publish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
CPSS’15, April 14, 2015, Singapore.
Copyright is held by the owner/author(s). Publication rights licensed to ACM.
ACM 978-1-4503-3448-8/15/04 ...$15.00.
http://dx.doi.org/10.1145/2732198.2732204.
Zhendong Ma
Safety & Security Department
Austrian Institute of Technology
zhendong.ma@ait.ac.at
Thomas Gruber
Safety & Security Department
Austrian Institute of Technology
thomas.gruber@ait.ac.at
1. INTRODUCTION
Cyber-physical systems (CPS) are systems with interact-
ing computational components and physical systems. CPS
provide many new capabilities and possibilities for humans
to control and interact with physical machines. Besides
application domains such as energy, industrial control and
healthcare, CPS have also made evolutionary changes in mo-
bility, especially automobiles. Automotive cyber-physical
systems transform vehicles from electromechanical systems
into intelligent means of transport for improved road safety,
traffic efficiency, and human convenience. Automotive cyber-
physical systems in modern vehicles are complex, with up
to 100 Electronic Control Units (ECUs) [1] and multiple
internal networks connecting intelligent sensor nodes with
control units and actuators. Such connectivity and cooper-
ation enable vehicles to connect with other road users and
the infrastructure systems, such that the drivers can react
more quickly and correctly to their environment. Current
projection shows that the vehicles of the future will be a
part of intelligent transportation systems characterized by
seamless interaction and cooperative mobility among multi-
ple road vehicles and other modes of transport. Embedded
systems such as computation devices, sensors, real-time con-
trol systems, and communication networks enable vehicles
for many advanced maneuvers and functions, e.g. driverless
cars, vehicle-to-vehicle (V2V) and vehicle-to-infrastructure
(V2I) communication. This allows highly automated driv-
ing and cooperative response to road and traffic conditions
on local as well as regional basis.
However, the increased interactivity between cyber and
physical systems and connectivity also gives rise to new
safety and security challenges. Since attacks in cyberspace
can lead to devastating consequences in the physical world,
ensuring safety and security in the engineering process are
two equally important aspects for developing systems with
high availability, reliability, and dependability. Due to the
tight interplay between safety and security, combining safety
and security in the engineering process for CPS has become
a new interesting research topic in recent years [2], [3].
 This paper investigates an integral part of the safety &
security co-engineering approach called safety & security co-
analysis, which aims to identify and analyze safety and se-
curity risk in a holistic approach. We focus on the methods
that enable the assessment of safety effects from security
threats and vice versa. In [4], we presented a Failure Mode
and Effect Analysis approach which extends safety analysis
to include security. We applied the method to the analysis
of a vehicle system in [5]. In this paper, we further evalu-
ate another promising approach, i.e. the Combined Harm
Assessment of Safety and Security for Information Systems
(CHASSIS) [6], and compare it with FMVEA. As a work
in progress for establishing a holistic safety & security co-
analysis method, we apply both approaches to a case study
of automotive CPS. We compare the results and discuss the
research challenges and gaps.
In the following, Section 2 reviews the existing work and
standardisation approaches for safety and security. Section
3.1 and Section 3.2 introduce FMVEA and CHASSIS, re-
spectively. Section 4 presents our comparison of the two
approaches, followed by the conclusion in Section 5.
2. STATE OF THE ART
Due to tight coupling between communication and com-
puting systems and physical machines in CPS, events in cy-
berspace and physical world become increasingly correlated.
Consequently, safety and security challenges arise in all do-
mains where CPS are used.
In the past, the safety and security communities devel-
oped quite differently and almost independently, and the
resulting standards, guidelines and methods were also lim-
ited to safety or security. With cyber-physical systems be-
coming ubiquitous, and their connectivity particularly over
“open” (i.e. wireless) channels predominant, a holistic view
on the dependability of systems becomes essential, including
all the properties of safety, security, reliability, availability
and maintainability [7].
2.1 Safety Analysis
In literature, many risk analysis methods can be found
with varying level of details and for different degree of knowl-
edge about the system under consideration, for instance, for
the chemical process industry [8]. ISO/IEC 31010:2009 [9]
lists 31 risk analysis methods without making claims of be-
ing exhaustive. It contains short descriptions and provides
guidance on which technique is appropriate for obtaining
certain result values in a particular setting with specific in-
fluencing factors (cf. tables A.1 and A.2 in [9]). Although it
states “This standard does not deal specifically with safety.
It is a generic risk management standard . . . ,” it is evident
that most of the methods described are primarily, if not only,
intended for safety analysis, and there is no guidance at all
how to deal with security vulnerabilities and threats.
Safety-oriented risk analysis methods are available for qual-
itative as well as quantitative analysis. In ISO/IEC 31010:2009,
well-introduced and, if required, detailed quantitative safety
analysis can be found. Among them are established meth-
ods like HAZard and OPerability study (HAZOP [10]), Fault
Tree Analysis (FTA [11]), and Failure Modes and Effects
Analysis (FMEA [12]). The latter formed the basis on which
one of the two methods compared in this paper is based,
namely FMVEA.
Safety analysis normally includes the potentially affected
system element, the way how the element fails, possible
causes, local as well as system-global consequences, exist-
ing and necessary detection, protection and mitigation mea-
sures, and the likelihood of the failure. For stochastic hard-
ware faults, the latter can be taken from statistical data.
Software faults and systematic hardware faults can be widely
eliminated by high-quality development processes and rigor-
ous verification and validation leaving the residual system-
atic failure rate below the critical threshold. With respect
to security analysis, however, likelihood is one of the issues
which make a common and comparable safety and security
analysis difficult.
In addition, safety analyses can and should be performed
at early stages and during the system development. The
results are valid as long as no changes to the system are
made. Security analysis should continue while the system is
deployed in the target environment and need to be updated
when new vulnerabilities are found.
2.2 Security Analysis
Several standards and guidelines exist today, which are ap-
plicable to information security analysis. ISO/IEC 27000 se-
ries provide standards on information security and risk man-
agement, and security controls. In general, these standards
focus on security policy and security management strategy.
In NIST SP800-30 “Risk Management Guide for Informa-
tion Technology Systems”, a methodology is proposed to
conduct risk assessment in nine sequential steps. From a
security point of view, ISO/IEC 31010 is also relevant be-
cause it provides information on risk assessment concepts,
processes and the selection of risk assessment techniques.
Commonly used techniques in the practice include threat
modeling [13] and attack tree [14]. Threat modeling is pro-
posed by Microsoft as an integral part of its security de-
velopment lifecycle. It identifies threats and impacts in a
system design. Attack tree is an extension of the Fault Tree
Analysis. It uses a tree structure to identify potential attack
steps and their inter-relations.
In the research community, attack graph [15] is method to
identify security risks from network-based attacks. In attack
graph, a network is modeled as a finite state machine. The
state space of the network is then enumerated to find the
network in a insecure state. CORSA [16] is a model-based
security risk analysis method. First, a system is modeled
using a modeling language such as UML. Security risks are
identified in structured brainstorming, in which the target of
analysis is viewed from different perspectives from different
participants to ensure that a broad scope of security risks
are considered.
2.3 Security in Safety Standards
In the standardization community of IEC TC651 , aware-
ness has risen that security is becoming a crucial factor for
these automation and control systems. It has to be man-
aged differently from the computing- and data center based
approaches of the e.g. ISO 27000 series [17], and in a more
holistic/system centered manner than by ISO/IEC 15408
(Common Criteria) [18].
1
Industrial-process measurement, control and automation,
where most of the computer-based functional safety stan-
dards are developed.
 End of October 2014, was the kick-off of a new Ad-Hoc
Group of IEC TC65 on “Framework for co-ordination of
safety and security (in industrial automation)”. Mission
of the group is to look into this issue from a more gen-
eral system point of view and to derive recommendations
how to treat this issue in context of functional safety stan-
dardization. As a starting point, an overview was provided
on how functional safety standards from different domains
prefer more or less integration/separation of safety and se-
curity concerns. The following is an excerpt from the func-
tional safety standards review, how security is considered in
the automotive, railway, machinery and generic functional
safety standards.
In the automotive safety standard ISO 26262 [19], secu-
rity risks are not considered. While “reasonably foreseeable
misuse” is mentioned as an factor for the risk assessment, it
relates only to misuse (e.g. a reckless driver) without mali-
cious intention.
Besides automotive-CPS such challenges arise also in the
railway domain where in the past this was rather a phys-
ical issue because of separated electro-mechanical and pro-
prietary communication systems. With the increasing use
of wireless communication (European Train Control System
(ETCS)[20]) security requirements have to be considered,
although safety remains the primary issue for certification.
The IEC 62443 standard [21] “Industrial communication net-
works - Network and system security - Security for industrial
automation and control systems”, was identified as a start-
ing point to integrate security in their domain specific safety
standards [22]. Particularly in Germany a draft for an up-
date of EN 50129 [23] to include security requirements from
IEC 62443 was started.
The functional safety standard for machinery group (IEC
TC44 committee) proposed to separate safety and security
requirements and responsibilities. This proposal was sent
to ISA for comments, and ISA stated: “Requirements for
safety and security can be termed differently, but separating
them can easily lead to a misunderstanding in the integra-
tor or end-user about the interrelationships between those
requirements. By separating the requirements, integrators
and end-users may try to respond to them separately, which
can lead to increased risks”.
The generic safety standard, IEC 61508 Ed 2.0 (2010)
[24] requires the consideration of security threats during haz-
ard analysis in the form of a security threat analysis (IEC
61508, Part 1, 7.4.2.3). Nevertheless, there is no guidance for
this step. It is only mentioned that if such security threats
have been identified, a vulnerability analysis should be un-
dertaken to specify security requirements. Details should
be included in the safety manual. IEC 61508-3 has started
to prepare for IEC 61508 Ed. 3.0. The more in-depth in-
tegration of security throughout the whole life cycle have
been taken up as one of the high-priority issues. This will
include new methods and techniques as discussed in this pa-
per and the corresponding levels of recommendation in the
mandatory and informative tables and guidelines.
2.4 CPS Challenges
In general, none of the above standards mentions CPS
or specific CPS related challenges. If we look at Internet
of Things (IoT) standards in the IEC repository we get a
huge number of related standards which cover only parts
of the challenges. The major challenges along the entire
development life cycle are:
• Requirements: Existing requirements engineering meth-
ods will not scale up with the complexity of CPS, for-
malization and “standardization” of requirements will
have to be managed.
• Risk- and Hazard analysis: The different dependability
categories cannot be considered independently. Com-
bined methods and techniques are required.
• Scale of deployment: Mass deployment embedded in
one or sometimes several (critical) infrastructures needs
particular attention, orchestrating the interrelation-
ships and dependencies, and potential misuse and ma-
licious interactions
• Maintenance of CPS: Involves managing or correct-
ing upcoming vulnerabilities, defects and wear-out, all
identified or happening by use, not only on the single
embedded system, component or part, but also on the
overall infrastructure and all related elements. Remote
maintenance is unavoidable, including coping with the
associated risks.
• Changing context: The context of use has to be ob-
served continuously, particularly human interaction,
experience and focus of control for partially automated
systems.
• Flexibility: Adaptation, reconfiguration, enhancement
and frequent re-design of elements or infrastructure has
to be considered.
The basis for design, building and maintenance of trust-
worthy systems remain a sound system risk- and hazard
analysis (through the overall life time in case of systems of
CPS). From the systems engineering view, dependability has
to built in from the very beginning, neither property can be
later just be an add-on to a system of that level of complex-
ity without running into the danger of causing unforeseen
emergent faults (and failures).
3. SAFETY AND SECURITY CO-ANALYSIS
METHODS
In [25] a first approach to combining fault and attack trees
was presented, in which attack trees are connected as spe-
cial nodes to a fault tree. Depending on the combination,
three different approaches for probability calculation were
proposed. Boolean logic Driven Markov Processes (BDMP)
[26] is an approach where fault tree analysis and attack tree
analysis are combined and extended with temporal connec-
tions. Besides the logical structuring, top events are acti-
vated based on the state of basic events. BDMP also uses
“triggers” to model dependencies among sub-trees. A sub-
tree connected with a trigger is only true if the element at
the origin of the trigger is true. In addition, leave nodes
have two potential fault behaviors: failure in operation or
failure in demand.
Young and Leveson [27] proposed to take a system think-
ing approach to safety and security analysis. As a result,
a loss or disruption of the system is caused by interactions
among various factors including safety hazards and security
vulnerabilities.
 The analysis focuses on modeling systems into a hierarchi-
cal structure in order to identify control actions at each level
that have the potential to bring a system to a vulnerable
state. Based on the control actions, security requirements
and constraints, as well as the causal relations are identi-
fied. However, their approach has a focus on strategy and
conceptual guidelines. In our opinion, the lack of details on
actionable techniques and the high level of abstraction make
it not readily applicable to real world problems.
This paper focuses on two recent approaches, Failure Mode,
Vulnerabilities and Effects Analysis (FMVEA) and Com-
bined Harm Assessment of Safety and Security for Informa-
tion Systems (CHASSIS), which in our opinion, provide not
only high level concepts but also concrete and actionable ac-
tion points for the combined safety and security analysis of
CPS.
3.1 FMVEA
Failure Mode, Vulnerabilities and Effects Analysis (FMVEA)
is based on the Failure Mode and Effect Analysis (FMEA)
[12] and extends the standard approach with security re-
lated threat modes. Figure 1 shows the process of applying
Figure 1: Overview of FMVEA method
FMVEA to a system. First a system is modeled. Then
the failure and threat modes for each element of the system
model are identified. While a failure mode describes the
manner in which the function of an element fails, a threat
mode describes the way in which the identified function of
a element can be misused.
Threat modes are based on the STRIDE [13] approach,
which classifies threats in six categories (Spoofing of user
identity, Tampering, Repudiation, Information disclosure,
Denial of service, Elevation of privilege). Depending on the
domain, the system architecture and the knowledge about
the system, failure and threat modes can be refined and ex-
tended.
Each identified failure or threat mode associated with the
element is investigated for potential effects. For modes with
critical effects, potential causes are analyzed and the likeli-
hood for each cause is estimated. For threat modes, likeli-
hood is determined using a combination of threat and sys-
tem properties. Threat properties mainly describe the re-
source and motivation of a potential threat agent while sys-
tem properties include reachability and system architecture.
The system model is based on a three-level data flow dia-
gram (DFD). Effects of failure and threat modes are pre-
sented at the context level of the diagram, which shows the
interaction between the system and its environment. Failure
and threat modes are located at the level 1 DFD. Vulnera-
bilities and failure causes are based on the level 2 DFDs.
3.2 CHASSIS
Combined Harm Assessment of Safety and Security for
Information Systems (CHASSIS) [6] is an approach for re-
quirements engineering via use cases and sequence diagrams.
Figure 2 gives an overview about the CHASSIS process
regarding the elicitation of functional and safety and secu-
rity Requirements. Step 1 of CHASSIS is concerned with
the definition of functional requirements as a basis for the
elicitation of safety and security requirements. Users, func-
tions and services are described in use case diagrams (D-UC)
and textual descriptions of use cases (T-UC). Sequence di-
agrams (SD) are used to refine the contents of the use case
diagrams and to model objects and their interactions. If a
system is already developed to the point where architecture
and functions are defined, the artifacts produced during this
activity might have to be reworked in order to be used for
CHASSIS.
In step 2, the elicitation of safety and security require-
ments is carried out. Through a brainstorming session with
domain as well as safety and security experts, potential mis-
uses of the system are identified. The names of use cases are
combined with hazard and operability study (HAZOP) [28]
guide words in order to obtain potential misuses of the sys-
tem2 . There may be more than one misuse case per use case.
After the identification of potential misuse cases, potential
misusers are identified. Misusers include all human users (al-
lowed or not), external systems and internal parts which can
fail or threaten the system. Based on the identified scenar-
ios misuse case diagrams (D-MUC) are drawn. Besides the
graphical representation, safety and security misuse cases
are also written down as textual misuse case (T-MUC). The
T-MUC may contain additional details and a extended de-
scription of actors and misusers. Misuse sequence diagrams
are used to describe chains of events and interactions which
leads to an misuse of the system. In safety and failure related
cases the same task is fulfilled by failure sequence diagrams
(FSD).
2
Since CHASSIS does not provide a specific list of guide
words, we opt to use the standard guide words in [28].
 Figure 3: Overview of OTA system

Depending on chosen functionality, the connection is ei-

Figure 2: Overview of CHASSIS method
Safety and security misuse cases and misusers are inte-
grated in the D-UC. Goal of step 2 is to identify safety haz-
ards, failures and potential mitigation measures and equally
security threats, vulnerabilities and potential mitigation mea-
sures.
ther handled over long-range cellular networks or short range
communications such as Wi-Fi or Bluetooth. Additional re-
mote access methods such as wireless key or Tire Pressure
Monitoring System (TPMS) are not considered here.
In-vehicle network architectures differ to an great degree
among each other [31]. Even system architectures from the
same manufacturer differ depending on model year and car
type. One commonality is that all vehicle systems use gate-
ways between their different buses. The need for multiple
buses arises from different timing requirements for functions
and from limits on how much control units can be connected
to a bus. Gateways connect different parts and enable func-
tions to obtain needed information from all parts of the ve-
hicle. Since gateways are able to access all buses, updates
or remote access functions are mostly installed in such com-
ponents. Modern vehicles typically have up to 3 high-speed

4. CASE STUDY
In order to compare both approaches, we use a similar
target system as in [5]. As shown in multiple studies and
surveys [29, 30, 31] today’s vehicles are vulnerable to se-
curity threats which can adversely affect the safety. While
most existing investigations for automotive systems are con-
cerned with finding existing vulnerabilities in vehicles, we
aim at an approach for a proactive and combined safety and
security analysis in the design phase for automotive CPS.

4.1 System description

As described in [32, 33, 34] we extend our simplified auto-
motive architecture with remote diagnosis and maintenance
features. Such systems enable Over The Air (OTA) updates
and the management of vehicle functions over communica-
tion links. In addition to system maintenance and service,
the owner is also able to connect to the vehicle to remotely
configure and control functions. Such a system consists of
three major parts: vehicle, remote access user, and commu-
nication network.
Figure 3 shows the basic components of an OTA system.
In our analysis, we focus on the interconnection between out-
side area and the vehicle. Researchers found out that neither Figure 4: Overview of in-vehicle network
controller area network (CAN) bus nor FlexRay include suf-
ficient security features to resist security attacks [30, 29, 35]. CAN and 3 low-speed CAN bus systems, dedicated networks
Therefore, we can reason that if an attacker is able to access for advanced driver assistance systems (ADAS) and connect
the in-vehicle network either directly or remotely, safety and up to 50 simpler modules via LIN or MOST.
security of the vehicle are endangered.
 Our simplified system architecture in Figure 4 excludes
the less critical MOST and LIN connections and contains
only one high-Speed and one low-speed CAN bus.
4.2 Analysis of OTA System
We focus on the long-range cellular connections to the ve-
hicle. These connections are used by the Telematic Control
Module for crash report and maintenance. In order to en-
sure connectivity over a wide range of potential conditions,
digital information is encoded and sent over a voice channel
[36]. For now this connection is only used for communication
with the Telematics Call Center (TCC) in order to enable
remote diagnostics and maintenance. The considered sce-
nario is an attack or failure in the Firmware Over The Air
(FOTA) functionality.
4.2.1 FMVEA
Figure 5 shows a simplified context level data flow diagram
of a vehicle system.
Figure 5: Context level diagram of an vehicle
The in-vehicle network contains all ECUs and interacts
with the TCC and the user. The interaction with the TCC
is either wireless via GSM or via the on-board-diagnostic
(OBD) interface. The user can interact over an wireless
connection or directly over physical interfaces like steering
wheel or pedals. We excluded all comfort functions and re-
stricted the control of the vehicle to lateral and longitudinal
movements. The in-vehicle network steers the vehicle and
reacts on inputs from different sensors for the movement.
The level 1 diagram in Figure 6 shows the data flow dia-
gram for an update of the transmission control unit. Main
objective of the transmission control unit is, depending on
driver input and vehicle state, to choose the correct gear in
order to optimize driver experience and fuel efficiency.
Figure 6: Level 1 diagram of Telematics and Trans-
mission Control Module
Appropriate failure and threat modes are applied to all
elements in Figure 6 in order to identify safety and security
risks. The level 2 diagram in Figure 7 is used to identify
potential causes for failure or threat modes. It shows a more
detailed model of the scenario analyzed. Depending on the
focus of the analysis different parts of the model can be
refined or excluded. We excluded driver input and additional
processes in the Transmission Control Module.
Figure 7: Level 2 diagram of an Firmware Over The
Air Update process
After the identification of failure and threat modes and
their effects, the severity is determined. In the next step po-
tential causes are identified. For non-malicious causes sta-
tistical data is used in order to assess the probability of a
failure. For deliberate actions which cause a threat or failure
mode, the probability is determined using threat properties
and system properties. For example, if the user of a vehi-
cle is assumed to be a potential attacker, threat modes that
require direct access to the vehicle are possible.
Figure 8 shows how the FMVEA interacts with the dif-
ferent levels of a dataflow diagram. System level effects are
identified on level 0. It describe the interactions between
the system and it’s environment. On this level end effects of
failure and threat modes are identified and modeled. Level 1
contains failure and threat modes for the different elements
and direct effects of failures and threats. Level 2 is used to
describe the causes for failure and threat modes, faults and
vulnerabilities.
As an example, a failure / threat mode could affect the
Telematic Control Module and lead to the application of
an incorrect or manipulated update. This could be caused
by an fault or vulnerability in the validate update process
in the Telematic Control Module. Such a failure / threat
mode could lead to an changed, restricted functionality of
the Transmission Control Module and could therefore dis-
rupt the lateral movement of the vehicle.
A full excerpt of the FMVEA tables for the analysed sys-
tem is shown in figure 9.

Figure 8: Integration of Failure and Threat Event
Chain of FMVEA with Dataflow Modelling
4.2.2 CHASSIS
In a typical FOTA update, a firmware binary is sent from
an Original Equipment Manufacturer (OEM) or other party
from the backend system via the TCC to the Telematic Con-
trol Moduel in the car and then flashed to the ROM of the
ECU [37]. The binary goes through a series of communica-
tion channels (including Internet, wireless communication,
and in-car buses) and entities, which possess a large attack
surface from a security point of view. Following the guide-
line in [38] and based on existing work [39, 37, 36], several
misuse cases are identified in the CHASSIS security assess-
ment. The threats and threat scenarios are identified us-
ing the information security Confidentiality, Integrity, and
Availability (CIA) model in a brainstorming session.
Since updates are in binary form, we neglect confidential-
ity threats. We identified three scenarios of integrity threats:
1. an update might be tampered during transmission by
an attacker unless proper signing and verification mech-
anisms are in place at both ends;
2. an attacker might send the ECUs software that is mas-
queraded as updates from legitimate sources (note that
such an attack is demonstrated by the Duqu malware
[40]);
3. since ECUs are considered untrusted environment, the
owner of the vehicle might act as a misuser to tamper
ECUs in order to allow them to accept any firmware
update for additional functionality and feature.
Two scenarios are identified for availability threats:
1. an attacker might send a large amount of firmware
files in order to crash the communication stack of the
Telematics Control Module or deplete the computation
resource since the ECUs need to verify the binary;
2. an attacker might keep sending bogus updates to the
Telematic Control Module to block other legitimate
functional update.
Since no guide word lists are found in the CHASSIS guide-
line [41] we use a generic list of HAZOP guide words from
[28] for the safety assessment. Using “EARLY” we identi-
fied a potential safety risk if an update is deployed while the
ECU is still in use. Normally, updates are only deployed if
the vehicle is in a non-critical driving situation, or prefer-
ably standing. An early update process while the ECU is
still in use can lead to a critical situation. For example,
the steering assist system or brake booster system can stop
working while the car is driving. Using “OTHER THAN”, a
potential failure might be that an update is sent to a wrong
ECU or is deployed to a wrong model variant. As described
in [42], functionality often differs between production years
of the same model and OEMs try to reuse as much of their
software as possible in newer generations. This might lead
to a situation where a wrong firmware leads to an unwanted
behavior or total failure of a Control Unit without a warning
to the driver.
A failure or mis-configuration can lead to a situation where
a firmware update is deployed multiple times. This is repre-
sented by the guide word “MORE”. The firmware update is
either sent multiple times by the TCC and blocks the func-
tion of the Telematic unit, or the Telematic unit is faulty
and sends the firmware update multiple times to all buses
and blocks a functions of the car.
Figure 10 gives an overview of the graphical development
of use cases and misuse cases for safety and security. CHAS-
SIS introduces the “threaten” relation, which connects a mis-
use case to the threatened use case. As described in the
CHASSIS guideline, safety and security assessment is con-
ducted in two separate sessions and the results are combined
afterwards.
4.3 Comparison
Although both methods are claimed to be a combined
safety and security analysis, an in-depth look into the two
approaches shows that CHASSIS and FMVEA have several
differences and hence different applicability in specific con-
text. In the following, a comparison along several criteria is
given.
4.3.1 Level of abstraction
CHASSIS is a quite high level approach, which is suit-
able for the analysis in early requirement and concept phase,
when a system is not clearly defined and little information is
known. In contrast, FMVEA needs at least a list of system
elements and connections between the elements in order to
generate meaningful results. This enables a more detailed
analysis and a connection between failure causes and system
elements. FMVEA uses the information about the system
architecture for rating risks, a step excluded from CHAS-
SIS. Therefore, FMVEA is more appropriate for later phases
in the engineering process such as design and verification,
where more information about the system is available. In
contrast, CHASSIS is better suited as a first step in the risk
analysis which identifies critical usage scenarios.
4.3.2 Comparability of repeated analysis
While causes for threat modes (attack vectors) can differ,
depending on the system architecture and environment, the
information on threat and failure modes is usually compo-
nent specific. Thus it is possible to reuse the information
for repeated analyses. As long as the list of potential threat
modes or the system architecture is not changed, a FMVEA
analysis will provide comparable results which are less likely
to differ in significant way. CHASSIS depends more on ex-
pert knowledge. The field and the level of experiences can
differ, which will effect analysis results. For example, if a
CHASSIS analysis is repeated by a new group, due to the
differences in the experts, new view points can be introduced
that change the results.
4.3.3 Reusability of analysis artefacts
In addition to lists of potential failure modes, FMVEA
uses threat catalogues for specific elements. As the example
in [43], a threat catalogue for wireless connections was spec-
ified which can be used as an input for FMVEA. Reusabil-
ity of CHASSIS elements is mostly not possible. While the
guidewords are the same for each analysis, they are merely
a suggestion for brainstorming which produces only system
specific results.
4.3.4 Scope of analysis
FMVEA depends to a high degree on the accuracy of the
system model and the available information on potential
threat and failure modes. Connections or elements which
are not contained in the model do not contribute to the
results of the analysis. In the contrary, CHASSIS depends
mostly on the knowledge of the experts. Since it is suggested
that the list of use cases used as a starting point can be ex-
tended during the assessment, it is possible to expand the
consideration of risk scenarios which do not arise directly
from the system model.
4.3.5 Suitability for a risk rating
CHASSIS is a semi-formalised approach where potential
security and safety risk scenarios are explored trough the us-
age of use cases and guide words. While it is possible to rate
the discovered risk scenarios this is mostly a reflection of the
expertise of the involved experts. Misuse cases are described
trough free text and are difficult to be used as a basis for a
consistent risk rating. FMVEA is interconnected with the
system model and potential attack and failure scenarios are
described trough the model.
While there is still the challenge to unify randomly caused
failures and motivated threats the rating of risks is easier in
FMVEA.
4.3.6 Adaptability to changing context
Comparing both analysis CHASSIS is less formal than
FMVEA. This allows CHASSIS to consider different us-
age scenarios and changing environment more easily than
FMVEA. Even if a future change in the context of use is
not clearly pictured in the system model it may be recog-
nized by the involved experts. Dynamic systems are more
easily analysed trough CHASSIS. While applying the same
threat catalogues to all potential architecture configurations
provide insights how they compare in respect to susceptibil-
ity to threats and failures it requires time and resources.
5. CONCLUSION AND FUTURE WORK
The increasing integration of computer systems into phys-
ical machines in cyber-physical systems poses new safety and
security challenges. A combined safety and security analy-
sis is an indispensable part to have a better understanding
of the interplay between cyber space and physical world for
engineering highly dependable CPS. As a part of our on-
going effort to develop a holistic approach to safety & secu-
rity co-analysis, this paper shows a case study of applying
two promising analysis methods (FMVEA and CHASSIS)
to automotive CPS. We evaluate and compare the results
and discuss their applicability to CPS.
Based on our experience with safety and security co-engineering,
we argue that a holistic approach must aim at integrating
both safety and security concerns with clear expressions of
the interplays. For example, as our case study shows, one
weakness of CHASSIS is that while safety and security are
analysed with the same methodology the two assessments
are done separately. There is a need for exchange and dis-
cussion between both the safety and the security domains
in all phases of system engineering lifecycle. From an engi-
neering point of view, commonalities and conflicts from both
domains need to be identified in the beginning, documented
and resolved. A unified risk rating for threats and failures
which influences security would be a necessary improvement
for both methods.
Despite their differences, the two approaches investigated
in this paper all exhibit potentials for addressing some of
the CPS challenges. Both methods can be used for identify-
ing safety and security requirements, in which concerns on
cyber security and physical harzards are addressed in a com-
bined manner. However, at this stage, both methods do not
explicitly address how to conduct safety and security anal-
ysis in a continuous manner. This becomes an issue when
a new vulnerability or attack vector is identified, which will
change the risk assumptions and the risk postures based on
the previous analyses and assumptions. How to efficiently
conduct analysis in this situation will be one direction of our
next step.
Furthermore, we will develop and improve the existing
safety & security co-analysis method and to apply it to real
world CPS engineering problems to gain more insights and
practical experiences. In addition, FMVEA requires threat
catalogues for identifying threat and failure modes.
 A comprehensive understanding of the threats and vulner-
abilities of existing CPS components and systems and their
cyber-physical implications will improve the accuracy and
certainty during analysis.
Acknowledgments
This work was partially funded by EU ARTEMIS EMC2
project (contract no. 621429) and Austrian Research Pro-
motion Agency (FFG). We thank our reviewers for valuable
comments and suggestions.
6. REFERENCES
[1] U. Abelein, H. Lochner, D. Hahn, and S. Straube,
“Complexity, quality and robustness - the challenges of
tomorrow’s automotive electronics,” in Design,
Automation & Test in Europe Conference &
Exhibition (DATE), 2012.
[2] A. Banerjee, K. K. Venkatasubramanian,
T. Mukherjee, and S. K. Gupta, “Ensuring safety,
security, and sustainability of mission-critical
cyber–physical systems,” Proceedings of the IEEE,
vol. 100, no. 1, pp. 283–299, 2012.
[3] D. Schneider, E. Armengaud, and E. Schoitsch,
“Towards trust assurance and certification in
cyber-physical systems,” in Computer Safety,
Reliability, and Security, pp. 180–191, Springer, 2014.
[4] C. Schmittner, T. Gruber, P. Puschner, and
E. Schoitsch, “Security application of failure mode and
effect analysis (FMEA),” in Computer Safety,
Reliability, and Security, 2014.
[5] C. Schmittner, Z. Ma, and P. Smith, “FMVEA for
safety and security analysis of intelligent and
cooperative vehicles,” in Computer Safety, Reliability,
and Security, 2014.
[6] C. Raspotnig, P. Karpati, and V. Katta, “A combined
process for elicitation and analysis of safety and
security requirements,” in Lecture Notes in Business
Information Processing, 2012.
[7] A. Avizienis, J.-C. Laprie, B. Randell, and
C. Landwehr, “Basic concepts and taxonomy of
dependable and secure computing,” Dependable and
Secure Computing, IEEE Transactions on, vol. 1,
no. 1, pp. 11–33, 2004.
[8] Center for Chemical Process Safety of the American
Institute of Chemical Engineers, Guidelines for
Hazard Evaluation Procedures, 3rd edition. 2008.
[9] International Electrotechnical Commission, “ISO/IEC
31010, Risk management - Risk assessment
techniques,” 2009.
[10] International Electrotechnical Commission, “IEC
61882: Hazard and operability studies (HAZOP
studies) - Application guide,” 2001.
[11] International Electrotechnical Commission, “IEC:
61025 Fault tree analysis (FTA),” 2006.
[12] International Electrotechnical Commission, “IEC
60812: Analysis techniques for system reliability -
procedure for failure mode and effects analysis
(FMEA),” 2006.
[13] Frank Swiderski and Window Snyder, Threat
Modeling. Microsoft Press Redmond, 2004.
[14] B. Schneier, “Attack trees,” Dr. DobbâĂŹs journal,
vol. 24, no. 12, pp. 21–29, 1999.
[15] A. Singhal and X. Ou, “Security risk analysis analysis
of enterprise networks using probabilistic attack
graphs.” NIST Interagency Report 7788, August 2011.
[16] M. S. Lund, B. Solhaug, and K. Stølen, Model-driven
risk analysis: the CORAS approach. Springer Science
& Business Media, 2010.
[17] International Standardization Organization, “ISO
27000 series: Information technology - security
techniques,” 2009.
[18] International Standardization Organization, “ISO
15408: Information technology - security techniques -
evaluation criteria for IT security (common criteria),”
2009.
[19] International Standardization Organization, “ISO
26262: Road vehicles - functional safety,” 2011.
[20] Commission of the European Communities, “Directive
96/48/EC - Interoperability of the trans-European
high speed rail system,” 1996.
[21] International Electrotechnical Commission, “IEC
62443: Industrial communication networks - network
and system security - security for industrial
automation and control systems,” 2009.
[22] J. Braband, “Towards an IT security framework for
railway automation,” (Toulouse), Feb. 2014.
[23] European Committee for Standardization, “EN 50129,
railway applications - communication, signalling and
processing systems - safety related electronic systems
for signalling,” 2003.
[24] International Electrotechnical Commission, “IEC
61508: Functional safety of electrical / electronic /
programmable electronic safety-related systems,” 2010.
[25] M. Masera, I. N. Fovion, and A. D. Cian, “Integrating
cyber attacks within fault trees,” Reliability
Engineering & System Safety, 2009.
[26] L. PiÃl’tre-CambacÃl’dÃĺs and M. Bouissou,
“Modeling safety and security interdependencies with
bdmp (boolean logic driven markov processes),” in
Systems Man and Cybernetics (SMC), 2010 IEEE
International Conference on, 2010.
[27] W. Young and N. Leveson, “Systems thinking for
safety and security,” in Proceedings of the 29th Annual
Computer Security Applications Conference, pp. 1–8,
ACM, 2013.
[28] Ministry of Defence (United Kingdom), “HAZOP
studies on systems containing programmable
electronics part 2 general application guidance,” May
2000.
[29] I. Studnia, V. Nicomette, E. Alata, Y. Deswarte,
M. KaÃćniche, and Y. Laarouchi, “Survey on security
threats and protection mechanisms in embedded
automotive networks,” in Dependable Systems and
Networks Workshop (DSN-W), 2013 43rd Annual
IEEE/IFIP Conference on, 2013.
[30] K. Koscher, A. Czeskis, F. Roesner, S. Patel,
T. Kohno, S. Checkoway, D. McCoy, B. Kantor,
D. Anderson, H. Shacham, et al., “Experimental
security analysis of a modern automobile,” in 2010
IEEE Symposium on Security and Privacy (SP), 2010.
[31] C. Miller and C. Valasek, “A survey of remote
automotive attack surfaces,” 2014.
[32] S. You, M. Krage, and L. Jalics, “Overview of remote
diagnosis and maintenance for automotive systems,”
tech. rep., SAE Technical Paper, 2005.
[33] H. A. Odat and S. Ganesan, “Firmware over the air
for automotive, fotamotive,” in Electro/Information
Technology (EIT), 2014 IEEE International
Conference on, pp. 130–139, IEEE, 2014.
[34] H.-K. Ryu, S.-R. Cho, S. Piao, and S.-H. Kim, “The
design of remote vehicle management system based on
OMA DM protocol and AUTOSAR s/w architecture,”
pp. 393–397, IEEE, 2008.
[35] D. K. Nilsson, U. E. Larson, F. Picasso, and
E. Jonsson, “A first simulation of attacks in the
automotive network communications protocol
FlexRay,” in Proceedings of the International
Workshop on Computational Intelligence in Security
for Information Systems, CISIS’08, pp. 84–91,
Springer, 2009.
[36] S. Checkoway, D. McCoy, B. Kantor, D. Anderson,
H. Shacham, S. Savage, K. Koscher, A. Czeskis,
F. Roesner, and T. Kohno, “Comprehensive
experimental analyses of automotive attack surfaces,”
in USENIX Security Symposium, 2011.
[37] D. K. Nilsson, L. Sun, and T. Nakajima, “A
framework for self-verification of firmware updates
over the air in vehicle ecus,” in GLOBECOM
Workshops, 2008 IEEE, pp. 1–5, IEEE, 2008.
[38] C. Raspotnig, V. Katta, P. Karpati, and A. L.
Opdahl, “Enhancing chassis: A method for combining
safety and security,” in Availability, Reliability and
Security (ARES), 2013 Eighth International
Conference on, pp. 766–773, IEEE, 2013.
[39] M. S. Idrees, H. Schweppe, Y. Roudier, M. Wolf,
D. Scheuermann, and O. Henniger, “Secure
automotive on-board protocols: a case of over-the-air
firmware updates,” in Communication Technologies for
Vehicles, pp. 224–238, Springer, 2011.
[40] B. Bencsáth, G. Pék, L. Buttyán, and M. Félegyházi,
“Duqu: Analysis, detection, and lessons learned,” in
ACM European Workshop on System Security
(EuroSec), vol. 2012, 2012.
[41] C. Raspotnig, P. Karpati, and K. Vikash, “Guideline
for applying CHASSIS, draft,” Nov. 2012.
[42] M. Broy, I. H. Kruger, A. Pretschner, and
C. Salzmann, “Engineering automotive software,”
Proceedings of the IEEE, vol. 95, no. 2, pp. 356–373,
2007.
[43] S. Plósz, A. Farshad, M. Tauber, C. Lesjak,
T. Ruprechter, and N. Pereira, “Security
vulnerabilities and risks in industrial usage of wireless
communication,” in Emerging Technology and Factory
Automation (ETFA), 2014 IEEE, pp. 1–8, IEEE,
2014.
Figure 9: Excerpt from FMVEA table
Figure 10: Use Case and Misuse Case Development of OTA