Open Problems when Mapping Automotive

Security Levels to System Requirements

Thomas Rosenstatter and Tomas Olovsson

Department of Computer Science and Engineering, Chalmers University of Technology, Gothenburg, Sweden

Keywords:

Vehicular Security, System Security, Requirements Engineering, Security Classiﬁcation.

Abstract:

Securing the vehicle has become an important matter in the automotive industry. The communication of

vehicles increases tremendously, they communicate with each other and to the infrastructure, they will be

remotely diagnosed and provide the users with third-party applications. Given these areas of application, it

is evident that a security standard for the automotive domain that considers security from the beginning of

the development phase to the operational and maintenance phases is needed. Proposed security models in the

automotive domain describe how to derive different security levels that indicate the demand on security, but do

not further provide methods that map these levels to predeﬁned system requirements nor security mechanisms.

We continue at this point and describe open problems that need to be addressed in a prospective security

framework for the automotive domain. Based on a study of several safety and security standards from other

areas as well as suggested automotive security models, we propose an appropriate representation of security

levels which is similar to, and will work in parallel with traditional safety, and a method to perform the

mapping to a set of predeﬁned system requirements, design rules and security mechanisms.

1 INTRODUCTION

New technologies and functionalities are constantly

introduced to vehicles. Vehicle-to-Vehicle (V2V)

and Vehicle-to-Infrastructure (V2I) communication

enables vehicles to share information with each other

and send warnings, e. g., about roadworks and traf-

ﬁc jams. Remote diagnostics is performed by vehi-

cle manufacturers and licensed repair shops, and plat-

forms for third-party applications in vehicles are also

provided. As a consequence of this ongoing transi-

tion, a security standard is crucial in order to secure

vehicles against modiﬁcations, hacks, and espionage.

The exposure of serious vulnerabilities underlines

the need for security in the automotive domain. The

attack surface of modern vehicles was analysed by

[Checkoway et al., 2011] and they demonstrated vul-

nerabilities in the Tire-Pressure Monitoring System,

media-player, OBD-II port, and Bluetooth. Further-

more, [Miller and Valasek, 2014] provide a survey of

attack surfaces of several vehicle models and [Yan,

2015] presents vulnerabilities in connected vehicles

using different attack vectors.

A systematic approach dealing with the aforemen-

tioned security threats is necessary, and in addition, an

automotive security standard is needed to harmonise

the hardware and software security requirements be-

tween the vehicle manufacturers and the suppliers.

This becomes evident when vehicle manufacturers get

more dependent on their suppliers since the complex-

ity of third-party modules is increasing and the mod-

ules are required to be reliable and secure. A secu-

rity framework which also contains a mapping to sys-

tem requirements and design rules containing guide-

lines describing how these demands can be fulﬁlled,

increases the efﬁciency during the development and

testing due to the ﬁxed structure and guidance, as

well.

The need for such a security standard has also

been identiﬁed by the industry, which initiated the

ISO/SAE AWI 21434 Road Vehicles – Cybersecurity

engineering. This work item is ongoing and currently

under development. Proposed security models, such

as EVITA [Henniger et al., 2009] and HEAVENS [Is-

lam et al., 2016], describe methods from identifying

threats to classifying them into security levels. Both

models focus on the identiﬁcation of risks and threats,

and how to classify them. HEAVENS describes meth-

ods to derive application speciﬁc requirements, but

does not perform a mapping to predeﬁned require-

ments nor security mechanisms that are required for

each security level. EVITA on the other hand lists the

Rosenstatter, T. and Olovsson, T.

Open Problems when Mapping Automotive Security Levels to System Requirements.

DOI: 10.5220/0006665302510260

In Proceedings of the 4th International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2018), pages 251-260

ISBN: 978-989-758-293-6

251

results of their risk analysis in [Ruddle et al., 2009],

but does not provide a mapping to generic security

requirements based on the security level.

Information security is concerned with conﬁden-

tiality, integrity and availability, which will be later

extended according to STRIDE [ISO 15408, 2009,

Microsoft Corporation, 2005]. We deﬁne security lev-

els similar to [Islam et al., 2016]. Security levels rep-

resent the necessity and extent for security measures

in a speciﬁc function or module. The factors taken

into account when deriving the security levels depend

on the underlying security model that considers the

severity of potential attacks, required expertise to per-

form the attack, or the impact for the involved parties

in case of the attack. We split security requirements in

two groups, system requirements and application spe-

ciﬁc requirements. System requirements are generic

security requirements that need to be fulﬁlled for a

certain security level and describe design rules or se-

curity functions. Application speciﬁc requirements

are the result of a threat analysis and include indi-

vidual requirements that are not covered by system

requirements. Security mechanisms are methods to

fulﬁl a requirement, for instance the choice of encryp-

tion algorithms to provide conﬁdentiality of informa-

tion, or use of access control lists to restrict the data

ﬂow in the in-vehicle network.

In this paper, we survey proposed security models

and acclaimed standards in the area of safety and

security, we investigate how these standards or

models classify safety and security, and how they

perform the transition to system requirements.

Our contributions in this paper are the following:

• A study on safety and security standards, along

with proposed security models for the automotive

domain.

• Propose methods for how to move forward from

unique requirements of individual systems and

identiﬁed security levels to a set of mandatory sys-

tem requirements, design rules and security mech-

anisms and

• show that such requirements should be based on

the security level of the function to be imple-

mented.

• We show the beneﬁts with having such a frame-

