ChapterPDF Available

Abstract and Figures

In recent years, several publications have shown that vehicles are hardly protected against security attacks. For this reason, the development of security concepts has moved into the focus of car manufacturers. The reuse of already known attacks plays a major role in this context. While the collection of known attacks in public databases for information technology is well established the automotive domain is still at the beginning of this process. In this paper, we want to show how such a vulnerability database can support security development in the automotive sector and how it can be used in individual development phases.
Content may be subject to copyright.
Enhancement of Cyber Security for Cyber Physical
Systems in the Automotive Field Through
Attack Analysis
Robin Bolz, Marcel Rumez, Florian Sommer, Jürgen Dürrwang, and Reiner Kriesten
Institute of Energy Efficient Mobility
Karlsruhe University of Applied Sciences
Karlsruhe, Germany
Email: {boro0001, ruma0003, sofl0001, duju0001, krre0001}
Abstract—In recent years, several publications have shown
that vehicles are hardly protected against security attacks. For
this reason, the development of security concepts has moved into
the focus of car manufacturers. The reuse of already known
attacks plays a major role in this context. While the collection of
known attacks in public databases for information technology is
well established the automotive domain is still at the beginning
of this process. In this paper, we want to show how such a
vulnerability database can support security development in the
automotive sector and how it can be used in individual
development phases.
Keywords—Automotive Security; Attack Analysis; Attack
Vehicles used to be largely self-contained systems, but in
recent years they have developed into highly connected units
which communicate with the environment to exchange control
and entertainment data. The steadily growing number of
electronic components as well as the introduction of different
(especially wireless) communication technologies have led to
a large surface for security attacks which can potentially be
exploited by an attacker. As a result, various attacks on
vehicles have been published in recent years. The work of
Koscher et al. [1] should be mentioned in the first place. The
researchers were able to manipulate various functions such as
exterior lighting, horn, windscreen wipers or door locking by
connecting to a vehicle's internal network. It was also possible
to manipulate driving physics components such as engine,
brakes and steering, which is critical with regard to the safety
of vehicle occupants. Furthermore, Checkoway et al. [2]
investigated wireless interfaces among other components.
Vulnerabilities in Bluetooth and cellular communication were
found and exploited, for example. In 2015, the researchers
Charlie Miller and Chris Valasek [3] were able to remotely
control a Jeep Cherokee and attracted great attention. This
attack was subject of various media reports. In a nutshell, local
in-vehicle communication systems were used to activate
components such as window regulators or displays. Beyond
this, vulnerabilities were found where the researchers
succeeded in accessing the vehicle's internal network via
external communication interfaces. As a result, numerous
other publications were released in the following years, in
which vehicles or their components were compromised.
Furthermore, there are various works which deal with
investigating recognition and detection systems in vehicles.
Petit et al. [4] were able to attack camera and LiDAR (Light
Imaging Detection and Ranging) systems and trigger
malfunctions. In other work, researchers were able to
manipulate traffic sign recognition algorithms. Such attacks
are particularly relevant for autonomous vehicles, which are
currently in development by several vehicle manufacturers.
This also includes attacks which influence driving physics
components, as this can possibly endanger vehicle occupants
and road traffic.
In order to reduce the risk of security attacks on vehicles,
the development of security concepts by vehicle
manufacturers and suppliers is currently a high priority. The
main goal is to develop security measures, which protect
against attacks. Since there have been hardly any established
security processes or standards in the automotive sector up to
now, SAE J3061 [5] was developed as one of the first
guidelines to support the development of such concepts and
measures. Individual security development phases were
embedded in the V-Model, which is established as a
development process in the automotive sector. When creating
a security concept for a new vehicle, the main focus is on
estimating the risk of attacks in order to derive possible
security mechanisms. At this point, it is possible to reuse
already known published attacks and vulnerabilities. Several
vulnerability databases, which collect attacks as well as
vulnerabilities and assess their risk, have been established in
information technology (IT). Unfortunately, there are no
comparable approaches in the automotive industry so far. In
this paper, we want to show how a vulnerability database can
support the security development process. Furthermore, we
want to show how individual development phases can benefit
from this approach. Fig. 1 presents individual phases of
security development in the V-Model.
On the left side, the first step is to elaborate use cases, which
represent requirements a vehicle should meet. The next step is
a threat and risk analysis, which serves to identify potential
threats from security attacks on individual subcomponents.
The detected threats are evaluated and prioritized for their
risk. High-priority threats are used to develop or implement
security concepts and to derive mechanisms in order to protect
the vehicle. On the right side, security test phases take place,
in which implemented mechanisms are verified and validated.
For our work, we extend the V-Model by the vehicle’s
deployment phase, where a vehicle is already on the road.
Through a vulnerability reporting and disclosure process the
automotive security community can be encouraged to
collaborate and to share their competence and knowledge to
address public interest. The gained information can be used as
input for the vulnerability database. The vulnerability
database is a comprehensive tool which can serve as a source
of information for development and test activities. The
necessity of such a database has already been recognized by
various authorities. For example, Upstream Security Ltd. [6]
provides an extensive collection of automotive security
attacks. In cooperation with various research and industry
partners, we ourselves are pursuing the goal of developing a
vulnerability database and an associated disclosure process as
part of the SecForCARs (Security For Connected
Autonomous caRs) research project [7]. The resulting benefits
and possible applications for the individual phases of the
development process are shown below.
In this section, the individual development phases of the
V-Model from Fig. 1 are explained. To demonstrate the
benefits of a vulnerability database, we show how our main
research areas in automotive security are supported by this
database and its information.
A. Threat Analysis and Risk Assessment (TARA)
A threat analysis examines a system for potential threats,
which can lead to security attacks. By doing a risk assessment,
these threats are investigated for their risk. Thus, their
probability of occurrence and the effects, which can be
expected, are assessed. In general, all possible attacks on the
system are displayed in form of attack trees during this
process. Such an attack tree describes individual steps an
attacker must take to ensure that an attack leads to the intended
target. This usually consists of violating security properties
such as confidentiality, integrity, availability, or
authentication, which also affects certain assets. Assets are
safety, intellectual property or financial assets for example. At
this point, already known attacks can be used to recognize
potential attacks on the system. This can help to ensure that
these vulnerabilities are not found in new systems. It is also
possible to derive new attack paths from already known
attacks. In this context, one of our research projects has
developed a joint threat and risk analysis methodology. This
approach combines the threat analysis from the security area
with the hazard analysis from the safety area and evaluates
them together. Therefore the resulting Security Guideword
Method (SGM) [8] looks at identified hazards in a safety
analysis and examines whether they can be triggered by
security attacks. The attacks are presented in form of attack
paths. They are automatically derived by creating a formal
model consisting of a vehicle’s components, its connections
and attacks from the vulnerability database (currently we have
a collection of 413 [9] attacks that serve as a source of
information). Then the formal model is validated against a
specification with a model checker. If the specification is
violated, a counterexample is generated, which is equivalent
to an attack tree. Subsequently, the individual paths in the tree
are evaluated for their probability of occurrence. In this way,
the vulnerability database contributes directly to the
identification of threats during a vehicle’s development. The
conceptual procedure for an automatic generation of attack
trees by means of model checking techniques is shown in
Fig. 2.
Fig. 1: Security development phases in the V-Model following
SAE J3061 [5] extended by operation in the field.
Fig. 2: Conceptual overview for generating attack paths wit
model checking techniques. The vulnerability database is used to
provide requirements for the specification and design of the
system model. The underlying approach is based on [10].
The examined system and its requirements serve as an input
for model checking. In relation to the problem considered, this
is equivalent to an E/E architecture with its components and
communication links as well as threats from the SGM. In this
context, the model checker verifies if identified threats can be
realized. This is given if a path leads from an initial state to a
threat state, which is characterized by the violation of a
security property. The latter is formalized by the developed
application which generates the specification. For this
purpose, formulas of Computation Tree Logic (CTL) [10, pp.
317-332] are used and passed to the model checker as an input
artifact. The system model (M) is passed as a second artifact,
which corresponds to the E/E architecture and associated
vulnerabilities taken from the vulnerability database. For an
automated generation of the system model (M), the software
tool uses the description language of the model checker.
Subsequently, the model checker runs through the state space
and checks whether a state violates the specified property. If
the system model meets the specification (M, s φ), no
security property has been violated and no attack paths are
created. In the other case (M, s φ), a counter-example is
created which contains all identified attack paths.
B. Security Concept and Implementation
Based on the identified and evaluated threats, a security
concept is created. This includes the networking structure of a
vehicle's internal control units and communication systems as
well as security measures used to prevent potential attacks. A
vulnerability database can also support at this point by
providing statistics of previous attacks in additional
information to the security concept and measures, which
depend mainly on specific conditions of the system. For
example, an analysis of our attack collection [9] shows that
39% of the attacks were carried out remotely and 61% locally
via physical access. Furthermore, the evaluation shows that
the majority of attacks violated the security property of
authenticity. This fact has already been recognized by the
automotive industry. As a countermeasure, various
authentication mechanisms have been developed and
published with Secure Onboard Communication (SecOC)
[11] of the AUTOSAR Consortium as a solution. This enables
authentic communication on a vehicle's internal bus systems.
Although this measure prevents the infiltration of manipulated
messages on communication lines, an attacker can still send
malicious authentic messages if she is able to gain control of
an ECU. In this case the security property of authorization
would be violated. For this reason, one of our research projects
consists in the development of firewall or especially access
control mechanisms to guarantee authorized access to control
units. An access control mechanism with an application of a
rights management system will be used, which currently does
not exist in the automotive sector, or only to a very limited
extent. The access control module (s. Fig. 3) checks whether
an ECU function is allowed or denied based on a stored policy.
Beyond that, each access decision depends on the current
vehicle state, which is evaluated via physical features (e.g.,
vehicle speed, radar or camera information, location) to make
a dynamic access decision. Furthermore, we work on an
enhanced approach, which is able to evaluate a request
regarding to its hazard potential.
Therefore, a function request is analyzed if it potentially
leads to an unintended transition into a dangerous vehicle
state. To describe the required access policies, the
vulnerability database provides important information to
derive fine-grained access rules from detailed attack
information to restrict the privileges. In case of an attack,
restrictive permissions can severely limit the attacker's
C. Security Testing
Security testing describes the verification of implemented
security mechanisms as well as testing a system for
vulnerabilities. While the former can usually be realized with
techniques of conventional software testing, the latter often
uses penetration testing techniques [12]. The tester takes the
view of an attacker and tries to compromise a system through
attacks in order to uncover new vulnerabilities. At this point,
it should be noted that a security test case can be interpreted
as an attack. For this reason, a vulnerability database can be a
valuable source of information for security testers to derive
test cases. These can be used to test compliance with the
security properties of a system. In the automotive sector, code-
based test techniques and dynamic test techniques such as
fuzzing or penetration tests have been established in security
testing [5]. Code-based techniques are carried out at the
component test level (i.e., shortly after the implementation of
the software) [12]. Dynamic techniques are usually carried out
late in the development cycle, when the vehicle has already
been largely implemented.
In order to additionally address the levels of integration
and system testing, one of our research projects consists of
generating model-based test cases. Artifacts from
development activities (left side of the V-model), which are
relevant for security testing, are identified and included in the
test process (s. Fig. 4). Possible artifacts are network
architecture of the vehicle, security mechanisms or threats.
The vulnerability database can be used as an input to use
vulnerabilities and attacks as additional artifacts. The goal is
to derive test cases in order to test the vehicle for new
vulnerabilities or for compliance with required security
features on all test levels. The more extensive the database of
vulnerabilities, the more test cases can be derived. One
principle of testing is that complete testing is not possible.
Fig. 3: Access Control Module with Interaction to a Policy- an
Feature Database
For this reason, the risk assessment of attacks from the
database can be used to prioritize test cases. The overall goal
is to obtain a continuous test process that verifies and validates
the security of a vehicle at all test stages.
This section first introduces the concept of the
vulnerability database. This is followed by an explanation of
a coordinated disclosure process approach, which describes
how vulnerabilities can be reported and how to deal with
them. Fig. 5 shows how both the reporting and disclosure of
vulnerabilities as well as the database for keeping and
providing vulnerability information.
A. Vulnerability Database
The vulnerability database serves to collect and record
attacks and vulnerabilities from the automotive sector. It is
divided into a database management system and a data
structure. The latter describes a uniform structure and
description of attacks and vulnerabilities contained in the
database. This can be achieved by describing data using a
uniform taxonomy. In a previous work, we developed such a
taxonomy [13], which divides attacks into different
categories. There are categories relevant to the overview and
management of attacks like brief description, source, year of
attack, consequences, affected vehicle and components,
affected asset, or vulnerability rating.
Other categories are used to describe security-relevant
areas like attack class (technique), attack path, violated
security property, attack tools, attacker motivation,
requirements, restrictions, etc. With this data structure the
information stored in the database can serve as input for
different vehicle development phases, which were already
given in Section Ⅱ.
We divide attacks into three different levels of detail. At
the first level of detail, a description is made in an abstract
way, so that attacks can be compared and classified more
easily. With increasing level of detail (level 2 and level 3) the
attack description becomes more concrete in order to
reconstruct the exact path of an attack. By introducing the
detailed levels, interests of various stakeholders can be
addressed. On the one hand, the high level of abstraction
makes it possible to describe technical details or
manufacturer-specific information in an abstract way. On the
other hand, detailed descriptions of attacks provide
information that can be used to carry out threat analysis and
risk assessments as well as penetration tests. This taxonomy
structure was applied to our attack collection [9]. Analogous
to established vulnerability databases from the IT sector (e.g.,
CVE [14]), a risk value according to CVSS (Common
Vulnerability Scoring System, [15]) was assigned for each of
these attacks.
The second part of the vulnerability database consists of a
management system. This serves to ensure data security
requirements as well as confidentiality and anonymity, in
order to achieve acceptance on the stakeholders’ side. Possible
stakeholders are vehicle manufacturers and suppliers, security
service providers, researchers, workshops and testing
organizations, state authorities and the public. As each party
has requirements for the data security of the database, access
control systems are conceivable. This could be based on the
presented concept of detail levels by allowing access to the
higher levels (levels 2 and 3) only through authorized access.
Anonymization and pseudonymization concepts based on
generalization and suppression, slicing or noise can be used to
exchange sensitive (manufacturer-specific) data. The levels of
attack detail serve to abstract data, so no conclusions can be
drawn about manufacturers or stakeholders involved on the
basis of the data.
A web-based graphical user interface for querying data is
conceivable, which allows stakeholders to query the
vulnerabilities and attacks in a user-specific way, taking into
account access restrictions. For entering new data into the
database, an input form might also conceivable to add new
reported vulnerabilities and attacks to the database in a
structured manner. Furthermore, there is a possibility of data
output via an e-mail server, which shares entered and patched
vulnerabilities to the outside world. Thus, involved
stakeholders are regularly informed about new security
findings. Therefore, cryptographically signed e-mails can be
used to ensure authenticity.
Fig. 5: Comprehensive concept for vulnerability reporting,
disclosure and a database
Fig. 4: Security Test Model derived from the System Model an
prioritized threats that result from TARA and the Vulnerability
B. Coordinated Disclosure Process
The average service life of vehicles in Germany in 2014
was 18 years [16]. The average registration period of vehicles
on German roads has risen steadily in recent decades, reaching
a maximum of 9.5 years in 2019 [17]. The long lifecycle of
vehicles on the road increases the probability that
vulnerabilities can be detected and exploited. These can be
weak points which were not discovered at the time of
registration. This includes vulnerabilities, which can only be
identified years after initial registration due to technical
progress such as higher computing power. Regarding the long
service life of vehicles, it is therefore necessary to identify
vulnerabilities preventively even during operation before they
can be found and exploited by malicious attackers. In addition
to academic and institutional research groups, the community
of so-called “ethical hackers” consists of people who work on
their own initiative to uncover vulnerabilities. In the IT
industry, cooperation between this community and the
industry has been common practice for a long time. In the
automotive industry, such cooperation can contribute greatly
to increasing cyber security. For this purpose, concepts must
be established to communicate vulnerability information to
potentially affected manufacturers, for an efficient,
coordinated remediation and publication. After fix and
publication, the information on detected vulnerabilities can
serve as input for an automotive vulnerability database. Thus,
a vulnerability database can not only serve the purposes
described above, but also as a source of statistical data for the
authorities within the automotive security environment. A
look at the IT domain shows how concepts for coordinated
communication and disclosure of found vulnerabilities can
look like. Corresponding standards such as ISO/IEC 29147
[18] and ISO/IEC 30111 [19] are now widely accepted and
applied. However, the essential differences in given
requirements between IT and automotive domains must be
considered. The greatest challenges for the automotive
domain are the enormous safety relevance, complex vertical
and horizontal supplier structures, pronounced non-locality of
the target system vehicle, and long product life cycles. Since
this concept depends heavily on the participation of the
community, it is essential to create incentives. It should be
more appealing for a finder to report a detected vulnerability
in a coordinated and responsible way, rather than using it for
illegal purposes and causing financial or health damage. The
basis of a reporting process is therefore a functioning incentive
system which offers finders legal certainty, fast and
uncomplicated processing, rewards in form of money or
public recognition and transparency. For authorities or
manufacturers who offer such reporting processes, industry-
wide established standards are indispensable in order to meet
the given time-criticality. To ensure efficient and trustworthy
exchange of information within the complex supply chain,
standardized, automatable communication protocols as well
as pseudonymization and anonymization procedures are
necessary. This requires close cooperation between
manufacturers. In many security-relevant industries, such as
aviation, shipping and energy supply, this is already done via
Information Sharing and Analysis Centers (ISACs). In 2015,
the industry-driven AUTO-ISAC was founded in North
America to exchange and analyze knowledge about cyber
security in vehicles [20]. The members of the AUTO-ISAC
operate cross-industry vulnerability information sharing and a
steadily growing number of members offer a vulnerability
reporting service. Across all brands in the industry, 2 out of 50
top car brands have a disclosure program combined with a
reporting office and specified reporting conditions, while
suppliers have 7 out of 50 [21]. With future innovations in
networking of vehicles, automotive cyber security will
become increasingly important for public security. A more
active role of independent players, such as official institutions,
in cooperation with the automotive cyber security community
would be desirable. Thus, public interests can be protected and
threat situations can be analyzed on basis of a broad database.
In other areas of relevance to public security, there is already
an increased cooperation obligation for companies [22]. For
this purpose, independent institutions should operate their
own reporting platforms and vulnerability databases. For the
IT sector these institutions exist worldwide [23]. In order to
stimulate such a development, demonstrators for a web-based
reporting platform as well as for a (partially) public database
for automotive security vulnerabilities are being developed
within the framework of ongoing research. The structure of
these demonstrators is explained in Section IV.
The knowledge gained by observing long time established
processes in the IT sector can be analyzed and adapted for
usage within the automotive sector. Application-oriented
demonstrators for both an automotive vulnerability database
and an online reporting platform can be developed to give an
example for a concrete implementation considering
automotive requirements. An intuitive, user-friendly
reporting platform will enable finders of vulnerabilities to
contact the affected vendor or a third independent entity. This
takes place through secure communication and initiates a
process for remediation and coordinated publication of the
reported vulnerability. In addition, the web application
contains a clear, unambiguous formulation of a
manufacturer's conditions and ideas regarding the disclosure
of vulnerability information (out-of-scopes, timeline, safe-
harbor, etc.). This is combined with the assurance that legal
action will not be taken against the finder if he or she
complies with the formulated conditions. Besides this
incentive of legal certainty (the legal situation is not clear
regarding "ethical" hacking [24]) hall-of-fames or monetary
rewards are also common in bug bounty programs. In a
second demonstrator, a system of databases is to be
implemented, which contains vulnerability information from
reporting to (partially) publicly available information on
fixed vulnerabilities. Work on this topic already existed at the
our institute [25]. A finder can submit a report via the
reporting platform and upload a proof-of-concept if
necessary. This data is stored encrypted in a non-public
database. Affected manufacturers are informed about the
detected vulnerability via an e-mail server. In the following,
a coordinated remediation and disclosure process between
affected manufacturers, finder or a third independent
authority is initiated. Once a vulnerability has been fixed,
predefined information about the fixed vulnerability (similar
to an advisory) is stored unencrypted in the semi-public
database. Different groups have restricted, role-dependent
read access to the semi-public database via an user interface
on a web page. Here, it is conceivable to motivate
manufacturers to anticipate by granting them defined access
rights, if in return internally generated vulnerability
information is fed into the semi-public database. The data of
the report will be deleted from the non-public database after
fixes have been made to prevent unauthorized access to
sensitive data.
In order to meet today's requirements for automotive
security, a holistic concept is necessary, which covers the
entire development process of a vehicle or its components up
to the operation on the road. In all phases, a comprehensive
vulnerability database can provide valuable support. During
the TARA phase, it can allocate an information base to
identify threats and assess their potential danger. Moreover,
new attacks can be derived from already known attacks. For
the development of a security concept, statistical evaluations
of data from a vulnerability database can reveal information
about anomalies in the behavior or targets of already
successful attacks. This allows targeted, effective
countermeasures to be considered. In the test phase, a
database can provide additional artifacts to supplement the
artifacts from the development activities. Since it is never
possible to test for all potential threats, a risk assessment
using data from the database can be used to prioritize the test
cases. For the quality of data in such a database, it is crucial
not only to obtain the broadest and most comprehensive data
possible, but also to ensure that it is always up-to-date, which
requires a constant flow of new information into the database.
This can be achieved by a reporting and disclosure process
for found vulnerabilities, which encourages the security
community through various incentives to share their
knowledge and provide it as input for a database.
[1] K. Koscher et al., “Experimental Security Analysis of a
Modern Automobile,” in 2010 IEEE Symposium on
Security and Privacy, pp. 447–462.
[2] S. Checkoway et al., “Comprehensive experimental
analyses of automotive attack surfaces,” in USENIX
Security Symposium, 2011, pp. 447–462.
[3] C. Miller and C. Valasek, “Remote exploitation of an
unaltered passenger vehicle,” Black Hat USA, vol.
2015, p. 91, 2015.
[4] J. Petit, B. Stottelaar, M. Feiri, and F. Kargl, “Remote
attacks on automated vehicles sensors: Experiments on
camera and lidar,” Black Hat Europe, vol. 11, p. 2015,
[5] SAE J3061:2016-01, Cybersecurity Guidebook for
Cyber-Physical Vehicle Systems.
[6] Upstream Security Ltd., Upstream Security's 2020
Global Automotive Cybersecurity Report. [Online]
Accessed on: Jan. 13 2020.
[7] BMBF, SecForCARs: Sicherheit für vernetzte,
autonome Fahrzeuge. [Online] Available:
vernetzte-autonome-fahrzeuge. Accessed on: Jan. 13
[8] J. Dürrwang, K. Beckers, and R. Kriesten, “A
lightweight threat analysis approach intertwining safety
and security for the automotive domain,” in
International Conference on Computer Safety,
Reliability, and Security, 2017, pp. 305–319.
[9] F. Sommer and J. Dürrwang, IEEM-HsKA/AAD :
Automotive Attack Database (AAD). [Online]
[10] C. Baier, J.-P. Katoen, and others, Principles of model
checking: MIT press Cambridge, 2008.
[11] AUTOSAR, Specification of Module Secure Onboard
Communication - AUTOSAR CP Release 4.4.
[12] M. Felderer et al., “Security testing: A survey,” in
Advances in Computers: Elsevier, 2016, pp. 1–51.
[13] F. Sommer, J. Dürrwang, and R. Kriesten, “Survey and
Classification of Automotive Security Attacks,”
Information, vol. 10, no. 4, p. 148, 2019.
[14] CVE, Common Vulnerabilities and Exposures (CVE):
The Standard for Information Security Vulnerability
Names. Available: Accessed on:
Jun. 08 2015.
[15] CVSS Special Interest Group, Common Vulnerability
Scoring System v3.0: Specification Document.
document. Accessed on: Mar. 28 2019.
[16] WirtschaftsWoche, Lebensdauer von Autos in
Deutschland nach Automarken. [Online] Available:
[17] D. Z. KBA, Durchschnittliches Alter von Pkw in
Deutschland in den Jahren 1960 bis 2019. [Online]
[18] ISO/IEC, ISO/IEC: 29147:2014 (E)-Information
technology-Security techniques-Vulnerability
[19] ISO/IEC, ISO/IEC: 30111:2013 (E)-Information
technology-Security techniques-Vulnerability handling
[20] AUTO-ISAC, Automotive Information Sharing and
Analysis Center. [Online] Available:
[21] HackerOne, How The Automotive Industry is working
with hackers to improve security. [Online] Available:
security.pdf (. Accessed on: Jan. 10 2020.
[22] EUR-Lex, Directive (EU) 2016/1148 of the European
Parliament and of the Council. [Online] Available:
[23] FIRST, 27th annual FIRST Conference Berlin-Unified
Security: Improving the Future. [Online] Available:
sig_20150619.pdf. Accessed on: Jan. 10 2020.
[24] L. M. Pupillo, A. H. B. Ferreira, and G. Varisco,
Software vulnerability disclosure in Europe:
Technology, policies and legal challenges : report of a
CEPS Task Force. Brussels: CEPS, 2018.
[25] M. Ring, J. Dürrwang, F. Sommer, and R. Kriesten,
“Survey on vehicular attacks-building a vulnerability
database,” in 2015 IEEE International Conference on
Vehicular Electronics and Safety (ICVES), 2015, pp.
... Since attacks of vehicles usually consist of several attack steps, the database also provides an extended version, which contains 413 sub-steps of captured attacks. Based on this information, detailed attack analyses [51] can be performed. Besides academic institutions, there are also commercial repositories for automotive incidents provided by industry [52], [53]. ...
Full-text available
New requirements from the customers' and manufacturers' point of view such as adding new software functions during the product life cycle require a transformed architecture design for future vehicles. The paradigm of signal-oriented communication established for many years will increasingly be replaced by service-oriented approaches in order to increase the update and upgrade capability. In this article, we provide an overview of current protocols and communication patterns for automotive architectures based on the service-oriented architecture (SOA) paradigm and compare them with signal-oriented approaches. Resulting challenges and opportunities of SOAs with respect to information security are outlined and discussed. For this purpose, we explain different security countermeasures and present a state of the section of automotive approaches in the fields of firewalls, Intrusion Detection Systems (IDSs) and Identity and Access Management (IAM). Our final discussion is based on an exemplary hybrid architecture (signal-and service-oriented) and examines the adaptation of existing security measures as well as their specific security features.
Full-text available
Due to current development trends in the automotive industry towards stronger connected and autonomous driving, the attack surface of vehicles is growing which increases the risk of security attacks. This has been confirmed by several research projects in which vehicles were attacked in order to trigger various functions. In some cases these functions were critical to operational safety. To make automotive systems more secure, concepts must be developed that take existing attacks into account. Several taxonomies were proposed to analyze and classify security attacks. However, in this paper we show that the existing taxonomies were not designed for application in the automotive development process and therefore do not provide enough degree of detail for supporting development phases such as threat analysis or security testing. In order to be able to use the information that security attacks can provide for the development of security concepts and for testing automotive systems, we propose a comprehensive taxonomy with degrees of detail which addresses these tasks. In particular, our proposed taxonomy is designed in such a wa, that each step in the vehicle development process can leverage it.
Conference Paper
Full-text available
The automotive industry relies increasingly on computer technology in their cars, which malicious attackers can exploit. Therefore, the Original Equipment Manufacturers (OEMs) have to adopt security engineering practices in their development efforts, in addition to their safety engineering efforts. In particular, information assets that can undermine safety have to be identified and protected. Assessing the safety relevance of specific information assets is best done by safety engineers, who, unfortunately, often do not have the security expertise to do so. In this paper, we propose a technique for identifying information assets and protection goals that are relevant for safety. Our method is based on security guide-words, which allow a structured identification of possible attack scenarios. The method is similar to the Hazard and Operability Study (HAZOP) in safety for eliciting possible faults. The similarity of the approach shall ease the effort for non-security engineers to identify information assets and protection goals to allow an exchange between safety and security mindsets. In contrary to other proposed methods, we performed an evaluation of our technique to show their practical application. In our evaluation with a total of 30 employees of an automotive supplier and employees of the University of Applied Sciences in Karlsruhe, results show that all non-security engineers achieved for precision, productivity and sensitivity, on average, higher values than the security control group.
Conference Paper
Full-text available
Modern cars are significantly linked to the outside world because of rising number of connections in the vehicle, connections between the vehicle and the exterior environment , e.g. diagnostics and flash interfaces or the numerous amounts of bus systems for data exchange. All these connections are potential security breaches. Previous papers and this research work show that there are a lot of security vulnerabilities in modern car connections. The aim of this paper is to merge the found vulnerabilities and the available results in literature, categorise them in the same way as in Information Technology (IT) and give an outlook on how most problems can be solved. This paper also aims to introduce an example database for automotive IT vulnerabilities.
Full-text available
Identifying vulnerabilities and ensuring security functionality by security testing is a widely applied measure to evaluate and improve the security of software. Due to the openness of modern software-based systems, applying appropriate security testing techniques is of growing importance and essential to perform effective and efficient security testing. Therefore, an overview of actual security testing techniques is of high value both for researchers to evaluate and refine the techniques and for practitioners to apply and disseminate them. This chapter fulfills this need and provides an overview of recent security testing techniques. For this purpose, it first summarize the required background of testing and security engineering. Then, basics and recent developments of security testing techniques applied during the secure software development lifecycle, i.e., model-based security testing, code-based testing and static analysis, penetration testing and dynamic analysis, as well as security regression testing are discussed. Finally , the security testing techniques are illustrated by adopting them for an example three-tiered web-based business application.
Conference Paper
Full-text available
Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks. While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure. We demonstrate that an attacker who is able to infiltrate virtually any Electronic Control Unit (ECU) can leverage this ability to completely circumvent a broad array of safety-critical systems. Over a range of experiments, both in the lab and in road tests, we demonstrate the ability to adversarially control a wide range of automotive functions and completely ignore driver inputdash including disabling the brakes, selectively braking individual wheels on demand, stopping the engine, and so on. We find that it is possible to bypass rudimentary network security protections within the car, such as maliciously bridging between our car's two internal subnets. We also present composite attacks that leverage individual weaknesses, including an attack that embeds malicious code in a car's telematics unit and that will completely erase any evidence of its presence after a crash. Looking forward, we discuss the complex challenges in addressing these vulnerabilities while considering the existing automotive ecosystem.
Remote exploitation of an unaltered passenger vehicle
  • C Miller
  • C Valasek
C. Miller and C. Valasek, "Remote exploitation of an unaltered passenger vehicle," Black Hat USA, vol. 2015, p. 91, 2015.
Remote attacks on automated vehicles sensors: Experiments on camera and lidar
  • J Petit
  • B Stottelaar
  • M Feiri
  • F Kargl
J. Petit, B. Stottelaar, M. Feiri, and F. Kargl, "Remote attacks on automated vehicles sensors: Experiments on camera and lidar," Black Hat Europe, vol. 11, p. 2015, 2015.
Sicherheit für vernetzte, autonome Fahrzeuge
  • Secforcars Bmbf
BMBF, SecForCARs: Sicherheit für vernetzte, autonome Fahrzeuge. [Online] Available: Accessed on: Jan. 13 2020.