Conference PaperPDF Available

Towards Comprehensive Threat Modeling for Vehicles


Abstract and Figures

Over the past few years, significant developmentswere introduced within the vehicular domain. The modernvehicle becomes a network of dozens of embedded systemswhich collaborate together. While these improvements haveincreased functionality of vehicle systems, they have introducednew potential risks. Threat modeling has gained a central role toidentifying the threats that affect different subsystems inside thevehicle. In most cases, threat modeling was implemented eitherfor one subsystem or based on a specific perspective such asthe external threat surfaces only. In this work, we try to revisethe existing threat modeling efforts in the vehicular domain. Wereassemble them and extract their main characteristics to builda comprehensive threat model. This general model could be usedto identify the different threats against the vehicular domain.Furthermore, reusable attack trees could be derived from thisgeneral model.
Content may be subject to copyright.
Towards Comprehensive Threat Modeling for
Mohammad Hamad, Marcus Nolte, Vassilis Prevelakis
Institute of Computer and Network Engineering, TU Braunschweig
Institute of Control Engineering, TU Braunschweig
Abstract—Over the past few years, significant developments
were introduced within the vehicular domain. The modern
vehicle becomes a network of dozens of embedded systems
which collaborate together. While these improvements have
increased functionality of vehicle systems, they have introduced
new potential risks. Threat modeling has gained a central role to
identifying the threats that affect different subsystems inside the
vehicle. In most cases, threat modeling was implemented either
for one subsystem or based on a specific perspective such as
the external threat surfaces only. In this work, we try to revise
the existing threat modeling efforts in the vehicular domain. We
reassemble them and extract their main characteristics to build
a comprehensive threat model. This general model could be used
to identify the different threats against the vehicular domain.
Furthermore, reusable attack trees could be derived from this
general model.
Recently, vehicle manufacturing has changed significantly.
These changes are reflected in the increased use of automotive
embedded systems and the large amount of embedded software
applications which are integrated into each single vehicle. A
modern vehicle may contain up to 100 microcontroller-based
computers, known as electronic control units (ECUs), which
run millions of lines of codes (LOC) [1], [2]. Each ECU relies
on a set of sensors and actuators to serve one or more of the
E/E-systems or -subsystems in a vehicle. Different types of
communication buses (e.g. CAN, FlexRay, etc.) are used to
interconnect the distributed ECUs inside the car. The increase
of connectivity within the vehicles is a double-edged sword.
On the one hand, it extends the vehicle functionalities and
capabilities, but on the other hand, it opens the door for several
cybersecurity threats and makes the vehicle a more attractive
target to adversaries [3].
The safety critical nature of the vehicle requires the adop-
tion of high-security measures when developing vehicular
IT systems. A good understanding of security requirements,
which can be concluded from threat modeling, is a primary
step toward contriving sufficient security countermeasures.
Threat modeling helps to identify and address most of the
potential threats. In fact, threats identification would likely
reduce the life cycle cost of achieving security objectives
when it is considered during the design process. Furthermore,
threat modeling provides relevant information about the attack
vectors which threaten the system. Such data can be used as a
reference during the test process to avoid the omitted threats.
Different researchers scrutinize threat modeling in the vehic-
ular domain. However, most of the researches examine the po-
tential threats only partially. By looking at threats which affect
a particular sub-system, then by creating attack vectors, and by
suggesting appropriate mitigation mechanisms. Practically, the
lack of a general threat model, within the vehicular domain,
makes threats analysis of the different subsystems a resource
consuming task. Additionally, it increases the possibility of
inconsistencies between the interacting subsystems and it
causes redundancy while defining the attack vectors.
In this work, we revise the existing vehicle-related threat
modeling efforts to develop a comprehensive threat model.
We define various potential attackers’ groups, the nature of
the attack, potential targets and security requirements of the
vehicular domain. Then, we propose an abstract model which
can be used to classify all conceivable attacks against the
vehicular domain. The abstract model is used as an aid to
construct general attack trees [4] which illustrate attack vectors
which threaten a particular sub-system of the vehicle.
The rest of the paper is organized as follows: In section II,
we review existing threat models in the vehicular domain and
reassemble them. We propose a general model in section III to
identify possible threats within the vehicle. In Section IV, we
used our general model to identify threats within an automated
obstacle avoidance use-case. Related work is presented in
section V. Finally, we present our conclusion in section VI.
Threat modeling is a systematic approach for describing
and classifying the security threats which affect a system.
Moreover, it provides significant information that would help
to safeguard the target (sub)system against attacks. Effective
defense against threats requires addressing all existing security
flaws in the target system and identifying threats which exploit
these vulnerabilities. In addition, it demands good comprehen-
sion of the prospective attackers, their capabilities, and their
objectives. Therefore, we start exploring threat modeling in the
vehicular domain by defining the potential attackers’ profiles.
A. Attacker profile
Different groups of attackers are attracted to attack vehicles.
These groups vary from the owner of the car to an expert
hacker with sophisticated tools. Each one of these groups
typically has its own motivations:
1) Falsification: An attacker (who could be the owner)
may like to misrepresent actual vehicle information such as
changing the tachograph or odograph measurements to sell
the car with false mileage reading.
2) Illegal profit: An attacker could make profit by stealing
the vehicle or by selling the attack capability to a different
organization. Some attacks could be driven by a commercial
competitor of the target vehicle’s vendor to sabotage their
product and gain share in the market.
3) Insane fun and vandalism: Revenge and vandalism
could motivate some attacks as the case of a dismissed
employee who sought to punish his ex-company by bricking
the sold cars from this company [5].
4) Research and test purposes: Attacks and penetration
tests could be performed by security experts or test teams. The
attackers, in this case, have benign motivations. They try to
discover security flaws in different components of the vehicle
systems before they get exploited by third parties.
5) Accidental: In some circumstances, an attack could
happen without any intention. Such attack could be performed
while upgrading an existing system or by unintentionally
reading malicious data as in the case of the malfunction in the
vehicles GPS, climate control and front console radio systems
in Toyota Lexus vehicles [6].
6) Overlap: Sometimes, multiple motives could stand be-
hind a single attack.
However, motivation alone is not enough. An attacker needs
sufficient technical skills and different sets of equipment
to achieve his targets. The disparity of skills, capabilities,
technical equipment, and financial resources could be used
as indication to classify the attackers into different groups [7]:
1) Unsophisticated attackers (script kiddie): Attackers with
limited financial resources and insignificant knowledge about
the vehicle architecture belong to this group. Such attackers
lack the ability to use complicated tools. Regular thieves,
owners who would like to install or replace a component
within their cars, an attacker who tampers with highway
signals for gaining reputation in their community are good
examples of this group members
2) Hacker: This group includes highly skilled experts who
have adequate tools and equipment to perform the attack. The
members of this group could use their experience to get profit
such as black-hat hackers. Mechanics and security researchers
belong to this group.
3) Organization: These organizations have multiple mem-
bers of the above group who work together. Typically, massive
financial support enables them to obtain the sophisticated tools
and attract experts. Security research groups could be one
sample of this class.
B. Attackable objects
Attackers may focus in different parts of the vehicle com-
ponents such:
1) Data: attackers could target stored data in some ECUs;
this data could be cryptographic private keys, digital certifi-
cates, or private vehicle and driver activities (e.g., vehicle
location, navigation destination, etc.). Or they could threaten
transferred wired/wireless data within the vehicle. This data
a) In-vehicle exchanged data between different compo-
nents and one component and its sensors. Spoofing
the transferred data between the on-board system and
the pressure sensors on the tires is an example of the
vulnerability of such data [8].
b) Transferred data between the vehicle and the external
world; such as V2V communication data, V2I commu-
nication data, etc.
2) In-Vehicle Hardware: Generally, attacking the hardware
infrastructure (i.e., ECUs, sensors, and On-Board Units) re-
quires direct access to the target devices. Attacking In-Vehicle
hardware could occur by replacing a device with a malicious
one, or even installing new hardware which performs mis-
chievously. Sometimes, the attacked hardware may not be a
part of the vehicle. It could be 3rd party devices plugged to the
vehicle, such as driver’s mobile phone [9]. The attacker could
target to degrade the performance of the vehicle’s component
or even lead them to produce misleading results intentionally
(e.g. Volkswagen’s Emissions Scandal [10]) .
3) Surrounding infrastructure: Some attacks could target
the surrounding environment of the vehicle. A typical example
of such an attack is the modifications to the electronic road
signs such as ”Zombies Ahead”, where an attacker figured
out how to alter the text on electronic road signs warning of
Zombies attack. Even such a ridiculous attack could create
public safety issues for the drivers on the roadway [11].
4) Software and framework: The massive amount of the
integrated software on each vehicle and the different levels
of security auditing between the different vendors make them
more susceptible to attacks. The framework which controls the
ECU could be a target for various attacks; some attackers could
tamper with this framework of the ECU to achieve superior
performance [12]. A malicious update of one application or
of internal parts of the framework could open the door for the
attacker to inflict damage to the vehicle.
C. Attack requirements
1) Direct access: Some attacks are based on direct access
to the target vehicle. Direct access could be achieved while a
vehicle is parked. Then, attackers could have a chance to attach
a GPS device to track the vehicle later or target the vehicle’s
immobilizer and electronic locks [13]. In some circumstances,
taking the car to the service station to check it could become
an avenue for direct access from attackers. In such cases,
an attacker has full access to the vehicle, and he could
get the benefit of using existing physical interfaces to have
direct access to the internal network. On-board Diagnostic
port (OBD-II) is one physical interface which was already
employed in many attacks [3].
2) Remote access: Other attacks do not require direct
access to the target vehicle. Attackers could target the vehicle
remotely. Such attacks take advantage of the integrated wire-
less features of modern cars. These features include Bluetooth,
a cellular connection, wireless tire pressure monitoring, etc.
The entertainment system is another point which could be
remotely hacked. Playing a song laced with Malware able to
emit malicious messages to the CAN bus [3].
3) Mixed access: Direct access to the vehicle could be an
introduction to remote attacks. Indeed, some attackers, even
with rapid direct access to the vehicle, could install some
devices inside the vehicle (such as a cover USB, malicious
DVD, malicious component connected via OBD-II port, etc.)
or outside it (communication sniffing devices). Later on, they
could employ those parasitic devices to target the vehicle
remotely. Attackers may use other people to install these
devices, such as a valet who parks the victim’s car, a mechanic
at a service station [3], etc.
D. Attack effects
For this contribution, we classify attacks based on their
1) Limited attack: The ultimate target of some attacks could
be a single part of the vehicle. The effect of such attacks will
stay bounded in the attacked ECU(s) and not propagate any
further. The targeted system will define the jeopardy of the
2) Stepping stone attack: The attack can start by com-
promising one component or subsystem. Later, the attacker
uses this subsystem as an attack surface to plague all related
subsystems. The same process could be repeated for the newly
infected components. Koscher et al. [3] showed that an attacker
who can control one ECU is able to attack other connected
E. Security Requirements
1) Authentication and Integrity: Providing the integrity
within the vehicular systems is comprised of:
Providing data integrity to safeguard against any modifi-
cation of data during a transaction.
Providing message source authentication to enable the
verification of both ends of the communication.
Providing framework and software integrity to ensure the
use of only trusted code and prevent the influence of
Providing hardware integrity to prevent hardware fraud.
2) Privacy and Confidentiality: While providing authenti-
cation for the exchanged messages in the vehicular domain
is vital, providing confidentiality often is less important. For
example, there is no critical reason to encrypt the exchanged
messages between the different ECUs inside the vehicle.
Enforcing confidentiality for the exchanged data should not be
mainly to prevent vehicle identification detection. The ability
to identify the vehicle is feasible already by different mech-
anisms without the need to snoop the exchanged messages
such as (identify vehicle by color, number plate, etc.) The
primary goals should be preventing the leak of the driver’s
critical data (such as driver behavior, previous location) as
well as to guarantee that any observer is not able to efficiently
link different messages coming from the same source. In some
scenarios, confidentiality is required; for example, leaving the
valuable stored information (e.g. private keys) without any
confidentiality protection may leave the whole vehicle security
at stake if an attacker is able to extract this data.
3) Availability: Availability is required particularly for
safety-related applications which are integrated into the vehi-
cle. Such applications should be available even if the vehicle
is under attack.
A. Proposed model
In this section we try to extract the main characteristics of
the reassembled threat model in order to create an abstract
model. This model shall be suitable for adoption by security
experts to identify and classify the majority of threats against
vehicular systems. Such classification could reduce redun-
dancy and inconsistency while applying defense techniques
against homogeneous threats. In addition, it provides the basis
for defining generic attack trees.
The proposed model shown in Fig. 1 uses three layers to
identify and classify threats:
1) Target Domains: A vehicular system contains various
assets (e.g. hardware, software, data, or surrounding infrastruc-
ture). Each asset may include several hidden vulnerabilities.
A motivated attacker could target each of these assets by
generating suitable conditions to exploit one or more of these
vulnerabilities. We use these various assets as the first layer for
identifying the potential threats by defining the flaws within
each asset.
2) Requirements violation: The exploitation of an existing
vulnerability in any asset will lead to a violation in one or more
of the security requirements (i.e. confidentiality, integrity, or
availability). We can further identify and classify the potential
threats based on the violated requirement(s).
3) Accessibility: Eventually, the way of accessing the ve-
hicle (i.e., remote, direct, or mixed access) in order to exploit
a specific vulnerability is used as the last level for compart-
Applying this model to the whole vehicle system will iden-
tify most of the threats. The achievement of each one of these
threats will be used as a root of a general attack tree which
explains how an attacker could be able to exploit a defined
vulnerability. Manipulating data and disabling hardware parts
in the vehicle are examples of such general attack trees.
These trees will turn into distinct ones gradually reflecting
the various studied subsystems. The accomplishment of one
tree could open the door to fulfill other trees as we explained
within the stepping stone attack.
Framework Data Surrounding
infrastructure Hardware
Confidentiality Integrity Availability
Remote Direct Mixed
Threat Threat-a
General Attack Trees
Identified Threats
Fig. 1. General threat model which identifies and classifies threats and links
them to general attack trees
Within the context of a vehicular system, many researchers
used attack trees to illustrate attack vectors which threaten a
particular (sub)system of the vehicle. However, general attack
trees seems to be indispensable for avoiding redundancy and
the interference between the high number of integrated sub-
systems within the vehicle. The general trees will be derived
from threats which were identified by our proposed threat
B. Attack Trees
Threat analysis describes who are the potential assaulters,
what are the motivations behind an attack, and which compo-
nents could be threatened. Describing how an attack could
be executed is the mission of attack trees. An attack tree
is used to explain attacks in a tree structure as shown in
Fig. 2. The root of the tree represents the attacker’s ultimate
goal, while the intermediate nodes of the tree (sub-goals)
define different stages of the attack. In case a node in an
attack tree requires achieving all of its sub-goals, the sub-
goals are combined by an AND branch. In case a node requires
achieving any of its sub-goals, the sub-goals are combined by
an OR branch. Leafs nodes represent atomic attacks. Attack
scenarios are generated from the attack tree by traversing
the tree in a depth-first method [14]. Each attack scenario
will contain the minimum combination of leafs. In classical
attack tree models the attacks’ chronology is disregarded.
However, in many cases, the success of an attack depends
on the subsequent success of interrelated attack steps. Arnold
et al. [15] propose sequential AND- and OR-gates (SAND,
SOR) to handle sequential occurrence of attacks.
C. Review Risk Analysis
Attack trees have been used to evaluate the security risk of
the system and calculate the probability of a successful attack.
This possibility depends on aspects, proposed by ISO/IEC
18045 [16], such as the required time for an attack, the desired
attack tools, etc. However, regarding the risk analysis within
Attack 1Sub-goal 1 Sub-goal 2
Attack 2 Attack 3 Attack 4 Attack 5
Fig. 2. Attack Tree
the vehicular domain, the calculation of the probability of po-
tential attacks based on associating numeric values with each
level of these factors as proposed by ISO/IEC 18045 is not
adequate anymore. Elapsed time, for example, has a different
effect regarding the way of carrying out the attack, whether
it is a remote attack or one with direct access to the vehicle.
Moreover, the overlap between expertise and used tools also
has a different effect; even inexpert attackers could launch
an attack by using sophisticated tools. Eventually, stepping
stone attacks should be considered during the calculation of
probability of an attack. An attack could be unlikely, while
achieving one attack goal in a different subsystem might
increase this possibility.
A. Description
In the CCC project, the Institute of Control Engineering
(ICE) contributes the full-by-wire research vehicle MOBILE
[17] as a demonstrator. MOBILE serves as a platform for
research in the fields of E/E-systems and vehicle dynamics.
It features four close-to-wheel electric drives (4x100 kW), as
well as individually steerable wheels, and electro-mechanic
brakes [17]. The vehicle features a FlexRay communication
backbone for inter-ECU-communication and additional CAN
bus interfaces, which are used for communication with vehicle
sensors and actuators. The ECUs responsible for vehicle con-
trol are programmed in a custom-designed MATLAB/Simulink
tool chain. Combined with detailed vehicle dynamics mod-
els, the tool chain serves as a means to establish a rapid-
prototyping process for vehicle control algorithms.
Within the scope of the project, a use case in the form
of automated obstacle avoidance will be implemented in the
(Smart) Sensors
(Smart) Actuators
Control Units / PCs
Sensor 1
Sensor n
Actuator n
Actuator 1
Control Localization Env.
Fig. 3. hardware architecture for obstacle avoidance use-case
experimental vehicle MOBILE. The basis for this use-case is
a trajectory following stability control system. In general, sta-
bility control systems only steer the vehicle into the direction
given by driver input at the steering wheel angle. However, as
the driver does not always perform safe steering maneuvers,
particularly in critical driving situations, such as fast obstacle
avoidance, this extended stability control will follow a safe
pre-planned trajectory instead of following a potentially unsafe
path, steered by the driver.
The research vehicle is equipped with a variety of environ-
ment sensors to perceive the static and the dynamic vehicle
environment. Three lidar scanners, a radar sensor and a camera
monitor the environment around the car. This data will be used
to create a map of the static environment, which provides
the basis for a model-based trajectory planning utilizing all
actuators (particularly all-wheel steering) for maximal maneu-
A hardware architecture showing the perception system, as
well as a simplified network for vehicle control is depicted in
figure 3. With regard to environment perception, the required
actions will be performed in a distributed system of three
nodes. GPS and inertial data is fed via CAN to a node which
is responsible for vehicle localization and motion estimation.
Lidar sensors and a camera are streamed via UDP to a node
responsible for environment perception (sensor data process-
ing, data fusion, environment modeling). Data from a radar
sensor is aquired via a CAN bus connection.
Trajectory planning will be performed on the ”Vehicle
Control” node, utilizing aggregated data from vehicle and
environment sensors. The planned trajectory is then converted
to reference values for the six vehicle control ECUs (three
main control units, three hot stand-by nodes), which are
connected with the already mentioned FlexRay backbone.
As the research vehicle is not permitted to drive in public
traffic, the use-case will be verified and validated on a closed
testing ground only. However, the sensor setup and sensor data
processing architecture is very similar to the research vehicle
Leonie [18], also built and maintained by the ICE, so that at
least parts of the identified attack vectors could be transferred
to a vehicle with a driving permit for public roads.
oDisabling a hardware (availability) (OR)
Disabling Camera
blinding the camera (SAND)
placing LED device
emitting a strong light to the camera
Disabling sensor or ECUS (OR)
transmitting electromagnetic pluse (EMP)
Crashing the framework of ECU
Disabling LIDAR (OR)
Jamming LIDAR
Physical damage
Disabling Radar
Jamming attack
oConfusing the proper function of a component (integrity) (OR)
Confusing GPS
Generating fake GPS signal
Confusing LIDAR (OR)
spoofing signal
replay attack
Relaying the signal attack
absorbing the signal
Confusing Radar (OR)
Replaying signal attack
Using undetactable obstecale
Confusing Camera (OR)
Disabling surrounding environment
Confusing the auto controls
Manipulating surrounding environment
Fig. 4. general attack tree for the hardware components in our use-case
B. Threat modeling for the use-case
We used our model to identify the potential threats within
the automated obstacle avoidance use-case. We started our
investigation by defining all components which could include
vulnerabilities, and identify the security requirement that could
be violated in the case of exploiting these vulnerabilities.
Lidar, Camera, Radar, and GPS are possible attack surfaces in
our use-case. We tried to construct attack trees for each one
of them, as shown in figure 4; these trees are derived from
the general ones (i.e., disabling a hardware and confusing the
proper function of a component). Detailed explanation about
attacking the camera and lidar in the vehicle can be found in
The manipulation of the surrounding infrastructures has
a direct effect on the functionality of different components
in our use-case (such as the Camera). Figure 5 illustrate a
general attack tree for the surrounding environment which
affect our use-case’s components. On the other hand, crashing
the framework of an ECU will lead to preventing the ECU
from doing its function and disable it, even, temporarily.
Threat analysis of modern vehicles has remained a hot topic,
and will continue. As modern vehicle architecture is getting
more complex, the potential threats are increasing too. Various
researchers have tried to point out the vulnerabilities within the
vehicular system based on different perspectives; Checkoway
et al. [20] looked at potential attack surfaces which could be
exploited by attackers externally. On the other hand, Koscher
et al. [3] studied the attack surfaces on the underlying system
structure. They demonstrated that attackers could leverage
oManipulating surrounding environment (OR)
Road-related attacks (OR)
installing fake signs
Installing fake speed signs
Installing fake announcement signs
Placing harmful devices (e.g. IR LED)
oDisabling surrounding environment (OR)
Removing road sign
Disabling speed sign (OR)
Removing the sign
Distorting the sign
Fig. 5. general attack tree for surrounding infrastructure in our use-case
direct access to the CAN bus to control various functions
adversarially. Petit and Shladover, in [21], investigated cy-
berattacks for the automated and connected vehicle. Attack
trees have been used as a tool to illustrate the attack steps
for individual attack scenarios within the vehicular system
[9]. Aijaz et al. [22] tried to create a reusable attack tree for
V2V communication threats. In our work, we try to provide
an abstract model which helps creating a general attack tree
for the whole vehicular domain.
Many threat model schemes, such as STRIDE [23] and SDL
[24], are used to characterize cybersecurity threats in different
environments. However, McCarthy et at. [25] claimed that
these models may not be fully applicable in the automotive
cybersecurity analysis. Therefore, they proposed the use of a
threat model which is a hybrid of various models. We went
in the same direction by adopting an existing model (i.e. the
Confidentiality, Integrity, and Availability (CIA) information
security model) in our approach.
In this work, we created a comprehensive threat model
based on the existing vehicle-related threat modeling efforts.
Our model classifies and identifies the threats based on target
assets, the violated security requirements, and the accessibility
of the threats. General attack trees can be linked to each
of the identified threats. We explored the automated obstacle
avoidance use-case while trying to classify the potential threats
against it, based on our model. Future work will define
mitigation mechanisms based on this model.
This work was supported by the DFG Research Unit
Controlling Concurrent Change (CCC), funding number
FOR 1800. We thank the members of CCC for their support.
We thank Mischa M¨
ostl for his helpful discussions, and
Marinos Tsantekidis for his comments that improved the
[1] M. Broy, I. Kr¨
uger, A. Pretschner, and C. Salzmann, “Engineering
Automotive Software,Proceedings of the IEEE, vol. 95, no. 2, 2007.
[2] R. Charette, “This car runs on code,” feb 2009. [Online]. Available:
[3] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway,
D. McCoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage, “Ex-
perimental security analysis of a modern automobile,” in Proceedings
of the 2010 IEEE Symposium on Security and Privacy, ser. SP ’10.
Washington, DC, USA: IEEE Computer Society, 2010, pp. 447–462.
[4] B. Schneier, “Attack Trees - Modeling security threats,Dr. Dobb’s
Journal, Dezember 1999.
[5] K. Poulsen, “Hacker disables more than 100 cars remotely,” Mar 2010.
[Online]. Available:
[6] J. Bogage, “Scary glitch affects luxury cars,” JUN 2016.
[Online]. Available:
scary-glitch- affects-luxury-cars/kj4wg2lhphlJDC3gATGuPM/story.html
[7] A. G. Camek, C. Buckl, and A. Knoll, “Future cars: Necessity for
an adaptive and distributed multiple independent levels of security
architecture,” in Proceedings of the 2Nd ACM International Conference
on High Confidence Networked Systems, ser. HiCoNS ’13, 2013.
[8] I. Rouf, R. Miller, H. Mustafa, T. Taylor, S. Oh, W. Xu, M. Gruteser,
W. Trappe, and I. Seskar, “Security and privacy vulnerabilities of in-car
wireless networks: A tire pressure monitoring system case study,” in
Proceedings of the 19th USENIX Conference on Security, ser. USENIX
Security’10. Berkeley, CA, USA: USENIX Association, 2010.
[9] V. Izosimov, A. Asvestopoulos, O. Blomkvist, and M. T¨
“Security-aware development of cyber-physical systems illustrated with
automotive case study,” in 2016 Design, Automation & Test in Europe
Conference & Exhibition, DATE 2016, Dresden, Germany, 2016.
[10] G. Guilbert, E. Jack, R. Karl, and W. Deerek, “Explaining
volkswagens emissions scandal,” July 2016. [Online]. Avail-
vw-diesel- emissions-scandal- explained.html
[11] J. Olofsson, “zombies ahead!a study of how hacked digital road signs
destabilize the physical space of roadways,” Visual Communication,
vol. 13, no. 1, pp. 75–93, 2014.
[12] A. Wasicek and W. Andre, “Recognizing manipulated electronic control
units,” in SAE 2015 World Congress & Exhibition, April 2015.
[13] R. Verdult, F. D. Garcia, and B. Ege, “Dismantling megamos crypto:
Wirelessly lockpicking a vehicle immobilizer,” in Supplement to the
22nd USENIX Security Symposium (USENIX Security 13), 2015.
[14] A. Moore, R. Ellison, and R. Linger, “Attack modeling for information
security and survivability,” Software Engineering Institute, Carnegie
Mellon University, Tech. Rep. CMU/SEI-2001-TN-001, 2001.
[15] F. Arnold, D. Guck, R. Kumar, and M. Stoelinga, “Sequential and
parallel attack tree modelling,” in International Conference on Computer
Safety, Reliability, and Security. Springer, 2015, pp. 291–299.
[16] “Information technology–security techniques–methodology for it secu-
rity evaluation,” International Standard ISO/IEC 18045, Standard, 2000.
[17] P. Bergmiller, “Towards Functional Safety in Drive-by-Wire Vehicles,”
Ph.D. dissertation, Technische Universit¨
at Braunschweig, 2014.
[18] J. Rieken, R. Matthaei, and M. Maurer, “Toward Perception-Driven
Urban Environment Modeling for Automated Road Vehicles,” in 2015
IEEE 18th International Conference on Intelligent Transportation Sys-
tems, Sep 2015, pp. 731–738.
[19] J. Petit, B. Stottelaar, M. Feiri, and F. Kargl, “Remote attacks on
automated vehicles sensors: Experiments on camera and lidar,” in Black
Hat Europe, 11/2015 2015.
[20] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Sav-
age, K. Koscher, A. Czeskis, F. Roesner, and T. Kohno, “Comprehensive
experimental analyses of automotive attack surfaces,” in Proceedings
of the 20th USENIX Conference on Security. Berkeley, CA, USA:
USENIX Association, 2011.
[21] J. Petit and S. E. Shladover, “Potential cyberattacks on automated
vehicles,” IEEE Transactions on Intelligent Transportation Systems,
vol. 16, no. 2, pp. 546–556, 2015.
[22] A. Aijaz, B. Bochow, F. D¨
otzer, A. Festag, M. Gerlach, R. Kroh,
and T. Leinm¨
uller, “Attacks on inter vehicle communication systems-an
analysis,” in 3rd International Workshop on Intelligent Transportation
(WIT 2006).
[23] Microsoft Developer Networks, “The STRIDE threat model.” [Online].
[24] ——, “Microsoft security development lifecycle SDL.” [Online].
Available: ttp://
[25] C. McCarthy, K. Harnett, and A. Carter, “Characterization of poten-
tial security threats in modern automobiles: A composite modeling
approach,” Tech. Rep., 2014.
... Within our previous work [18], we were among the first authors to attempt to concentrate on the attacker-centric method for the automotive domain by classifying attackers against the vehicular system and trying to define their different goals. Other efforts also followed the same strategy and included the attacker in their threat model, such as [19,20]. ...
... We will use the PAND gate in this paper whenever we need to show the order of attacks in our attack trees ( Figure 1 shows two sub-attacks (AT4 and AT5) which are used as inputs for PAND gate). Attack trees have been used as a tool to illustrate the attack steps for individual attack scenarios, to assess the risk of these attacks which could target the modern vehicle [18,[38][39][40], or to support the planning of intrusion response system within the vehicular systems [41]. E-Safety Vehicle Intrusion Protected Applications (EVITA) proposed a method called threat and operability analysis (THROP). ...
Full-text available
In recent years, significant developments were introduced within the vehicular domain, evolving the vehicles to become a network of many embedded systems which depend on a set of sensors to interact with each other and with the surrounding environment. While these improvements have increased the safety and incontestability of the automotive system, they have opened the door for new potential security threats which need to be defined, assessed, and mitigated. The SAE J3061 standard has defined threat modeling as a critical step toward the secure development process for vehicle systems, but it did not determine which method could be used to achieve this process. Therefore, many threat modeling approaches were adopted. However, using one individual approach will not identify all the threats which could target the system, and may lead to insufficient mitigation mechanisms. Thus, having complete security requires the usage of a comprehensive threat model which identifies all the potential threats and vulnerabilities. In this work, we tried to revise the existing threat modeling efforts in the vehicular domain. Also, we proposed using a hybrid method called the Software, Asset, Vulnerability, Threat, and Attacker (SAVTA)-centric method to support security analysis for vehicular systems. SAVTA combines different existing threat modeling approaches to create a comprehensive and hybridized threat model. The model is used as an aid to construct general attack trees which illustrate attack vectors that threaten a particular vehicle asset and classify these attacks under different sub-trees.
... In this paper, we specifically focus on the proper and due consideration of the security aspect within the safety engineering life cycle, which is one particu- 30 larly urgent problem related to the aforementioned challenge. Consequently, we propose a systematic pattern-based and ISO 26262-oriented approach for safety and security co-engineering in the automotive domain. ...
... For security ISO/SAE 21434 [6] is still in development and SAE J3061 was pushed back to work in progress. We use threat modeling as a well established security analysis method for the automotive domain [28], [29], [30]. In order to support a consistent engineering workflow we utilize a threat modeling add-in 455 for Enterprise Architect (EA) [31] 12 . ...
Automotive systems will exhibit increased levels of automation as well as ever tighter integration with other vehicles, traffic infrastructure, and cloud services. From safety perspective, this can be perceived as boon or bane - it greatly increases complexity and uncertainty, but at the same time opens up new opportunities for realizing innovative safety functions. Moreover, cybersecurity becomes important as additional concern because attacks are now much more likely and severe. However, there is a lack of experience with security concerns in context of safety engineering in general and in automotive safety departments in particular. To address this problem, we propose a systematic pattern-based approach that interlinks safety and security patterns and provides guidance with respect to selection and combination of both types of patterns in context of system engineering. A combined safety and security pattern engineering workflow is proposed to provide systematic guidance to support non-expert engineers based on best practices. The application of the approach is shown and demonstrated by an automotive case study and different use case scenarios.
... The increasing of connectivity in a vehicle improves the functionality, capability and the utility of the vehicle. On the other hand, however, this may cause more cyber-security threats and the vehicles will be more vulnerable to attacks from adversaries [5]. ...
... The multiple kind of attackers in V2X system has own motivation, some of them are mentioned in the following [5]: ...
Full-text available
In the environment of self-driving vehicles, enabling a vehicle to communicate with surrounding infrastructure (V2I) and other vehicles (V2V) increases transportation efficiency and vehicle safety. Using only the vehicle sensors to perceive the environment is however not sufficient. To enable V2V and V2I, many concerns have to be under consideration, principally, safety, security, reliability, etc. Safety and security are the main concern of this thesis. An efficient authentication mechanism between vehicles and surrounding infrastructures is a requirement for ensuring safe and secure V2X communication. Such efficient authentication mechanism should satisfy certain properties like 1) in-field management (at running time), 2) lightweight protocols, 3) scalable management. In this thesis, a perusal of the state-of-the-art of proposed solutions is presented where the insufficiency in the state of the art will be uncovered. Since the lack of proper authentication mechanism gives rise to most of the security issues in V2X communication, this work aims to propose an authentication mechanism that combines two solutions in hand, namely the Secure Hardware Module (HSM) and the Secret Unknown Cipher (SUC). SUC will be used as an ID of the vehicle. Such an ID is a clone-resistance and non-replicable ID, which eliminate security attacks e.g. replication attack or Sybil attack. The needed protocols for V2X communication, which take the features of the SUC, are defined in this work. Since authenticity is a cornerstone of any trust management system, our proposed authentication mechanism could be considered as a step toward establishing an efficient trust management module in the vehicle domain.
... In 2016, Zhendong Ma et al. [33] proposed a practical approach to conduct threat modeling for automotive security analysis during the development lifecycle, but it did not explain how to model and analyze the threat items of in-vehicle systems. Mohammad et al. [34] tried to revise the existing threat modeling efforts in the vehicular domain with only four categories of attack objective, which lacked fine-granularity for complex in-vehicle threat analysis. In 2017, Karahasanovic et al. [35] demonstrated that the threat VOLUME 4, 2016 modeling process in the computer industry can be adapted and applied in the automotive industry. ...
Full-text available
Modern vehicles are equipped with more than 100 Electrical Control Units (ECUs) with over 2500 signals to transmit internally. The application of advanced electronics and communication techniques helps a vehicle transform from an information island into a powerful distribution center. However, a large number of ECUs have introduced a wider range of security threats for vehicles. The attackers can compromise a vehicle remotely through a vulnerable ECU. How to evaluate the cyber security of in-vehicle ECUs has become an important issue. Current Threat Analysis and Risk Assessment (TARA) only carries out theoretical analysis on the potential threats and risks faced by the vehicle in the conceptual design phase of the lifecycle, but lacks the details of actual security evaluation. In this paper, we proposed a Cyber Security Evaluation Framework (CSEF) to independently evaluate the security of the in-vehicle ECUs, which is composed of the asset identification, the threat analysis, the risk assessment, and the security test. The proposed CSEF is applied to a pre-installed On-Bord Unit (OBU) to provide a use case. The use case show that the proposed CSEF is able to figure out assets, threats, risks behind threats, and vulnerabilities of OBU, playing an important role in guiding others to conduct security evaluation. Moreover, CSEF can be extended to evaluate the cyber security of other critical ECUs, such as the Telematic Box, the infotainment units, and the gateway.
... The attack tree is created off-line for each system asset (e.g. hardware, software, data) [17]. Then, the defined attack trees are used to evaluate the security risks, to calculate the probability of a successful attack and to measure the defense (local response) cost [10]. ...
Recently, significant developments were introduced within the vehicular domain, making the modern vehicle a network of a multitude of embedded systems communicating with each other, while adhering to safety-critical and secure systems specifications. Many technologies have been integrated within modern vehicles to give them the capability to interact with the outside world. These advances have significantly enlarged the attack surface. We already have numerous instances of successful penetration of vehicular networks both from inside the vehicle and from the outside. To face these attacks, many intrusion prevention and detection mechanisms were implemented inside a vehicular system. Nonetheless, even if all security mitigation is adopted, an attack still can happen. In critical-safety environments, such as the vehicle, the response to the attack is as essential as detecting the attack itself. Although Intrusion Response Systems (IRSs) have been adopted in other domains to add an extra layer of security, there is a lack of such systems in the vehicular field. In this work, we investigate the challenges and identify the requirements for integrating such a mechanism within the vehicle system. Besides, we present an IRS framework, which meets the identified requirements. Also, we discuss the integration of IRS through the vehicle system development and the different aspects which support such a process. Finally, we use the automated obstacle avoidance system to explain how we could develop intrusion response strategies and to measure the overhead of such security system.
... Regarding security, the platform should thus ensure the integration of new components without putting the vehicle at a risk of violating the system requirements or creating a vulnerability regarding communication and access control rules. We propose an integration procedure, as shown in Figure 5. 5. ...
Full-text available
In recent years, significant developments were introduced within the vehicular domain, evolving the vehicles to become a network of many embedded systems distributed throughout the car, known as Electronic Control Units (ECUs). Each one of these ECUs runs a number of software components that collaborate with each other to perform various vehicle functions. Modern vehicles are also equipped with wireless communication technologies, such as WiFi, Bluetooth, and so on, giving them the capability to interact with other vehicles and roadside infrastructure. While these improvements have increased the safety of the automotive system, they have vastly expanded the attack surface of the vehicle and opened the door for new potential security risks. The situation is made worse by a lack of security mechanisms in the vehicular system, which allows the escalation of a compromise in one of the non-critical subsystems to threaten the safety of the entire vehicle and its passengers. This dissertation focuses on providing a comprehensive framework that ensures the security of the vehicular system during its whole life-cycle. This framework aims to prevent cyber-attacks against different components by ensuring secure communications among them. Furthermore, it aims to detect attacks that were not prevented successfully, and finally, to respond to these attacks properly to ensure a high degree of safety and stability of the system. The thesis starts by developing a hybrid threat model that combines multiple existing threat modeling approaches to define a more comprehensive one. This model defines (1) the various potential groups of attackers, which may threaten the vehicular system and their capabilities, (2) the potential targets (i.e., assets) of these groups and the various vulnerabilities that they include, and (3) the security requirements for these targets which should be considered to prevent the attacker from compromising them. After defining the security requirements by using the proposed threat model, the thesis addresses the challenges of developing the security policy, which implements these requirements. The thesis presents a methodology supporting the gradual definition of the security policy. Under our methodology, the designer of each software component is responsible for formulating the security policy of their components. As components get integrated into larger subsystems, the individual policies are merged into the subsystem policy. This continues as we go up the ladder of bigger subsystems until we have a complete vehicle. The thesis also shows how to enforce the developed security policy in an efficient manner by using a lightweight distributed access framework implemented within each single ECU. The enforcement takes place at the network level, enforcing communications only between authorized components while employing data integrity mechanisms in the communication between components, even if they run on different ECUs. In this way, we provide a level of compartmentalization in the in-vehicle network. With this precondition, a malicious application might remain able to emit (a) malicious packet(s) to its remote peer(s), if it is authorized. But, at the same time, this application can be prevented from attacking other components, which it is not authorized to communicate with. A heavy-handed security policy may adversely impact availability. Taken to the extreme, a secure system is a silent system that does not interact with its environment, and this is clearly not the intent of a security policy aimed at a vehicular platform. So we face the conundrum of increased security, leading to false positives affecting availability and overall performance against a more permissive system that may fail to detect attacks (false negatives), leading to the demise of the platform. The thesis addresses this issue by using the Red-Zone principle, whereby a tighter inner security envelope alerts the security system of a potential compromise before an actual security violation occurs. In this way, we can observe the suspect component as it operates within the Red-Zone, and characterize the event. We leverage the Red-zone principle in order to develop a run-time mechanism to detect the incidence of an attack and to prevent the attackers from gaining a foothold. The thesis defines temporal specifications for each hard real-time software component within the vehicle to be used as a baseline to define its nominal behavior. Attacks such as code injection, or Denial of Service (DoS) will usually cause a breach of this temporal specification, and thus will be detected. Once a software component is found to have violated its security boundaries, the system needs to take some remedial action. The type of response, e.g., taking the component offline, restarting the component, initiating containment measures (e.g., resetting the entire ECU), and so on, are the responsibility of the Intrusion Response System (IRS). This thesis uses the Red-Zone principle as the basis for developing an IRS framework to manage the interaction between security and safety of the system.
... Even though these different sets may be securely developed individually, integrating them in the same system could end up leaving the system in a non-secure state. For example, in a vehicular system, an attacker can get benefits from the heterogeneity at the security level of the different ECUs by launching a stepping stone attack on the whole system [11]. Attackers start compromising the weak components or subsystems and use them as an attack surface to plague all related subsystems. ...
... However, the enormous growth of vehicle functionalities, capabilities and connectivity was accompanied by new security vulnerabilities which expanded the vehicle's attack surface and made it a very attractive target to adversaries (Koscher et al., 2010;Checkoway et al., 2011;Hamad et al., 2016a). Attackers were able to exploit these vulnerabilities mounting serious attacks without the need of physical access to the vehicle (Ishtiaq Roufa et al., 2011). ...
Conference Paper
Modern vehicles are increasingly equipped with highly automated control systems both for driving and for passenger comfort. An integral part of these systems are the communication channels that allow the on-board systems to interact with passenger devices (e.g. tablets), ITS systems (e.g. roadside units), and other vehicles. These advances have significantly enlarged the attack surface and we already have numerous instances of successful penetration of vehicular networks both from inside the vehicle and from the outside. Traditional mechanisms for detecting and responding to such attacks are ill-suited to the vehicular domain mainly due to the fact that the entire process of dealing with an attack must be handled automatically and in a way that does not affect safety or severely impacts the continued availability of the vehicle or its key systems. Once a security breach is suspected, the system must evaluate the circumstances in order to determine whether the threat is real (and not a false positive) and select the optimal response through the use of an Intrusion Response System (IRS). Although IRSs have been adopted in other domains, there is a lack of such systems in the vehicular field. In this paper, we investigate the challenges and requirements for integrating such a mechanism inside a vehicle. In addition, we present an Intrusion Response System based on the Red-Zone principle which meets the identified requirements. Finally, we discuss the integration of IRS through the vehicle system development and the different aspects which support such a process.
This chapter examines the cybersecurity and privacy of the twin notions of smart transportation and intelligent transportation systems with a focus on the role of personal automobiles. Smart transportation encompasses the individual and joint capabilities of connected cars, or more generally vehicles, and so comprises the internal workings of autonomous vehicles and the complex interdependencies introduced by vehicle-to-vehicle (V2V) communications. An intelligent transportation system introduces smart technology to civil transportation infrastructure, and the connected car further creates the opportunity for vehicle-to-infrastructure (V2I) communications. We identify threats and attacks enabled by smart transportation and intelligent transportation systems, and survey methods for providing security and privacy.
Conference Paper
Full-text available
The intricacy of socio-technical systems requires a careful planning and utilisation of security resources to ensure uninterrupted, secure and reliable services. Even though many studies have been conducted to understand and model the behaviour of a potential attacker, the detection of crucial security vulnerabilities in such a system still provides a substantial challenge for security engineers. The success of a sophisticated attack crucially depends on two factors: the resources and time available to the attacker; and the stepwise execution of interrelated attack steps. This paper presents an extension of dynamic attack tree models by using both, the sequential and parallel behaviour of AND and OR-gates. Thereby we take great care to allow the modelling of any kind of temporal and stochastic dependencies which might occur in the model. We demonstrate the applicability on several case studies.
Conference Paper
Full-text available
Combatting the modification of automotive control systems is a current and future challenge for OEMs and suppliers. 'Chip-tuning' is a manifestation of manipulation of a vehicle's original setup and calibration. With the increase in automotive functions implemented in software and corresponding business models, chip tuning will become a major concern. Recognizing tuned control units in a vehicle is required to report that circumstance for technical as well as legal reasons. This work approaches the problem by capturing the behavior of relevant control units within a machine learning system called a recognition module. The recognition module continuously monitors vehicle's sensor data. It comprises a set of classifiers that have been trained on the intended behavior of a control unit before the vehicle is delivered. When the vehicle is on the road, the recognition module uses the classifier together with current data to ascertain that the behavior of the vehicle is as intended. A proof-of-concept implementation uses the TORCS racing simulator to generate traces of the engine's behavior. The recognition module extracts features from these traces and feeds them to an artificial neural network (ANN). After training on different tracks, the ANN successfully distinguishes traces originating from the original racing car as well as traces taken from modified racing cars. The results show that assessing a vehicle's behavior is feasible and contributes to protect its integrity against modifications. Additionally, the availability of a vehicle's behavioral model can trigger even more interesting applications.
Full-text available
Vehicle automation has been one of the fundamental applications within the field of intelligent transportation systems (ITS) since the start of ITS research in the mid-1980s. For most of this time, it has been generally viewed as a futuristic concept that is not close to being ready for deployment. However, recent development of “self-driving” cars and the announcement by car manufacturers of their deployment by 2020 show that this is becoming a reality. The ITS industry has already been focusing much of its attention on the concepts of “connected vehicles” (United States) or “cooperative ITS” (Europe). These concepts are based on communication of data among vehicles (V2V) and/or between vehicles and the infrastructure (V2I/I2V) to provide the information needed to implement ITS applications. The separate threads of automated vehicles and cooperative ITS have not yet been thoroughly woven together, but this will be a necessary step in the near future because the cooperative exchange of data will provide vital inputs to improve the performance and safety of the automation systems. Thus, it is important to start thinking about the cybersecurity implications of cooperative automated vehicle systems. In this paper, we investigate the potential cyberattacks specific to automated vehicles, with their special needs and vulnerabilities. We analyze the threats on autonomous automated vehicles and cooperative automated vehicles. This analysis shows the need for considerably more redundancy than many have been expecting. We also raise awareness to generate discussion about these threats at this early stage in the development of vehicle automation systems.
Conference Paper
Automated driving is a widely discussed topic nowadays. Impressive demonstrations have shown the potentials of vehicle automation. However, many projects in the context of automated driving use a priori data in order to compensate insufficiencies in perceiving and understanding the vehicle's environment. Additionally, in terms of functional safety and redundancy, it is not yet known whether such localization-and map-based approaches are really path breaking. This is the reason why we focus on on-board perception also of the stationary urban environment. While object tracking is a commonly used approach, the combination of grid-based and object-based representations for environment perception is still a research topic. The sufficient perception of lanes and drivable areas is an unsolved issue in urban environment. Several perception modules have to collaborate for a suitable representation of the vehicles' surroundings. In this paper, we present the latest contributions of the project Stadtpilot to a perception-driven modeling of urban environments. We propose a lane detection approach which is based on a grid-based representation of different environmental features. Our approach is able to detect multi-lane structures and it is capable to deal with complex lane structures which are typical of urban roads. The extracted features are stabilized by a tracking module. Additionally, we incorporate a free-space representation which data is not derived implicitly from detected targets, but based on an explicit ground representation. Extensions of our dynamic classification module focus on the start/stop behavior of other road users in order to enhance the completeness of track list (mobile objects) and grid (stationary environment). The presented algorithms run in real-time on a standard PC and are evaluated with real sensor data.
This book presents approaches to address key challenges based on a vehicle level view and with a special emphasis on Drive-by-Wire systems. The design and testing of modern vehicle electronics are becoming more and more demanding due to increasing interdependencies among components and the safety criticality of tasks. The development towards Drive-by-Wire functionalities in vehicles with multiple actuators for vehicle control further increases the challenge. The book explicitly takes into account the interactions between components and aims at bridging the gap between the need to generate additional customer benefits and the effort to achieve functional safety. The book follows a twofold approach: on the one side, it presents a toolchain to support efficient further development of novel functionalities for Drive-by-Wire vehicles. The toolchain comprises appropriate software tools and scaled and full-scale experimental vehicles. On the other side, development towards functionally safe and flexible Drive-by-Wire vehicles is addressed by proposing a top-down designed architecture for vehicle electronics that is enabled by suitable mechanisms. The resulting goal achievement with regard to functional safety is evaluated based on a novel hierarchical approach.
This article explores some of the ways in which hacked Changeable Message Signs (CMSs) destabilize the physical space of motor transport spaces and jeopardize the institutionalized function of travel. While CMSs draw attention to the correlation between motorists' current positions, possible inconveniences ahead and their final destination, hacked CMSs and the subsequent projection of unsanctioned messages destabilize this correlation. Hence, the seemingly straightforward relationship between motor transport spaces and the activities of motorists, pedestrians and passers-by is in fact fashioned by the particular kind of message that is displayed at any given moment. Focusing on the spatial effects of hacked CMSs and how the dissemination of unsanctioned information points to the social stratifications of motor transport spaces, hacking is understood as a means of combating the disciplinary regimes of roadways.
Conference Paper
Current automotive systems contain security solutions provided as singular solutions. Security mechanisms are implemented for each automotive function individually. This individual security design leads to several problems: combining several functions that are for its own secure may not result in a secure system. Furthermore, the combination of functions might also lead to situations, where mechanisms erroneously detect a security threat. This paper argues that new features, such as Car-2-Car communication or autonomous driving, will result in new information and communication technology (ICT) architectures of cars. The paper will outline basic properties of this architecture and summarize resulting security threads. We will argue that security needs to be treated in a holistic way and that the design must be suitable for adaptive, multiple independent levels of security (MILS) architecture.