work in place when dealing with third-party de-

veloped functionality.

• We show the challenges and complexity of deﬁn-

ing such a framework.

2 BACKGROUND AND RELATED

WORK

The difference between safety and security is that

safety is about handling malfunctioning behaviour

that is caused by random errors. Security threats are

caused by an attacker who intentionally wants to mod-

ify the system, harm involved people, or gather infor-

mation. It may be also the case that the owner, who

has physical access and unlimited time, slips in the

role of an attacker in order to perform unauthorised

modiﬁcations on the vehicle. The skills of attackers

may vary from limited to advanced depending on his

knowledge, purpose, and equipment. For these rea-

sons, security involves complex countermeasures. An

attacker who has successfully exploited a vulnerabil-

ity of one vehicle is able to apply the same method to

all vehicles of that speciﬁc model or even to all vehi-

cles of that manufacturer or supplier depending on the

kind of vulnerability [SAE J3061, 2016].

The large attack surface in vehicular security is an-

other difference to safety. Performing Hazard Analy-

sis and Risk Assessment (HARA) on functional safety

requires a narrower focus compared to assessing the

security of a system. The security assessment of a sys-

tem requires one to cope with a larger attack surface.

For instance, a vehicle that is able to communicate

with its infrastructure and cooperate with other vehi-

cles can not only be attacked locally, it can be attacked

through this communication channel as well. More-

over, vehicles have Internet access which additionally

increases the attack surface. Having a built-in mo-

bile communication unit also enables attacks via SMS

and other phone services. In addition to the wire-

less communication, Checkoway et al. showed other

attack vectors, such as an attack through the media-

player [ENISA, 2016, Checkoway et al., 2011].

Looking at the different areas shows that safety

has been adapted to the speciﬁc needs for this area.

[ISO 26262, 2011] is the standard for functional

safety of road vehicles, [RTCA DO-178, 2011] and

[RCTA DO-254, 2000] (software and hardware) are

customised for the aeronautics domain, and the rail-

way domain is described in CENELEC EN 50126,

CENELEC EN 50128, and CENELEC EN 50128.

[Blanquart et al., 2012] perform a comparison of the

criticality categories across safety standards in differ-

ent domains, including the aforementioned standards

and the corresponding safety standards for nuclear fa-

cilities and space systems. They highlight how these

domains differ from each other in terms of structure

and guidance throughout the development process.

Security standards exist in many areas, such as

programming, industrial automation, and system and

VEHITS 2018 - 4th International Conference on Vehicle Technology and Intelligent Transport Systems

252

device security. The [SEI CERT C, 2016] Coding

Standard, for instance, deﬁnes rules for speciﬁc pro-

gramming languages, in this case for C, and uses a

classiﬁcation in levels to indicate the impact of not

addressing a certain rule. SEI CERT C shows how

certain programming traits have to be implemented in

order to be reliable, secure and safe. By following

these rules, undeﬁned behaviour that may lead to vul-

nerabilities will to a large extent be eliminated. The

standard ranks each rule with an example and its pri-

ority and level. A combination of severity, likelihood

and remediation costs results in such a level ranging

from 1 to 3. The priorities are directly mapped to the

levels.

[NIST SP 800-53r4, 2013] is catalogue of secu-

rity controls and assessment procedures for informa-

tion systems. The security controls are split in 18

families, such as Access Control, Incident Response,

and Identiﬁcation and Authentication. Consequently,

each family comprises security controls mapped to

priority and impact levels (low, medium, high). Se-

curity controls are nested, the lowest priority level has

to be implemented ﬁrst and controls with higher prior-

ity have to be implemented in addition to the controls

with a lower priority level.

Security models for the automotive domain have

been proposed by various researchers. [Burton et al.,

2012] suggest a method that extends ISO 26262 with

security analysis. A combined safety and security

development lifecycle is presented by Schmittner et

al. in [Schmittner and Ma, 2014, Schmittner et al.,

2015]. Burton et al. and Schmittner et al. both

focus on the differences between safety and secu-

rity and how to combine them, but they do not dis-

cuss how predeﬁned system requirements or design

rules for security can be deﬁned. Common Cri-

teria [ISO 15408, 2009] is a standard for evaluat-

ing security properties of systems and devices. The

similarities of ISO 26262 and Common Criteria are

discussed in [Schmittner and Ma, 2014]. The au-

thors describe the relationship between the Automo-

tive Safety Integrity Levels (ASILs) from ISO 26262

and the Evaluation Assurance Levels (EALs) from

Common Criteria according to the strictness and de-

gree of formalism. The SAHARA method presented

by [Macher et al., 2015] combines the existing HARA

known from ISO 26262 with a security assessing

method considering the needed resources and know-

how. Macher et al. do not describe a method to de-

rive system requirements based on the resulting se-

curity level. The EVITA [Henniger et al., 2009] and

HEAVENS [Islam et al., 2016] models describe the

procedure on how to derive security levels and how

these can be used for requirement engineering, how-

ever, they do not perform a mapping to system re-

quirements as we propose.

Guidelines for cybersecurity with respect to the

automotive domain are [SAE J3061, 2016] and

[ENISA, 2016]. Both guidelines provide good prac-

tice examples and recommendations, whereas ENISA

limits the scope by excluding autonomous vehicles

and V2V communication in their guideline. An-

other difference is that J3061 sets the focus on the

necessary processes and their implementation, while

ENISA describes the typical architecture of smart ve-

hicles and possible threats and attacks. J3061 lists

Threat, Vulnerabilities, and implementation Risks

Analysis (TVRA), which is a threat and risk assess-

ment method developed by ETSI in TS 102 165-

1 [ETSI, TS, 2011]. According to J3061, this model is

not suited for control and data networks of vehicles, as

it was developed speciﬁcally for telecommunications

networks. These two guidelines for cybersecurity ad-

dress important subjects, but do not discuss methods

for mapping to system requirements nor mechanisms.

3 THE COMPLEXITY IN

AUTOMOTIVE SECURITY

Lifetime. The automotive domain differs in many

ways from other areas. A vehicle has a lifetime of

about 150.000 to 300.000 km [Hawkins et al., 2012].

During this time, the vehicle has to be safe, secure,

ﬁrmware needs to be updated, the owner may change,

and vehicle parts or modules need to be replaced.

Discovering a security vulnerability in the vehicle re-

quires a fast reaction and update distribution to the ve-

hicles. Once a severe security problem has been iden-

tiﬁed, over-the-air updates provide efﬁcient means for

distribution as they are much faster than a recall of

a certain vehicle model or vehicles with a speciﬁc

component from a supplier. In addition, over-the-air

updates are needed because security requirements 20

years from now are likely to be different from what is

designed today, since the expected lifetime from de-

sign of security functionality to the expected end of

the vehicle lifetime can be as much as 20 – 25 years.

Interplay between safety and security. The safety

of the passengers has to be retained in all situations.

Fault detection mechanisms have to be designed in

such a way that they cannot be exploited by an at-

tacker. For example, the use of redundant modules

for increased safety, may open up for attacks where

both modules believe the other one is active while it

is the attacker who sends the messages.

Compliance to standards. One speciﬁc challenge

for heavy duty vehicles is the required compliance to

Open Problems when Mapping Automotive Security Levels to System Requirements

253

[SAE J1939, 2013]. This standard speciﬁes the exact

content of frames that have to be transmitted within

the in-vehicle network. To comply, the frames may

not be changed and thus encryption mechanisms may

not be used. This restriction limits the set of suitable

security mechanisms.

Compliance between manufacturers and suppli-

ers. The suppliers will provide modules with more

functionalities and may also need to maintain the se-

curity of their products. Manufacturers integrate soft-

ware, and hardware modules from third-party devel-

opers and in-house developed modules into a vehicle

and thus need to ensure the security and safety of all

modules individually and combined. A well-deﬁned

framework with strict system requirements for secu-

rity functions and mechanisms to be used, would sim-

plify the requirement speciﬁcations and communica-

tions between these two parties.

Maintenance. Authorised workshops need to be

able to diagnose the vehicle and replace modules in

case of a failure. For this reason, they need to, for in-

stance, be able to handle the change of security keys

in an ofﬂine and online environment. Authorised de-

vices may also need to be revoked in case of theft.

Alignment with ISO 26262. The harmonisa-

tion/alignment with the functional safety standard for

road vehicles [ISO 26262, 2011] is important when

introducing a new framework for automotive security.

ISO 26262 has a high acceptance in the automotive

domain and would, for this reason, signiﬁcantly re-

duce the time required for introducing such a secu-

rity framework, because of the already known pro-

cesses. The question is to which extent it should be

harmonised. Strong harmonisation has the advantage

of easier integration due to known processes, but it

may not be ideal for security due to the fundamental

differences to safety.

Guidance. The necessary level of guidance has to

be deﬁned. Providing a strict guidance for each re-

quirement may not be feasible or optimal for certain

cases. The developers may, for certain security re-

quirements, ﬁnd other countermeasures that are more

suitable. On the other hand, sparse guidance leads

to overhead when evaluating security of third-party

components and individual solutions may not corre-

spond to best practices.

We address these problems by investigating how

standards and other security models handle guidance

and propose a method able to cope with the problems

listed above.

4 STANDARDS AND MODELS

In this section, we describe standards, models, and ap-

proaches that inﬂuence the design of safety and secu-

rity by assigning levels according to a deﬁned scheme.

They are all well-known and accepted in their domain

or applicable for the automotive area. The insights

into how these standards allocate safety or security

levels and how they perform the mapping to require-

ments are further used for our suggested framework.

The related standards and models being described in

detail are [ISO 26262, 2011], [RTCA DO-178, 2011],

EVITA [Henniger et al., 2009], HEAVENS [Islam

et al., 2016], Trust Assurance Levels [Kiening et al.,

2013], and [IEC 62443, 2013].

First, we describe the purpose of the standards

and models followed by a discussion on the number

of levels their analysis results in. Next, we discuss

the impact of the levels in the design and develop-

ment of the system and investigate how the standards

or models address the relation between requirements

and allocated levels. Do they provide strict informa-

tion about the requirements necessary for each level

or is the mapping between the allocated levels and the

requirements without guidance?

4.1 Safety Standards

ISO 26262 applies HARA for a system without safety

measures by taking the severity, exposure, and the

controllability into account. A hazard is deﬁned by

ISO 26262 as malfunctioning behaviour that poten-

tially causes harm. After identifying the levels for

each class, such as severity and controllability, they

are mapped according to a predeﬁned matrix to the

ASIL levels. The ASIL levels comprise QM, A, B,

C, and D, where QM corresponds to Quality Man-

agement, i.e., a non-safety relevant event which does

not require any further safety consideration in the de-

sign and development of the system. Events classi-

ﬁed as ASIL D, the highest level, require the highest

demand regarding risk reduction. In case a system

failure causes several hazards, the highest occurring

ASIL rating has to be applied [ISO 26262, 2011].

Next, a safety goal is deﬁned for each hazardous

event. The safety goals are subsequently associated

with a functional safety concept, which states how

the safety goal can be achieved. The next step is to

formulate a technical safety concept describing how

the functionality is going to be implemented by hard-

ware and software on the system level. The soft-

ware and hardware safety requirements describe the

speciﬁc requirements, which will be implemented.

The requirements inherit their ASIL level from their

VEHITS 2018 - 4th International Conference on Vehicle Technology and Intelligent Transport Systems

254

safety goal respectively their parent requirement [ISO

26262, 2011].

ISO 26262 provides guidelines and requirements

for each level on system, hardware, software, produc-

tion, and operation level. In addition to the speci-

ﬁed requirements for each ASIL level, this standard

also provides three levels of recommendations, no

recommendation (◦), recommended (+), and highly

recommended (++). The method independent paral-

lel redundancy as a mechanism for error handling at

the software architectural level, for instance, is rec-

ommended for ASIL C and highly recommended for

ASIL D [ISO 26262, 2011].

DO-178 is the safety standard for the aeronautics

domain, its categories are called Development As-

surance Levels (DAL). The DALs are representing

the effects of a failure condition, e. g., catastrophic or

hazardous. The ﬁve DALs range from A, the most

demanding level, to E, which is the equivalent to

ASIL QM. A top-level function is mapped to the

Function DAL (FDAL) according to a table that asso-

ciates the failure condition class and the quantitative

safety requirement (failures per hour) with the DAL.

These top-level functions are decomposed to sub-

functions, which are further decomposed to items. It

may be the case that a top-level function is divided

into more than one sub-function, where one of the

sub-functions has a lower or the same DAL as the top-

level function. DO-178 also provides guidance, but

not to the same extent as ISO 26262 [Blanquart et al.,

2012, RTCA DO-178, 2011, RCTA DO-254, 2000].

4.2 Security Models in the Automotive

Domain

The HEAVENS and EVITA projects deﬁne models to

derive security levels. [Henniger et al., 2009] describe

a model developed in the EVITA project. [Islam et al.,

2016] propose an ISO 26262 compliant model as part

of the HEAVENS project. Both models specify how

to identify threats and classify them into security lev-

els.

Henniger et al. use attack trees based on use cases

as base for the following requirements analysis. The

root of the attack tree is the goal of the attack. The

sub-levels contain sub-goals that can lead to the goal

of the parent node.

A risk assessment is performed for each poten-

tial attack. The mapping of the three components,

severity (4-component vector), probability of a suc-

cessful attack, and controllability, is derived from a

predeﬁned table which leads to a security risk level.

This level is not associated to a single value, it is a

4-component vector describing the security risk level

for the elements of the severity vector. The levels for

each element are in the range [0, 7], where 0 repre-

sents no risk and 6 the highest risk. Level 7 and 7+

are used for safety critical threats with controllability

C ≥ 3 and severity high [Henniger et al., 2009].

The authors further discuss how the security risk

levels can be used to prioritise security requirements.

Requirements resulting from the developed use cases

and risk assessment are listed in [Ruddle et al., 2009].

Henniger et al. highlight that not only the highest rat-

ing should be considered, the number of occurrences

in the attack trees has to be considered as well. A

lower risk that is seen in several attack trees may have

the same importance as a level 5 or higher risk that

appears only once in the attack tree [Henniger et al.,

2009].

The HEAVENS risk assessment model suggested

by Islam et al. describes the workﬂow for identify-

ing assets and threats (threat analysis), and a method

describing how to perform the risk assessment. Islam

et al. apply Microsoft’s STRIDE model [Microsoft

Corporation, 2005] to identify the asset/threat pairs.

The result of the risk assessment is the security

level, which is a combination of the threat level and

the impact level. The levels for the resulting secu-

rity level are QM, low, medium, high, critical. Is-

lam et al. highlight the parallels to ISO 26262. The

functional safety requirements derived from the safety

goals in ISO 26262 have the same property as the

high-level security requirements originating in the as-

set/threat pair and their corresponding security level.

Both are high-level requirements that are indepen-

dent from the implementation. These requirements

are consequently divided into technical security re-

quirements on system level, which further result in

hardware and software security requirements.

4.3 Trust Assurance Levels for V2X

Communication

The purpose of the Trust Assurance Levels is to

classify the security of Vehicle-to-Everything (V2X)

communication nodes. [Kiening et al., 2013] provide

the minimum requirements for each Trust Assurance

Level (TAL) and discuss the beneﬁts of certifying

V2X nodes and how to perform the veriﬁcation of

security. The mapping of the TAL is performed ac-

cording to a predeﬁned table. This table contains the

minimum requirements and a description of security

implications for each level. The proposed levels are

nested and range from 0 to 4. A node with TAL 0

does not have any security measures. With an increas-

ing TAL, the core V2X communication modules and

other relevant modules of the node need to be secured.

Open Problems when Mapping Automotive Security Levels to System Requirements

255

For instance, TAL 4 requires all involved modules to

be protected. Moreover, the authors map the TALs to

the EALs of Common Criteria [Kiening et al., 2013].

4.4 Cyber Security Standard - IEC

62443

[IEC 62443, 2013] is a group of security standards for

Industrial Automation and Control Systems. Part 3

describes the system security requirements and secu-

rity levels. The security levels range from 0 to 4 and

are further split into Target Security Levels (SL-T),

Achieved SLs (SL-A), and Capability SLs (SL-C).

A security level of 0 corresponds to no speciﬁc re-

quirements for security and level 4 implies the high-

est demand on security. SL-T is derived from a con-

sequence analysis on a particular system, called zone,

and describes the desired security level. During the

iterative design phase SL-A and SL-T are compared

with each other after every cycle. Components and

systems need to provide the SL-C that indicates its

capability in regards to the deﬁned security levels.

In case that SL-C does not meet the required SL-

T, compensating countermeasures have to be imple-

mented [IEC 62443, 2013].

The high-level requirements are named Founda-

tional Requirements (FRs) and consist of seven el-

ements, e. g., system integrity, data conﬁdentiality,

and use control. These FRs are consequently broken

down into System Requirements (SRs) and Require-

ment Enhancements (REs). The security level for a

speciﬁc zone or component does not consist of a sin-

gle value, it is a 7-component vector describing the

security level for each FR. A table in IEC 62443 maps

the SRs and REs to the security level of each FR [IEC

62443, 2013].

Equation 1 shows the composition of the Security

Levels (SLs) in IEC 62443. Each component listed

in this vector refers to a FR. An example shown in

IEC 62443-3-3 is the SL-T of a basic process control

system zone. It is speciﬁed that this zone requires a

SL of 3 for the FRs Restricted data ﬂow and Resource

availability. In contrast, measures to provide Data

conﬁdentiality are not required, as the SL is 0.

Table 1 provides an overview of the reviewed stan-

dards and models. It highlights the differences be-

tween safety and security. Functional safety stan-

dards have ﬁve different levels whereas the automo-

tive security models, such as EVITA and HEAVENS,

use a more complex representation of security or risk

levels. IEC 62443, developed for the security of

industrial automation and control systems, classiﬁes

security as a 7-component vector with a range of

ﬁve levels for each element and differs compared to

ISO 26262 with respect to how it relates the SLs to

requirements.

SL =







Identiﬁcation & authentication ctrl.

Use control

System integrity

Data conﬁdentiality

Restricted data ﬂow

Timely response to events

Resource availability



















(1)

5 PROPOSED SECURITY

LEVELS AND MAPPING

Our previous discussion about the problems of im-

plementing security in vehicular systems followed by

a survey of standards and models, are the base for

the following suggestion for the number and repre-

sentation of security levels, and the mapping to sys-

tem requirements, design rules and security mecha-

nisms. Investigating how established standards and

proposed security models deﬁne a classiﬁcation in

form of Security Levels (SLs) is important for sug-

gesting an automotive security framework. Addition-

ally, we discuss how to evaluate or even certify the se-

curity compliance of a module, and how well our pro-

posed framework is aligned with ISO 26262. We want

to highlight that the suggested solutions are a proposal

based on the review of several standards and models

from safety or other security domains and should pro-

vide a recommendation to future research.

5.1 Number of Security Levels

The decision on the number of SLs and the mapping

to system requirements strongly depends on the un-

derlying model for risk/threat assessment. Models

differ in their composition and weights for parame-

ters, such as expertise to perform the attack, opportu-

nity, and impact level.

Both functional safety standards, ISO 26262 and

DO-178, use ﬁve levels to classify safety, but secu-

rity models propose different solutions. The TALs

with the focus on V2X communication security use

ﬁve levels. Two automotive security models propose

a more complex classiﬁcation of security or risk lev-

els. EVITA focusses on the risk of security relevant

attacks by representing the risk as a 4-component vec-

tor and HEAVENS associates the SLs with a speciﬁc

asset/threat pair.

Following the HEAVENS approach by using its

classiﬁcation of SLs leads to one level in the range

of 0 to 4 for each threat/asset pair, meaning that the

VEHITS 2018 - 4th International Conference on Vehicle Technology and Intelligent Transport Systems

256

Table 1: Overview of the reviewed Standards in respect to their classiﬁcation approach.

ISO 26262 DO-178 IEC 62443 TAL EVITA HEAVENS

Field of Application Safety Safety Security Security Security Security

# Security Levels 5 5 5 5 8 5

Representation / vector size 1 1 7 1 4 1

Predeﬁned System Requirements ( )

– – –

HEAVENS associates each threat/asset pair with a SL.

ISO 26262 provides recommendations for speciﬁc methods depending on the SL.

threat violating conﬁdentiality of an individual asset

ranges between these levels. Continuing with deﬁn-

ing high-level requirements and technical security re-

quirements for each threat/asset pair would only result

in more overhead. Instead, we recommend the use

of system requirements, which describe the necessary

security measures for each type of threat and secu-

rity attribute and thus provide the developer already

with necessary requirements that need to be fulﬁlled

depending on the SL.

The classiﬁcation of SLs needs to provide sufﬁ-

cient categories to have a distinct separation of the

required security measures. Having a wide range of

SLs may lead to an overly detailed guidance, which

may be inefﬁcient due to the high granularity of re-

quirements and the difﬁculty to distinguish between

the SLs.

Since security needs to address many different as-

pects or attributes, such as the authenticity of mes-

sages and their origin, system integrity, and data con-

ﬁdentiality, it is reasonable to use a vector deﬁning

the SL for each component representing one of these

areas. The SL of each component is in the range of 0

to 4. Such an approach is described in IEC 62443 and

seems to be appropriate for the automotive domain

as well, as the representation as a single value may

lead to imbalanced security measures. For certain

modules or subsystems, it might be necessary to pro-

vide data conﬁdentiality, whereas data integrity might

be of greatest importance for many other subsystems,

hence, it is beneﬁting to distinguish between such at-

tributes and assign them SLs individually. In addition,

a vector representation eases the communication be-

tween the parties, as a vector already combines the

demanded level of security for each attribute.

Furthermore, we suggest to distinguish between

target, achieved and capability SL, as described in

IEC 61442. Modules provided by suppliers, or in-

house developed modules should be classiﬁed accord-

ing to their security capability (SL-C). This may lead

to a more efﬁcient reuse of developed modules, as

they are clearly marked with the SL they are capa-

ble of. This approach also simpliﬁes the design of the

system, since modules and systems can be labelled

with their target SL (SL-T) that states the necessary

system requirements and design rules.

Describing security as a vector instead of a sin-

gle value is different to ISO 26262, nevertheless, we

believe that it is unavoidable to present security as a

structure describing several attributes. As an exam-

ple, SL(auth.) = 1 may require a veriﬁcation of the

new ﬁrmware when performing an upgrade, whereas

SL(auth.) = 3 may require a ﬁrmware veriﬁcation at

every start-up and SL(auth.) = 4 may additionally re-

quire the authenticity of messages sent and received

within this particular subsystem. IEC 62443 and other

security models also use a vector or other similar ap-

proaches and thus support our choice.

5.2 Mapping to Security Requirements

and Mechanisms

There are different ways to map SLs to system re-

quirements and security mechanisms. One option is

to perform a binary mapping of the SLs, e. g., a sys-

tem requirement has to or does not have to be ful-

ﬁlled. An alternative is the introduction of recommen-

dations in combination to the binary mapping, which

is a closer approach to ISO 26262. The presentation

of the requirements for certain SLs, is another impor-

tant aspect.

ISO 26262 lists the requirements and recommen-

dations in separate documents, e. g., description for

system, hardware and software level. IEC 62443 on

the other hand provides a compact overview of the

required security measures. The System Require-

ments (SRs) and Requirement Enhancements (REs)

of a Foundational Requirement (FR) are mapped to

the SLs. The demands for fulﬁlling a SL of a FR is re-

ﬂected in the required SRs and REs. For lower levels,

it is sufﬁcient to only fulﬁl a few requirements, but in

order to provide the highest SL, one must fulﬁl all SRs

and REs. This way, it is ensured that also modules or

subsystems with lower SLs provide basic methods to

Open Problems when Mapping Automotive Security Levels to System Requirements

257

Table 2: Binary Mapping of Security Levels to System Re-

quirements and Requirement Enhancements.

FR 1 0 1 2 3 4

none low medium high critical

SR 1 • • • •

SR 2 • • •

RE 2.1 • •

RE 2.2 •

SR 3 • • •

. . .

ensure a speciﬁc security attribute. Table 2 illustrates

the structure of this approach. It shows which SRs and

REs of FR 1 are required for each SL. For instance,

SL 1 requires only SR 1, whereas SL 2 requires SR 1,

SR 2, and SR 3. Higher levels demand also the RE

2.1 respectively RE 2.1 and RE 2.2.

The FRs and their associated SRs and REs shown

in Table 2 still need to be deﬁned. One approach is to

use the FRs of IEC 62443 (see Equation 1) as a base

and adjust the SRs and REs by incorporating auto-

motive speciﬁc requirements which are described in

Section 3, e. g., the possibility to exchange vehicle

parts in an ofﬂine environment (ofﬂine distribution of

cryptographic keys) and ofﬂine diagnostics in a work-

shop (see Section 3). Another approach we propose

is to combine the structure of IEC 62443 with HEAV-

ENS – the FRs are the security attributes, which are

mapped to Microsoft’s STRIDE model [Islam et al.,

2016, Microsoft Corporation, 2005]. This leads to a

6-component vector for each asset, as shown in Equa-

tion 2. This example shows the security demands for

each element, e. g., the demands for integrity are high,

whereas there are no demands on conﬁdentiality. Ad-

ditionally, SRs and REs for each FR have to be de-

ﬁned and mapped to the SLs.

With this approach, it is possible to incorporate

design rules in the SRs as well. Plausible design rules

may be the physical isolation of critical networks,

multi-factor authentication of diagnostic devices or

other modules with a critical SL, or the composition

of modules with different SLs in one control unit.

SL =







Authenticity

Integrity

Non-repudiation

Conﬁdentiality

Availability

Authorisation



















(2)

A mapping to speciﬁc security mechanisms can

Table 3: Combined presentation of security and functional

safety levels.

0 1 2 3 4

QM A B C D

Security

Authenticity •

Integrity •

Non-repudiation •

Conﬁdentiality •

Availability •

Authorisation •

Safety •

be performed through recommendations. The chal-

lenge when introducing such a mapping is its dynam-

ics. The mapping changes over time as cryptographic

algorithms may be considered as broken or exist-

ing hardware may have sufﬁcient processing capa-

bilities to solve the cryptographic problem on which

the mechanism is built upon. Such recommendations

support the developers in choosing mechanisms that

satisfy a certain SL. They can be represented as a list

of requirements associated with certain mechanisms.

This method requires an individual identiﬁer or a ver-

sion number for each mapping to a security mecha-

nism in order to provide a seamless documentation of

how the SRs have been addressed.

Tools for the secure implementation of software

are the [SEI CERT C, 2016] Coding Standard and the

[MISRA C:2012, 2013] Guideline, both give guid-

ance and provide rules to develop software that is safe,

secure, and reliable. ISO 26262, for instance, rec-

ommends the use of MISRA C. We propose to com-

ply with such a secure coding standard for any SL

greater than 0, as basic vulnerabilities inherited from

programming languages or the wrong use of it can be

limited this way.

We believe that a vector representation allows

the combination of demands from different disci-

plines, such as safety. Adding the ASIL levels from

ISO 26262 to the vector is beneﬁcial when discussing

and deploying the requirements for a module or sub-

system, as the requirements of both areas have to be

implemented in the very same module or feature. Pro-

viding a vector or table as illustrated in Table 3 is thus

useful for the software architects and developers to

see if required safety mechanisms interfere with se-

curity requirements or vice versa. We propose such

a combined presentation of both, safety and security

demands, as it is necessary in order to fulﬁl the nec-

essary requirements.

VEHITS 2018 - 4th International Conference on Vehicle Technology and Intelligent Transport Systems

258

5.3 Evaluation and Certiﬁcation

Providing evidence about how the SL has been

achieved is necessary for the vehicle manufacturers

in order to rely on the security capabilities of modules

offered by suppliers. Common Criteria, a standard for

IT security evaluation, speciﬁes methods and require-

ments for each Evaluation Assurance Level. Schmit-

tner et al. perform in [Schmittner and Ma, 2014] a

mapping of the levels deﬁned in Common Criteria

and the ASIL levels from ISO 26262. [Wooderson

and Ward, 2017] describe how the assessment as in

Common Criteria can be applied for cybersecurity in

vehicular systems. They further discuss the beneﬁts

and disadvantages of an internal assessment and an

independent certiﬁcation body.

We suggest, that evidence for compliance in form

of documents, such as the attack tree analysis or the

threat analysis and an overview how the identiﬁed

threats have been addressed, is sufﬁcient for lower

SLs. However, components requiring a SL of high

(3) or critical (4) need to provide a more detailed doc-

umentation on how the security measures are taken

into account.

As the SLs consist of a vector, it is possible to de-

ﬁne the level of detail for the required documentation

for each element (FR) of the vector. This way, it is

ensured that no unnecessary overhead for documenta-

tion has to be performed.

6 CONCLUSION

With the increasing functionality of modern vehicles,

it is essential to have a standardised security frame-

work for vehicles that speciﬁes the development life-

cycle as well as System Requirements (SRs). A stan-

dard, such as ISO 26262 for functional safety of road

vehicles, is needed so that all involved parties, e. g.,

manufacturer and suppliers, share the same under-

standing for automotive security.

We provide a study on several safety and security

standards from different domains and discuss speciﬁc

problems that have to be solved before a similar se-

curity standard can be introduced in the automotive

domain. Based on this, we suggest a representation

of Security Levels (SLs), how to map them to SRs,

and discuss how the security compliance of systems

and modules with a certain SL can be proven.

The number of SLs found to be suitable is ﬁve.

Having ﬁve SLs not only harmonises with ISO 26262,

it allows also a sufﬁcient guidance through specify-

ing system requirements and suitable security mech-

anisms. A higher number of levels leads to a stricter

guidance and would only increase the complexity of

the mapping to requirements. However, as shown in

IEC 62443 and two automotive security models, secu-

rity needs to address different attributes or categories,

e. g., conﬁdentiality and integrity. For this reason, we

propose to deﬁne one SL for each category and conse-

quently use a vector for representation. Due to the use

of a vector, we also suggest to include safety as one

element in order to provide a matrix that presents all

safety and security demands, as safety measures may

interfere with security. Furthermore, we propose the

use of a capability SL (SL-C), similar to IEC 62443,

to be used as a classiﬁer for the security of third-party

modules and all in-house developed modules.

Providing guidance in the process of mapping SLs

to system requirements as part of a security frame-

work has beneﬁts, such as a common understanding

of the required security for each level, and the com-

pliance of products from suppliers. Adding recom-

mendations for how to implement certain SRs by pro-

viding suitable mechanisms, further guides the devel-

oper. It has to be highlighted that such recommenda-

tions need to be continuously maintained and updated

as security mechanisms might have to be revised due

to published exploitation methods.

The evaluation and compliance of components is

important for the vehicle manufacturer. During the

concept and design phase it has to be known what

the system or subsystems need to be capable of and

what components provided by suppliers are capable

of. For lower SLs, we believe that the documenta-

tion of the threat analysis and attack tree analysis to-

gether with documented proof providing information

how these security requirements have been handled,

is sufﬁcient. For the SL high and critical, we propose

to adapt Common Criteria according to the speciﬁc

needs in the automotive domain.

In future work, the detailed security requirements

and mechanisms have to be identiﬁed, evaluated for

their applicability in the automotive domain, and

mapped to SLs. Additionally, it is necessary to in-

clude this proposed structure in a security framework

that is suitable for this domain.

ACKNOWLEDGMENT

This research was funded by the HoliSec project

(2015-06894) funded by VINNOVA, the Swedish

Governmental Agency for Innovation Systems.

Open Problems when Mapping Automotive Security Levels to System Requirements

259

REFERENCES

Blanquart, J.-P., Astruc, J.-M., Baufreton, P., Boulanger, J.-

L., Delseny, H., Gassino, J., Ladier, G., et al. (2012).

Criticality categories across safety standards in differ-

ent domains. ERTS-2012, Toulouse, pages 1–3.

Burton, S., Likkei, J., Vembar, P., and Wolf, M. (2012). Au-

tomotive functional safety = safety + security. In Pro-

ceedings of the First International Conference on Se-

curity of Internet of Things - SecurIT 12. Association

for Computing Machinery (ACM).

Checkoway, S., McCoy, D., Kantor, B., Anderson, D.,

Shacham, H., Savage, S., Koscher, K., et al. (2011).

Comprehensive experimental analyses of automotive

attack surfaces. In USENIX Security Symposium. San

Francisco.

ENISA (2016). Cyber Security and Resilience of smart

cars. Technical report, The European Union Agency

for Network and Information Security (ENISA).

ETSI, TS (2011). 102 165-1: Telecommunications and In-

ternet converged Services and Protocols for Advanced

Networking (TISPAN). Methods and protocols.

Hawkins, T. R., Gausen, O. M., and Strømman, A. H.

(2012). Environmental impacts of hybrid and elec-

tric vehicles—a review. The International Journal of

Life Cycle Assessment, 17(8):997–1014.

Henniger, O., Apvrille, L., Fuchs, A., Roudier, Y., Rud-

dle, A., and Weylr, B. (2009). Security requirements

for automotive on-board networks. In 2009 9th In-

ternational Conference on Intelligent Transport Sys-

tems Telecommunications, (ITST). Institute of Electri-

cal and Electronics Engineers (IEEE).

IEC 62443 (2013). IEC 62443 – Industrial communication

networks - Network and system security. Standard,

International Electrotechnical Comission.

Islam, M. M., Lautenbach, A., Sandberg, C., and Olovsson,

T. (2016). A risk assessment framework for automo-

tive embedded systems. In Proceedings of the 2nd

ACM International Workshop on Cyber-Physical Sys-

tem Security - CPSS 16. Association for Computing

Machinery (ACM).

ISO 15408 (2009). ISO/IEC 15408:2009 Information tech-

nology – Security techniques – Evaluation criteria for

IT security. Standard, International Organization for

Standardization (ISO).

ISO 26262 (2011). ISO 26262:2011 Road Vehicles – Func-

tional Safety. Standard, International Organization for

Standardization (ISO).

Kiening, A., Angermeier, D., Seudie, H., Stodart, T., and

Wolf, M. (2013). Trust assurance levels of cybercars

in V2X communication. In Proceedings of the 2013

ACM workshop on Security, privacy & dependability

for cyber vehicles - CyCAR 13. Association for Com-

puting Machinery (ACM).

Macher, G., Sporer, H., Berlach, R., Armengaud, E., and

Kreiner, C. (2015). SAHARA: A security-aware haz-

ard and risk analysis method. In Design, Automation

& Test in Europe Conference & Exhibition (DATE),

2015. EDAA.

Microsoft Corporation (2005). The stride threat

model. Available at https://msdn.microsoft.com/en-

us/library/ee823878.aspx.

Miller, C. and Valasek, C. (2014). A survey of remote auto-

motive attack surfaces. Black Hat USA.

MISRA C:2012 (2013). MISRA C: Guidelines for the Use

of the C Language in Critical Systems 2012. Motor

Industry Research Association.

NIST SP 800-53r4 (2013). NIST Special Publication 800-

53 – Security and Privacy Controls for Federal In-

formation Systems and Organizations. Standard, Na-

tional Institute of Standards and Technology.

RCTA DO-254 (2000). Design assurance guidance for air-

borne electronic hardware. Standard, RTCA and EU-

ROCAE.

RTCA DO-178 (2011). Software considerations in airborne

systems and equipment certiﬁcation. Standard, RTCA

and EUROCAE.

Ruddle, A., Ward, D., Weyl, B., Idrees, S., Roudier, Y.,

Friedewald, M., Leimbach, T., et al. (2009). Deliver-

able D2.3: Security requirements for automotive on-

board networks based on dark-side scenarios. Deliver-

able, E-safety vehicle intrusion protected applications

(EVITA).

SAE J1939 (2013). Serial Control and Communications

Heavy Duty Vehicle Network - Top Level Document.

Technical report, SAE International.

SAE J3061 (2016). SAE J3061: SURFACE VEHI-

CLE RECOMMENDED PRACTICE - Cybersecurity

Guidebook for Cyber-Physical Vehicle Systems. Stan-

dard, SAE International.

Schmittner, C. and Ma, Z. (2014). Towards a framework

for alignment between automotive safety and security

standards. In International Conference on Computer

Safety, Reliability, and Security, pages 133–143.

Schmittner, C., Ma, Z., and Schoitsch, E. (2015). Com-

bined safety and security development lifecylce. In

2015 IEEE 13th International Conference on Indus-

trial Informatics (INDIN). Institute of Electrical and

Electronics Engineers (IEEE).

SEI CERT C (2016). Sei cert c coding standard rules for

developing safe, reliable, and secure systems. book,

Carnegie Mellon University.

Wooderson, P. and Ward, D. (2017). Cybersecurity testing

and validation. In SAE Technical Paper. SAE Interna-

tional.

Yan, W. (2015). A two-year survey on security challenges

in automotive threat landscape. In 2015 Interna-

tional Conference on Connected Vehicles and Expo

(ICCVE). IEEE.

VEHITS 2018 - 4th International Conference on Vehicle Technology and Intelligent Transport Systems

260