Probabilistic Modeling and Simulation ofVehicular Cyber Attacks: An Application of the

Meta Attack Language

Sotirios Katsikeas1, Pontus Johnson1, Simon Hacks2, and Robert Lagerstrom1

1KTH Royal Institute of Technology, Stockholm, Sweden{sotkat, pontusj, robertl}@kth.se

2RWTH Aachen University, Aachen, Germanyhacks@swc.rwth-aachen.de

Abstract. Attack simulations are a feasible mean to assess the cybersecurity of systems. The simulations trace the steps taken by an attackerto compromise sensitive system assets. Moreover, they allow to estimatethe time conducted by the intruder from the initial step to the com-promise of assets of interest. One commonly accepted approach for suchsimulations are attack graphs, which model the attack steps and theirdependencies in a formal way.To reduce the effort of creating new attack graphs for each system ofa given type, domain-specific attack languages may be employed. Theycodify common attack logics of the considered domain. Consequently,they ease the reuse of models and, thus, facilitate the modeling of aspecific system in the domain. Previously, MAL (the Meta Attack Lan-guage) was proposed, which serves as a framework to develop domainspecific attack languages.In this article, we present vehicleLang, which can be used to design ve-hicles with respect to their IT infrastructure and to analyze their weak-nesses. To model domain specifics in our language we rely on existingliterature and verify the language using an interview with a domain ex-pert from the automotive industry. To evaluate our results, we perform aSystematic Literature Review (SLR) to identify possible attacks againstvehicles. Those attacks serve as a blueprint for test cases checked againstthe vehicleLang specification.

Keywords: Domain Specific Language, Cyber Security, Threat Model-ing, Attack Graphs, Vehicular Security

1 Introduction

Vehicles, especially passenger cars, are ubiquitous in European countries andtheir amount is still rising. For example, from January 2009 to January 2018the number of registered passenger cars was increased by nearly 18% in Sweden[61] and 12.5% in Germany [33]. This means that 62% of Swedes and 56% ofGermans owned a car in average in January 2018. Simultaneously, IT-systems

Non pu

blish

ed dr

aft

pervade vehicles more and more to increase driving security and user experience.Contemporaneously, the number of IT related security issues grows as well [63].This raises the need to assess the cyber security of vehicles.

However, assessing the cyber security of computing systems in general andof vehicles in special is difficult. In order to identify vulnerabilities, the security-relevant parts of the system must be understood, and all potential attacks haveto be identified. There are three challenges related to these needs: Firstly, it ischallenging to identify all relevant security properties of a system. Secondly, itmight be difficult to collect this information. Lastly, the collected informationneeds to be processed to uncover all weaknesses that can be exploited by anattacker.

Hitherto, we have proposed the use of attack simulations based on systemarchitecture models [11,19,24,59] to support these challenging tasks. Our ap-proaches facilitate a model of the system and simulate cyber attacks in orderto identify the greatest weaknesses. This can be imagined as the execution of agreat number of parallel virtual penetration tests. Such an attack simulation toolenables the security assessor to focus on the collection of the information aboutthe system required for the simulations, since the first and third challenges aretackled by the simulation.

As the previous approaches rely on a static implementation, we propose MAL(the Meta Attack Language)1 [23]. This domain-specific language defines whichinformation about a system is required and specifies the generic attack logic. AsMAL is a meta language, no certain domain of interest, like vehicle security, isrepresented. Therefore, this work aims to create and evaluate a domain-specific,probabilistic modeling language for simulation of cyber attacks on modern con-nected vehicles, so called vehicleLang, (cf. Figure 1).

Fig. 1. Meta modeling hierarchy

To create vehicleLang, we follow the means of DSR (Design Science Research)as presented by Peffers et al. [51]. Therefore, we conduct a domain survey to ex-tract a feature matrix containing all the security assets, the possible attacks andthe corresponding defenses. This feature matrix serves as input to compile adetailed list of all the possible attacks following some widely used attack clas-

1 www.kth.se/profile/robertl/page/mal-the-meta-attack-language

Non pu

blish

ed dr

aft

sifications and taxonomy frameworks. Subsequent, vehicleLang is constructedand evaluated. The created artifact is limited to the internal networks of thevehicles (i.e., CAN bus, FlexRay, and LIN bus) and the attacks that are related.However, it is scheduled to extend vehicleLang to other parts as well.

The remainder of the paper is structured as follows. Section 2 considers re-lated work, followed by Section 3 describing the applied methodology. In Section4 we present the MAL and its syntax to provide the framework for vehicleLang,which is presented with the core language in Section 5. The language itself isevaluated by a number of test cases depicted in Section 6. Finally, the paper isconcluded in Section 7.

2 Related work

Our work relates to three domains of previous work: model-driven security engi-neering, attack/defense graphs, and car security. First, in model-driven securityengineering were domain-specific languages for security analysis of software andsystem models defined as vehicleLang is one. Second, attack/defense graphs areapplied as formalism for its analysis. Last, besides the fact that vehicleLang isin the domain of car security, the results of existing car security research areutilized for evaluation.

Model-driven security engineering induced a large number of domain-specificlanguages like UMLsec [26,27], SecureUML [3,4], SECTET [1,15], or STS-ml [50].These languages facilitate the capability to model a system’s design accordingto components and their interaction. Furthermore, they enable to model alsosecurity properties such as constraints, requirements, or threats. They are buildupon different formalisms and logics like the Unified Modelling Language andthe Object Constraint Language. Model checking and searches for constraintviolations are applied to conduct security analysis in these languages.

Apart from the languages mentioned before, there exist some security lan-guages which do not support automated analysis purposes, such as CORAS [36],secureTROPOS [42] and SecDSVL [2]. They offer only the capability to modelsecurity relevant properties. An analysis needs to be conducted manually withoutany further support.

The concept of attack trees is commonly based on the work of Bruce Schneier[56,57]. They were formalized by Mauw & Oostdijk [37] and extended to includedefenses by Kordy et al. [29]. As summarized in [30], there are several approacheselaborating on attack graphs, e.g. [22,32,49,68]. Elaborating on the theoreticalachievements of the beforehand presented papers, different tools using attackgraphs were developed. These tools mostly build up on collecting informationabout existing system or infrastructure and automatically create attack graphsbased on this information. For example, MulVal [21,48] derives logical attackgraphs by associating the vulnerabilities extracted from scans with a probability.This probability expresses how likely an attacker is to exploit the vulnerabilitysuccessfully. MulVAL is extended by k-Zero Day Safety [66] to compute zero-dayattack graphs. NAVIGATOR [7] considers identified vulnerabilities as directly

Non pu

blish

ed dr

aft

exploitable by the attacker, given that she has access to the vulnerable system.The TVA tool [47] models security conditions in networks and uses a databaseof exploits as transitions between these security conditions. Similarly, NetSecuri-tas [14] composes scanners output and known exploits to generate attack graphsand corresponding security recommendations.

A sub domain of attack graph modelling are probabilistic attack graphs, e.g.,facilitating Bayesian networks. In [13], the authors apply the TVA-tool to gen-erate attack graphs, transform them to dynamic Bayesian networks, and enrichthem with probabilities using CVSS (Common Vulnerability Scoring System)scores. CVSS is also utilized by [71] to model uncertainties in the attack struc-ture, attacker’s actions and alerts triggering. In [53] a genetic algorithm is usedto produce a security mitigation plan, which takes Bayesian attack graphs as aninput to estimate the security risk on network systems.

All before mentioned approaches have in common not to be model based.Therefore, we have combined attack graphs and system models in our previ-ous work: CySeMoL [59], P2CySeMoL [19], pwnPr3d [24], and securiCAD [11].The central idea of these works is to automatically generate probabilistic attackgraphs from a given system specification. The attack graph serves as inferenceengine that produces predictive security analysis results from the system model.

To the best of our knowledge, there exists no research in the direction of prob-abilistic attack graph modelling within the domain of vehicle security. Therefore,we relate following to work elaborating on vehicle hacking. A first impression onthe domain of vehicle hacking can be received by the work of Wolf [69] andSmith [58]. First, the authors give insides into vehicles’ IT architectures whichcontributes to the general construction of our instance of MAL. Second, theydepict different ways to compromise various components of the vehicle underinvestigation.

More detailed attack scenarios are given by different authors e.g. Wolf et al.[70], Takahashi et al. [64], or Cho and Shin [6]. The first two work concentrateon attacking the bus of the vehicle. In [70] the authors attack different bus andshow their weaknesses as well as the weaknesses of future bus. To strengthenvehicle’s security, they also propose a secured communication along the variousbuses. In contrast to Wolf et al., Takahashi et al. [64] focus on LIN bus (LocalInterconnect Network). They show possible attacks on this elementary vehiclecommunication system in different case studies. Furthermore, they contributedifferent countermeasures to rise vehicle’s security. The last work by Cho andShin [6] attacks ECU (Electronic Control Units) using DoS (Denial-of-Service).For this purpose, they facilitate the error-handling scheme of in-vehicle networkto shut down or disconnect the ECU. Additionally, they suggest and evaluateapproaches to detect and prevent their attack.

3 Methodology

DSR is a widely applied and accepted mean for developing artifacts in infor-mation systems (IS) research. It offers a systematic structure for developing

Non pu

blish

ed dr

aft

artifacts, such as constructs, models, methods, or instances [18]. As our researchobjective indicates the development of an artifact, the application of a DSR isappropriate. We stick to the approach of Peffers et al. [51], since it transpired aseffective in former research. It is split up into six single steps and two possiblefeedback loops (cf. Figure 2).

Fig. 2. Design Science Research Process

The first two steps of DSR are already presented within the introduction. Todesign our artifact we based our attack language on the MAL [23]. To modeldomain specifics in our language we rely on existing literature as presented inrelated work and we verified it against a conducted interview with a domain ex-pert from the automotive industry. Moreover, the modeled language is reviewedon a weekly to biweekly basis to ensure correctness and completeness.

To evaluate our artifact we applied test cases, which can be differentiated intotwo classes. First, there are unit tests to ensure that there are no mistakes inthe implementation of specific attack steps and classes. Those are implementedby the researcher developing the language itself and a researcher developing alanguage related to vehicleLang. Second, we created integration tests based onan attack list, which was created applying a SLR (Systematic Literature Review)following the approach of Webster and Watson [67]. Moreover, the test cases arean instantiation of the vehicleLang and, thus, serve as demonstration.

4 The Meta Attack Language

As already presented, this attack language relies on the MAL (Meta AttackLanguage) [23]. Therefore, this section presents the core parts of the grammar

Non pu

blish

ed dr

aft

(syntax) for MAL. For the formalism behind the language and details we referto the original work.

MAL mainly consists of classes (e.g., Car), their instance (i.e., myCar), attacksteps on classes (e.g., Car.hijack), and defenses on classes (e.g., Car.immobilizer).Furthermore, the entities of MAL are related to each other. Classes, and re-spectively their instances, can be linked to each other (e.g., Garage.parked =

{Car}). Attack steps are connected to each other, thus the successful compromiseof one step leads to the second step (e.g., e = (Garage.open, Garage.parked.accessible)).Additionally, attack steps can be either of the type OR or AND, signifying ei-ther one of its parental steps is needed to elaborate on this step (OR) or all stepsare needed (AND). Lastly, defenses are parenting attack steps which they hinderto be performed if they are TRUE (e.g., (Car.immobilizer, Car.drive) ∈ E).

To each attack step a probability distribution can be associated describingthe expected time to perform this step, so called local time to compromise. Sim-ulating different attackers behaviour on the modelled MAL attack graph allowsto calculate the global time to compromise. This value provides a measure of howsecure various points of the system are in respect to attack resilience. Further,it facilitates a quantitative way of comparing systems designs.

Classes containing attack steps constitute the core entities of a MAL speci-fication. A class is specified as such:

class Garage {

| open

-> parkedVehicle.accessible

}

Garage is the name of the class, and open is the name of its unique attackstep. | symbolizes that the attack step is of the type OR. AND is representedby the symbol &, while defenses are denoted by a #. The arrow, ->, signifiesthat the compromise of attack step open allows for an attack on the attacksteps parkingSpace.accessible. parkingSpace is an association role, which isdefined in a separate part of the MAL specification:

associations {

Vehicle [parkedVehicle] 0-2 <-- Parking --> 1 [isParked] Garage

}

Association ends are bound to types with cardinalities like UML class dia-grams. In this example, an object of the class Garage can be connected to upto two objects of the class Vehicle. Both ends of an association have roles,which are used for navigation. Thus, myGarage.parkedVehicle refers to the setof Vehicle objects connected to myGarage. Consequently, a compromise of theGarage.open attack step enables the attacker for an attack on the accessible

step of the connected Vehicle objects, i.e. the Garage’s parkedVehicle.MAL features inheritance in a manner similar to other object-oriented lan-

guages. It allows to define abstract classes that are only intended for specializa-tion, and never instantiated. Following, Vehicle is an abstract class, specialized

Non pu

blish

ed dr

aft

into the concrete classes Car and Bicycle, which inherit the attack steps andassociations of Vehicle. Car adds a further required attack step key to be ableto drive the Car.

abstractClass Vehicle {

| accessible

-> drive

& drive

}

class Bicycle extends Vehicle {

}

class Car extends Vehicle {

| key

-> drive

& drive

}

Some steps may be accomplished without effort. For instance, as soon as abicycle is accessible to the attacker, she is able to drive the bicycle. However,sometimes attack steps require a certain amount of time. Therefore, it is possiblefor each attack step to specify the required time. For example, the time to short-circuit a Car takes a mean of 12 minutes and a standard deviation of 5 minutesspecified by a Gamma distribution. This can be specified as follows:

class Car {

& short-circuit [GammaDistribution(24, 0.5)]

}

Objects can be configured at the time of instantiation which is used for mod-elling defenses. For example, some instances of the class Car should have an im-mobilizer, while others do not have one. In this case, the defense Car.immobilizermay be introduced. # represent defenses and boolean values indicate defense’sstatus. Technically, each defense includes an attack step. If the defense is false,then the associated attack step is marked as compromised at the time of instan-tiation. Following example facilitates effect’s comprehension:

class Car {

| accessible

-> short-circuit

& short-circuit

# immobilizer

-> short-circuit

}

If Car.immobilizer is false, then the attacker will be able to reach theand attack step short-circuit as soon as she has reached accessible. If,instead, Car.immobilizer is true, then short-circuit will not be reached, asit’s compromise requires the compromise of both parents.

Non pu

blish

ed dr

aft

5 The Vehicular Cyber Attack Language

Beforehand, we presented the foundations underlying the MAL and its syntax.Following, we will present, first, a core language containing common IT entities,and, second, vehicleLang covering all the basic assets that comprise the internalvehicle’s network, from ECUs and vehicle’s networks up to applications andservices running on top of them. The core (light blue) and the extensions madeby vehicleLang (dark blue) are depicted in Figure 3. The elements in gray arealso part of the core, but have been changed within vehicleLang.

MachineMachine

ECUECU GatewayECUGatewayECU

SoftwareSoftware0-1 *

Execution

0-1 *

Execution

AccountAccount

1-*

*

Assignment

1-*

*

Assignment

AccessPrivileges, ConnectionPrivilegesAccessPrivileges, ConnectionPrivileges

UserUser

UserAccountUserAccount

AuthenticationAuthentication

CredentialsCredentials

CredentialsCredentials

DataDataRead, Write, DeleteRead, Write, Delete

ContainmentContainment

InformationInformation*

0-1

Representation*

0-1

Representation

StorageStorage

NetworkNetwork

DataflowDataflowCommunicationCommunication

0-1

0-1

Transmission

0-1

0-1

Transmission

IDPSIDPS

VulnerabilityVulnerability

0-1

*

ConnectionVulnerability,AccessVulnerability

0-1

*

ConnectionVulnerability,AccessVulnerability

*

1-*

Privileges*

1-*

Privileges

VehicleNetworkVehicleNetwork

FirmwareFirmware1

0-1

Firmware Execution

1

0-1

Firmware Execution

Assets included on the vehicleLang

ConnectionConnection

IDPSProtectionIDPSProtection

ClientClient ServiceService

NetworkClientNetworkClient NetworkServiceNetworkService

RequestRequest ResponseResponse

CANnetworkCANnetwork FlexRayNetworkFlexRayNetwork LINnetworkLINnetwork

Legend: Core language assets Modified core language assets New assets introduced by vehicleLang

Legend: Core language assets Modified core language assets New assets introduced by vehicleLang

Fig. 3. Model of vehicleLang

5.1 Core Language

The core language consists mainly of entities representing Machine, Vulnerability,Account, Data, Dataflow, and Network. There are still more entities, but in thefollowing, we will focus on the previously mentioned. A Machine represents at-tackable entities (i.e., hard- and software) of a system under investigation and,thus, are exposed by a Vulnerability. A Vulnerability can be exploited by auser represented by an Account. An Account can also be capable to read, write,and delete Data which is stored on a Machine. Two Machines can exchange Datafacilitating a Dataflow on a Network.

Non pu

blish

ed dr

aft

Following we will explore those entities with more detail and depict how theyand their interrelations are modelled. If one connects to a Machine, one can tryto authenticate to get access to the Machine. Another way to get access to aMachine is to bypassAccessControl. If an attacker achieved access to a Machine,she can connect to all executees (i.e., executed Software on this Machine),requestAccess to all stored Data, and start denialOfService attacks, which can beexecuted against the executees or to denyAccess of certain Data. Without beingauthenticated the attacker is, first, able to compromise all privileges related tothe connection and, second, to exploit the vulnerability related to an account togain its privileges.

As far as the attacker reached the Vulnerability, she can try to exploit it.We assume that her time consumption to exploit the Vulnerability is given byan exponential distribution with a rate parameter of 10. A successful exploitedVulnerability leads to compromised privileges of all related Accounts.

An Account can be compromised by either exploiting a Vulnerability orauthenticating (e.g., stealing the Credentials). A compromised Account allowsto overtake other Accounts (e.g., a super user can authenticate as each otheraccount on a machine) and use their privileges. Moreover, an attacker can au-thenticate at other Machines, which use the same Account. Last, an attacker iscapable of reading, writing, and deleting Data on a Machine.

Data is a recursive entity as it can store other Data inside itself. Consideringthe basic attack steps of Data, there are three: read, write, and delete. To getto these attack steps, the attacker needs to requestAccess and the used Account

must have granted the corresponding privileges (e.g., anyAccountRead). Theattack steps read, and delete behave intuitively. In contrast, write allows also todelete Data and to tamper Data on the Dataflow. The attack step denyAccessis the result of a denialOfService and prevents the accessibility of the data.

A Dataflow is a logical communication between two Software applications.It allows several different attack steps. First, an attacker can eavesdrop on theDataflow and, therefore, she can read the contained data. Second, an attackercan try to carry out a man-in-the-middle attack on the data flow. This leads tothe control of the contained Data. In both cases, that Data may be encrypted andauthenticated, thus preventing a breach of confidentiality and integrity. Besidesreading, writing, and deleting, a manInTheMiddle allows also maliciousRequestsand maliciousResponds.

A Network is a physical connection between Machines like Ethernet LANs,the Internet, and Wifi networks. Basically, it provides access to its Dataflows

and enables the attacker to perform denialOfService, manInTheMiddle, andeavesdrop attacks.

5.2 vehicleLang

vehicleLang extends the core by adding Firmware, ECU, and VehicleNetwork.The Firmware, which is some kind of Software, runs on the ECU, which is derivedfrom a Machine. Besides the “simple” ECU, there is also a GatewayECU whichacts as gateway to the Network. Moreover, a GatewayECU offers the possibility

Non pu

blish

ed dr

aft

to activate a firewall and an IDPS to prevent certain attack steps. The ECUs areconnected via the VehicleNetwork to exchange data with each other.

An ECU specifies any ECU, or controller in a vehicle. An ECU is an embeddedsystem in a vehicle controlling one or more electrical system or subsystems likethe anti-lock braking system. A vehicle can contain up to 80 ECUs [10]. We modelit as an extension of the existing concept of a Machine, since an ECU offers manyattacks that are not related to the abstract type of a Machine. If an attackeris connected to an ECU she can try to get access to the ECU, attemptChangeOp-erationMode, or to modify the Firmware. After compromising ECU’s Firmware,bypassingAccessControl, or properly authenticating, the intruder has access to theECU. The access to an ECU can be utilized to changeOperationMode, gainLINAc-cessFromCAN [64], modify the Firmware, or execute a serviceMessageInjectionon the related Services running on this ECU.

A changeOperationMode puts the ECU into diagnostics, which is usually usedfor service mechanics to seek for failures of the system, or into update mode,which is e.g. utilized to install a new Firmware. An ECU in these modes willno longer send messages and an attacker can imitate it, if she is careful, thus,executing a bypassMessageConfliction. Furthermore, the changeOperationModecan be protected by the defense operationModeProtection. It either preventsdiagnostics mode after vehicles starts moving or allows diagnostics mode onlyafter some physical change is done on the vehicle (e.g. a physical switch pressedby the mechanic).

bypassMessageConfliction enables the attacker to inject forged service mes-sages that could notify about vehicle’s fault or report fake status like speedor operation mode. This can lead to an unresponsive ECU (denialOfService) orallows to inject messages for the services running on this ECU (serviceMessageIn-jection). It is also possible to defend against serviceMessageInjection by usingmessage confliction mechanisms, which act like a host-based IDPS (IntrusionDetection and Prevention System) [28]. A host-based IDPS monitors and an-alyzes the internals of a computing system as well as the network packets onits network interfaces. Therefore, it observes the inbound and outbound packetsfrom the device and alerts if suspicious activities are detected [44].

A GatewayECU is a specialization of an ECU that acts as a gateway on a ve-hicle. A GatewayECU contains additionally an inline IDPS and a firewall. Aninline IDPS scans the passing through traffic of a network in real time and an-alyzes it following defined rules to decide if an attack is already running [41].The firewall is modelled as a defense firewallProtection on the attack step by-passFirewall. Mainly, firewallProtection should be TRUE if there is a correctlyconfigured firewall in place. Similar to this, the IDPS is modelled as defenseon gatewayIDPS. If the defense is FALSE, the attacker can access the networkunrestricted, thus, she can connect to all related VehicleNetworks.

Furthermore, a GatewayECU offers forwarding as the lightest interaction withthe router, where the router simply re-transmits received messages. Vulnerabili-ties may, however, lead to compromise of the router as well as of the associatedfirewall. Therefore, forwarding leads to connect.

Non pu

blish

ed dr

aft

Firmware is a specialization of Software and is in our case related to thefirmware running on an ECU. The attacker tries to ulpoadForgedFirmware, sincethis leads to full access on the ECU and messageInjection capabilities to the con-nected Networks. The attacker has to successfully perform the firmwareMod-ification so that the ECU will execute it [69]. During the firmwareModificationthe forged Firmware has to be validated. A firmware is usually equipped witha checksum based on the principle of digital signatures to empower the ECU

to check if the Firmware is trustworthy. The attacker can either perform thefirmwareModification by having the keys to sign it (passFirmwareValidation),by cracking the checksum (crackFirmwareValidation), or by exploiting the ab-sence of verification (bypassFirmwareValidation). We put in a defense for by-passFirmwareValidation by code signing and verification during upload, the useof strong checksum functions and no distribution of the private keys for signing.

The VehicleNetwork extends the Network of the core language and serves asabstract layer containing the common attack steps and relations of its specializa-tions CANNetwork, FlexRayNetwork, and LINNetwork. E.g., accessNetworkLayerimplies the possibility to transmit messages over the network. But, it does notimply the possibility to listen to others’ traffic on the network, because the at-tacker is outside theGatewayECU but with a possibility to communicate in to thenetwork. Therefore, she is able to connect to all related ECU, perform a network-SpecificAttack, or execute a messageInjection. However, the eavesdrop attack isstill inherited from the Network.

Even if there is an IDPS in action, maliciousRequests/maliciousResponds canbe applied directly, because manInTheMiddle attacks are not easily, or not atall, detected by an IDPS. Third, an injection can be performed, but only fromVehicleNetwork using a messageInjection. An injection means that an attackercan make maliciousRequests easily but must try hard to make maliciousRe-sponds, because an IDPS may recognize those. Next, the attacker may tamperthe Data, and, last, execute a denialOfService, which leads to the deletion of thetransmitted Data.

A maliciousRequest/maliciousRespond allows to connect to the Machine ontop of which the Service or Client is running, respectively. For the purpose ofprotection an IDPS can be deployed which enforces the attacker in some casesto bypass it. As this takes time, we use an exponential distribution with a rateparameter of 6.13 to estimate the time consumption [20,60].

A CANNetwork represents the CAN bus network which is a soft real-time con-trol network used for e.g. anti-lock breaking or engine control [69]. It is subjectto two CAN related attacks: exploitArbitration, and busOffAttack. To exploitAr-bitration for message prioritization in CANNetwork can lead to invalidation oflegitimate messages and allows tampering with the Dataflow. exploitArbitrationis different from the messageInjection attack, because it allows direct maliciousrespond and request.

A busOffAttack exploits the error-handling scheme of in-vehicle networks todisconnect or shutdown not compromised ECUs [6]. The busOffAttack is easyto mount if the attacker has access to a CANNetwork or specializations of it,

Non pu

blish

ed dr

aft

because the attacker only needs to find messages which are sent periodically.Consequently, a costly reverse-engineering of messages or the network is notnecessary. Additionally, an IDPS cannot differentiate between the injected mes-sages and error messages. Therefore, an attacker who has access to a CANNetwork

can apply directly a busOffAttack and a denialOfService to all connected ECU,no matter if there is an IDPS in place or not.

Cho and Shin [6] propose a protection against the busOffAttack, which ismodeled with the defense busOffProtection. In this case, the busOffAttack cannotbe performed against the ECU. In reality, this defense is two fold. First, more than16 consecutive error frames indicate a busOffAttack. However, some errors canproduce also so many consecutive error frames. Therefore, second, the ECU sendsa message to the CANNetwork and observes if there will be another message withthe same ID which is not allowed on a CANNetwork. Consequently, there mustbe a busOffAttack and the ECUs can be modified in a way that they do not gotshout down.

The FlexRayNetwork is a hard real-time control network used for X-by-wire applications e.g. break-by-wire or emergency braking systems. It allowsthree special kinds of attacks: commonTimeBaseAttack, exploitBusGuardian,and sleepFrameAttack. The attacker sends for a commonTimeBaseAttack morethan defined messages within one certain timeframe to make the whole net-work inoperable [69, p. 103]. Consequently, this leads to a denialOfService of theFlexRayNetwork.

The Bus Guardian is usually a part of a FlexRayNetwork connected ECU andregulates the access to the bus for sending messages to certain, defined timeperiods [62]. This Bus Guardian is utilized in the exploitBusGuardian attack forsending well-directed faked error messages to deactivate ECUs [69]. Therefore,on all FlexRayNetwork connected ECUs a shutdown can be performed. However,the Bus Guardian mechanism is hardened and, therefore, an attacker may needto spend much effort [43].

The sleepFrameAttack results also in the shutdown of all connected ECUs. Forthis purpose, the attacker sends well-directed forged sleep frames to deactivatepower-saving-capable FlexRay ECU [69]. This takes her an effort expressed by anexponential distribution with a key parameter of 10. If FlexRay power-savingis enabled, the sleepFrameAttack cannot be performed, which is modelled asdefense powerSavingIncapableNodes.

A LINNetwork is a low-level non-real-time subnet which is used for e.g. doorlocking or light sensors. The attacker can easily gainLINAccessFromCAN fromthe ECU [31,54] on the LINNetwork and, consequently, perform the attack stepaccessNetworkLayer. Another possible attack on the LINNetwork is injectBo-gusSyncBytes. To perform this attack, the attacker sends frames with bogussynchronization bytes within a SYNCH field. This makes the local LIN networkinoperative or causes at least serious malfunctions [69]. This leads in our modelto a denialOfService of the LINNetwork.

A specific attack on the LINNetwork which exploits the error handling mech-anism is the injectHeaderOrTimedResponse. If the attack is successful, it allows

Non pu

blish

ed dr

aft

to tamper the Dataflow [64]. To overcome the shortcoming of the LINNetwork

Takahashi et al. [64] propose a protection against this attack, which is modelledas defense headerOrTimedResponseProtection in our model. Additionally, it isnot easy to exploit this attack [64].

6 Evaluation

According to Hevner et al. [18], five methods are possible to evaluate the outputof DSR: observations, analysis, experiments, tests, and descriptions. As devel-oping vehicleLang is similar to developing source code, we opt for testing asevaluation method. We ground our decision on the fact that testing is widelyspread in application development and commonly accepted as means to ensurethat an application behaves as intended.

More concretely, we apply two different kinds of testing. First, we implementunit tests to ensure that vehicleLang behaves like we expect it to. To ensureour results, we apply, additionally, cross checking by another developer, whoworks also on a realization of MAL. This cross checking includes a revisionof vehicleLang as well as the implementation of further unit tests to uncoverunintended behavior. Second, we implement integration tests. Those integrationtests rely on a compiled attack list created by a SLR.

Our SLR follows the methodology of Webster and Watson [67]. The scopeof the SLR is in line with the objectives of this paper, in other words, identi-fying attacks on the internal networks of vehicles. Therefore, we searched forthe terms “vehicle security”, “in-vehicle protocol security”, “CAN bus attacks”,“LIN bus attacks”, “FlexRay attacks”, “connected cars security”, and “auto-motive communication security” in title and abstract of articles in the GoogleScholar2, IEEE Xplore3, and Springer Books4 databases from 2006 to present.We scanned the abstracts of about 100 found results, filtered them with respectto their relevance to our research objective, and ended up with fourteen confer-ence papers [5,6,16,17,25,28,43,45,46,52,55,64,65,70], three long papers [9,38,40],five scientific books [8,35,39,58,69], and one ENISA (European Network and In-formation Security Agency) report [12] relevant to our objective. We completedthe SLR by conducting a back- and forward search which resulted in no moreadditional papers.

We scanned the identified literature and found 22 possible attacks on sevendifferent classes. We relate to each class its possible attacks and give a shortdescription of the attack steps. Furthermore, we refer to defenses which couldbe put in place to prevent the attack. We also kept track of the literature whichmentioned the attack, and linked to the the test cases which ensure the relatedbehavior.5

2 https://scholar.google.com3 http://ieeexplore.ieee.org/Xplore/home.jsp4 http://www.springer.com/gp/products/books5 The complete tables can be found in Appendices A.1 and A.2.

Non pu

blish

ed dr

aft

The following provides a sample test case as depicted in Figure 4. It is basedon a scenario where an attacker aims to perform a maliciousResponse on theOtherDataflow by using as entry point the physicalAccess to VehicleNetwork

vNet1. It simulates a VehicleNetwork with two ECUs, one running a Service

and one consuming it with a receiver acting as a Client. Each ECU is placed in itsown Network and the Networks are connected to each other via a GatewayECU.On this GatewayECU the firewall and the IDPS are unfortunately disabled. Theattacker initially has access to the Network of the ECU running the Service.Consequently, she can also compromise the Dataflows in this Network. However,she only reached (was able to connect to) the Services and the respectiveECU, but did not compromise them. Same holds for the other Network, sincethe attacker can compromise the Network, because the firewall and IDPS aredisabled, but she was not able to compromise the ECU and the correspondingClient.

Fig. 4. Sample Attack on Vehicle’s Network

To be more concrete, we give the implementation of the described test case inAppendix A.3 Listing 1.1. First, we create all entities contained in our test case(cf. lines 5 to 16). Second, we establish the connections between the entities likecommunication over a network or including each other (cf. lines 18 to 30). Third,we create an attacker (cf. line 32) and give her an entry point to the graph ofentities (cf. line 33). Fourth, we start the simulation (cf. line 34). Last, we checkwith assertions if the attacker could or could not achieve different attack stepsin our model.

7 Conclusions and Further Work

Assessing the cyber security of vehicles is becoming increasingly important asIT-systems and cyber-physical systems pervade vehicles more and more and,

Non pu

blish

ed dr

aft

simultaneously, the number of IT related security issues grows. Within this ar-ticle, we developed the vehicleLang based on the MAL. vehicleLang will fostersecurity analysts in the vehicle’s domain to model the vehicle and to focus on an-alyzing possible weaknesses. To model domain specifics in our language we relyon existing literature as presented in related work and we verified it against aconducted interview with a domain expert from the automotive industry. For thepurpose of evaluation, we performed an SLR to identify possible attacks againstvehicles. Those attacks served as a blueprint for test cases used to validate thevehicleLang specification.

Further work remains. First, we only included the internal networks of thevehicles (i.e., CAN bus, FlexRay, and LIN bus) and the connected componentsto them. Nevertheless, a vehicle comprises of further elements, which we didnot model so far, like the infotainment system and the connectivity with theInternet.

Second, our studies have shown that the expected time consumption of at-tackers is mostly unresearched in the domain of vehicle cyber security. Conse-quently, future research should elaborate on uncovering those numbers to createmore suitable models. As already mentioned, creating tests is feasible to evaluatean artifact, but, third, a real world evaluation of vehicleLang is still missing andshould be conducted in further extensions of our work.

The last point is not related to vehicleLang itself, but to MAL. MAL relieson a static model. This allows a fast computation of possible attack paths. Un-fortunately, the fast computation is bought by no dynamics in the model. Thus,a simulated attacker would not be able to create new entities during an intru-sion. In other words, we are not able to consider e.g. newly created servers oradditionally plugged entities. However, this sounds more problematic than it is,as most dynamic situations that are possible to model in a static model (e.g., byincluding the potential objects already from the start, but leaving them inactiveuntil reached by the attacker).

References

1. Alam, M., Breu, R., Hafner, M.: Model-driven security engineering for trust man-agement in sectet. JSW 2(1), 47–59 (2007)

2. Almorsy, M., Grundy, J.: Secdsvl: A domain-specific visual language to supportenterprise security modelling. In: Software Engineering Conference (ASWEC), 201423rd Australian. pp. 152–161. IEEE (2014)

3. Basin, D., Clavel, M., Egea, M.: A decade of model-driven security. In: Proceedingsof the 16th ACM symposium on Access control models and technologies. pp. 1–10.ACM (2011)

4. Basin, D., Doser, J., Lodderstedt, T.: Model driven security: From uml modelsto access control infrastructures. ACM Transactions on Software Engineering andMethodology (TOSEM) 15(1), 39–91 (2006)

5. Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S.,Koscher, K., Czeskis, A., Roesner, F., Kohno, T., et al.: Comprehensive experi-mental analyses of automotive attack surfaces. In: USENIX Security Symposium.San Francisco (2011)

Non pu

blish

ed dr

aft

6. Cho, K.T., Shin, K.G.: Error handling of in-vehicle networks makes them vulner-able. In: Proceedings of the 2016 ACM SIGSAC Conference on Computer andCommunications Security. pp. 1044–1055. CCS ’16, ACM, New York, NY, USA(2016)

7. Chu, M., Ingols, K., Lippmann, R., Webster, S., Boyer, S.: Visualizing attackgraphs, reachability, and trust relationships with navigator. In: Proc. of the 7thInt. Symp. on Visualization for Cyber Security. pp. 22–33. ACM (2010)

8. Corchado, E., Zunino, R., Gastaldo, P.: Proceedings of the International Workshopon Computational Intelligence in Security for Information Systems CISIS 2008,vol. 53. Springer Science & Business Media (2008)

9. Currie, R.: Hacking the can bus (2017)10. Ebert, C., Jones, C.: Embedded software: Facts, figures, and future. Computer

42(4), 42–52 (Apr 2009)11. Ekstedt, M., Johnson, P., Lagerstrom, R., Gorton, D., Nydren, J., Shahzad, K.:

securiCAD by foreseeti: A CAD tool for enterprise cyber security management. In:Enterprise Distributed Object Computing Workshop (EDOCW), 2015 IEEE 19thInternational. pp. 152–155. IEEE (2015)

12. enisa: Cyber security and resilience of smart cars: Good practicesand recommendations. https://www.enisa.europa.eu/publications/

cyber-security-and-resilience-of-smart-cars/at_download/fullReport

(2016), [Online; accessed 10-April-2018]13. Frigault, M., Wang, L., Singhal, A., Jajodia, S.: Measuring network security using

dynamic bayesian network. In: Proc. of the 4th ACM workshop on Quality ofprotection. pp. 23–30. ACM (2008)

14. Ghosh, N., Chokshi, I., Sarkar, M., Ghosh, S.K., Kaushik, A.K., Das, S.K.: NetSe-curitas: An integrated attack graph-based security assessment tool for enterprisenetworks. In: Proc. of the 2015 Int. Conf. on Distributed Computing and Network-ing. p. 30. ACM (2015)

15. Hafner, M., Breu, R., Agreiter, B., Nowak, A.: Sectet: an extensible framework forthe realization of secure inter-organizational workflows. Internet Research 16(5),491–506 (2006)

16. Han, G., Zeng, H., Li, Y., Dou, W.: Safe: Security-aware flexray scheduling engine.In: Proceedings of the conference on Design, Automation & Test in Europe. p. 8.European Design and Automation Association (2014)

17. Han, K., Weimerskirch, A., Shin, K.G.: Automotive cybersecurity for in-vehiclecommunication. In: IQT QUARTERLY. vol. 6, pp. 22–25 (2014)

18. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in information systemsresearch. MIS quarterly 28(1), 75–105 (2004)

19. Holm, H., Shahzad, K., Buschle, M., Ekstedt, M.: P2CySeMoL: Predictive, proba-bilistic cyber security modeling language. IEEE Transactions on Dependable andSecure Computing 12(6), 626–639 (2015)

20. Holm, H., Sommestad, T., Franke, U., Ekstedt, M.: Success rate of remote codeexecution attacks - expert assessments and observations. Journal of Universal Com-puter Science 18(6), 732–749 (mar 2012)

21. Homer, J., Zhang, S., Ou, X., Schmidt, D., Du, Y., Rajagopalan, S.R., Singhal,A.: Aggregating vulnerability metrics in enterprise networks using attack graphs.Journal of Computer Security 21(4), 561–597 (2013)

22. Ingols, K., Chu, M., Lippmann, R., Webster, S., Boyer, S.: Modeling modern net-work attacks and countermeasures using attack graphs. In: Computer SecurityApplications Conference, 2009. ACSAC’09. Annual. pp. 117–126. IEEE (2009)

Non pu

blish

ed dr

aft

23. Johnson, P., Lagerstrom, R., Ekstedt, M.: Mal (the meta attack language): Adomain specific language for probabilistic threat modeling and attack simulation.www.kth.se/profile/robertl/page/mal-the-meta-attack-language (2018),[Non Published Submitted Draft Online; accessed 12-April-2018]

24. Johnson, P., Vernotte, A., Ekstedt, M., Lagerstrom, R.: pwnpr3d: An attack-graph-driven probabilistic threat-modeling approach. In: Availability, Reliability and Se-curity (ARES), 2016 11th International Conference on. pp. 278–283. IEEE (2016)

25. Joy, J., Samuel, S., Vinu, V.S.: Gateway architecture for secured connectivity andin vehicle communication (2013)

26. Jurjens, J.: Umlsec: Extending uml for secure systems development. In: Interna-tional Conference on The Unified Modeling Language. pp. 412–425. Springer (2002)

27. Jurjens, J.: Secure systems development with UML. Springer Science & BusinessMedia (2005)

28. Kleberger, P., Olovsson, T., Jonsson, E.: Security aspects of the in-vehicle networkin the connected car. In: 2011 IEEE Intelligent Vehicles Symposium (IV). pp. 528–533 (June 2011)

29. Kordy, B., Mauw, S., Radomirovic, S., Schweitzer, P.: Foundations of attack–defense trees. In: International Workshop on Formal Aspects in Security and Trust.pp. 80–95. Springer (2010)

30. Kordy, B., Pietre-Cambacedes, L., Schweitzer, P.: Dag-based attack and defensemodeling: Don’t miss the forest for the attack trees. Computer science review 13,1–38 (2014)

31. Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T., Checkoway, S., McCoy,D., Kantor, B., Anderson, D., Shacham, H., Savage, S.: Experimental security anal-ysis of a modern automobile. In: 2010 IEEE Symposium on Security and Privacy.pp. 447–462 (May 2010)

32. Kotenko, I., Doynikova, E.: Evaluation of computer network security based onattack graphs and security event processing. Journal of Wireless Mobile Networks,Ubiquitous Computing, and Dependable Applications (JoWUA) 5(3), 14–29 (2014)

33. Kraftfahrt-Bundesamt: Bestand in den jahren 1960 bis 2018 nachfahrzeugklassen. https://www.kba.de/DE/Statistik/Fahrzeuge/Bestand/

FahrzeugklassenAufbauarten/b_fzkl_zeitreihe.html (2018), [Online; accessed28-March-2018]

34. Larson, U.E., Nilsson, D.K.: Securing vehicles against cyber attacks. In: Proceed-ings of the 4th annual workshop on Cyber security and information intelligenceresearch: developing strategies to meet the cyber security and information intelli-gence challenges ahead. p. 30. ACM (2008)

35. Lemke, K., Paar, C., Wolf, M.: Embedded security in cars. Springer (2006)36. Lund, M.S., Solhaug, B., Stølen, K.: Model-driven risk analysis: the CORAS ap-

proach. Springer Science & Business Media (2010)37. Mauw, S., Oostdijk, M.: Foundations of attack trees. In: International Conference

on Information Security and Cryptology. pp. 186–198. Springer (2005)38. Miller, C., Valasek, C.: A survey of remote automotive attack surfaces. black hat

USA 2014 (2014)39. Miller, C., Valasek, C.: Remote exploitation of an unaltered passenger vehicle.

Black Hat USA 2015 (2015)40. Miller, C., Valasek, C.: Can message injection (2016)41. Mohamed, A.A.: Design intrusion detection system based on image block matching.

International Journal of Computer and Communication Engineering 2(5), 605–607(Sep 2013)

Non pu

blish

ed dr

aft

42. Mouratidis, H., Giorgini, P., Manson, G., Philp, I., et al.: A natural extension of tro-pos methodology for modelling security. In: Proceedings Agent Oriented Method-ologies Workshop, Annual ACM Conference on Object Oriented Programming,Systems, Languages (OOPSLA), Seattle-USA. Citeseer (2002)

43. Mundhenk, P., Steinhorst, S., Lukasiewycz, M., Fahmy, S.A., Chakraborty, S.:Security analysis of automotive architectures using probabilistic model checking.In: Proceedings of the 52Nd Annual Design Automation Conference. pp. 38:1–38:6.DAC ’15, ACM, New York, NY, USA (2015)

44. Newman, R.C.: Computer security: Protecting digital resources. Jones & BartlettPublishers (2009)

45. Nie, S., Liu, L., Du, Y.: Free-fall: Hacking tesla from wireless to can bus (2017)46. Nilsson, D.K., Larson, U.E.: A roadmap for securing vehicles against cyber attacks.

In: NITRD National Workshop on High-Confidence Automotive Cyber-PhysicalSystems, April 3-4, 2008, Troy, MI, USA (2008)

47. Noel, S., Elder, M., Jajodia, S., Kalapa, P., O’Hare, S., Prole, K.: Advances intopological vulnerability analysis. In: Conference For Homeland Security, 2009.CATCH ’09. Cybersecurity Applications Technology. pp. 124–129 (Mar 2009)

48. Ou, X., Govindavajhala, S., Appel, A.W.: Mulval: A logic-based network securityanalyzer. In: USENIX security (2005)

49. Ou, X., Singhal, A.: Attack graph techniques. Quantitative Security Risk Assess-ment of Enterprise Networks (Jan 2011)

50. Paja, E., Dalpiaz, F., Giorgini, P.: Modelling and reasoning about security re-quirements in socio-technical systems. Data & Knowledge Engineering 98, 123–143(2015)

51. Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee, S.: A Design ScienceResearch Methodology for Information Systems Research. Journal of ManagementInformation Systems 24(3), 45–77 (2007)

52. Petit, J., Shladover, S.E.: Potential cyberattacks on automated vehicles. IEEETransactions on Intelligent Transportation Systems 16(2), 546–556 (2015)

53. Poolsappasit, N., Dewri, R., Ray, I.: Dynamic security risk management usingBayesian attack graphs 9(1), 61–74 (2012)

54. Rippel, E.: Embedded security challenges in automotive designs. In: Proc. Work-shop on Embedded Security in Cars (escar 2008) (2008)

55. Roufa, I., Millerb, R., Mustafaa, H., Taylora, T., Ohb, S., Xua, W., Gruteserb,M., Trappeb, W., Seskarb, I.: Security and privacy vulnerabilities of in-car wirelessnetworks: A tire pressure monitoring system case study. In: 19th USENIX SecuritySymposium, Washington DC. pp. 11–13 (2010)

56. Schneier, B.: Attack trees. Dr. Dobb’s journal 24(12), 21–29 (1999)57. Schneier, S.: Lies: digital security in a networked world. New York, John Wiley &

Sons 21, 318–333 (2000)58. Smith, C.: The Car Hacker’s Handbook: A Guide for the Penetration Tester. No

Starch Press (2016)59. Sommestad, T., Ekstedt, M., Holm, H.: The cyber security modeling language:

A tool for assessing the vulnerability of enterprise system architectures. IEEESystems Journal 7(3), 363–373 (2013)

60. Sommestad, T., Holm, H., Ekstedt, M.: Estimates of success rates of remote ar-bitrary code execution attacks. Information Management & Computer Security20(2), 107–122 (2012)

61. Statistiska centralbyran: Fordonsstatistik januari 2006–februari2018. http://www.scb.se/hitta-statistik/statistik-efter-amne/

Non pu

blish

ed dr

aft

transporter-och-kommunikationer/vagtrafik/fordonsstatistik/pong/

tabell-och-diagram/fordonsstatistik/ (2018), [Online; accessed 28-March-2018]

62. Sung, G.N., Juan, C.Y., Wang, C.C.: Bus guardian design for automobile net-working ecu nodes compliant with flexray standards. In: 2008 IEEE InternationalSymposium on Consumer Electronics. pp. 1–4 (April 2008)

63. Symantec: Internet security threat report. https://www.symantec.com/content/dam/symantec/docs/reports/istr-22-2017-en.pdf (2017), [Online; accessed 28-March-2018]

64. Takahashi, J., Aragane, Y., Miyazawa, T., Fuji, H., Yamashita, H., Hayakawa,K., Ukai, S., Hayakawa, H.: Automotive attacks and countermeasures on lin-bus.Journal of Information Processing 25, 220–228 (2017)

65. Ueda, H., Kurachi, R., Takada, H., Mizutani, T., Inoue, M., Horihata, S.: Securityauthentication system for in-vehicle network. SEI Technical Review (81) (2015)

66. Wang, L., Jajodia, S., Singhal, A., Cheng, P., Noel, S.: k-zero day safety: A networksecurity metric for measuring the risk of unknown vulnerabilities 11(1), 30–44(2014)

67. Webster, J., Watson, R.T.: Analyzing the past to prepare for the future: Writinga literature review. MIS Quarterly 26(2), xiii–xxiii (2002)

68. Williams, L., Lippmann, R., Ingols, K.: GARNET: A graphical attack graph andreachability network evaluation tool. Springer (2008)

69. Wolf, M.: Security engineering for vehicular IT systems—improving trustworthi-ness and dependability of automotive IT applications. Vieweg + Teubner (2009)

70. Wolf, M., Weimerskirch, A., Paar, C.: Security in automotive bus systems. In:Proceedings of the Workshop on Embedded Security in Cars (2004)

71. Xie, P., Li, J.H., Ou, X., Liu, P., Levy, R.: Using Bayesian networks for cybersecurity analysis. In: Dependable Systems and Networks (DSN), 2010 IEEE/IFIPInt. Conf. on. pp. 211–220. IEEE (2010)

Non pu

blish

ed dr

aft

A Appendix

A.1 Assets & Attacks

Table 1: Covered Attacks

RelatedAsset

ID Attack Name Short Description PossibleDefense/Obstacle

TestCases

References

ECUA1.1 Bypass Access

ControlAn attacker can bypass accesscontrol and authenticate tothe machine through thediagnostics interface

None TC 2 -

A1.2 Denial of Service(DoS)

When an attacker performs aDoS attack to the ECU. Thisleads to DoS on the servicesrunning and deny of access tostored data. This can evenlead to unresponsive ECU

None TC 1,TC 2

-

A1.3 Shutdown When an attacker successfullyswitches off or takes offline aworking ECU

None, but it requiressignificant effort

TC 9,TC 10

[6,39]

A1.4 Changeoperation mode

An attacker might put theECU into diagnostics (ifvehicle is moving slowly or isstopped) or even update mode(bootmode)

Prevent ECU fromentering diagnosticsmode after it startedmoving for first time.Allow diagnosticsmode only after somephysical change on car.

TC 17,TC 18,TC 19,TC 20

[39]

Non pu

blish

ed dr

aft

Table 1: Covered Attacks

RelatedAsset

ID Attack Name Short Description PossibleDefense/Obstacle

TestCases

References

ECU

A1.5 Bypass messageconfliction

An attacker can bypassmessage confliction protectionmechanisms by changingECU’s operation mode (i.e. noconflicts) and achieve messageinjection

See A1.4 TC 20 [39]

A1.6 Message injection An attacker can inject forgedmessages, to the services thatare running on this ECU, thatcould for example notifyabout vehicle’s fault or reportfake status (speed, operationmode, etc.). This can evenlead to unresponsiveECU/DoS attack

Communicationprotection(authorization and/orauthentication),message conflictionmechanism, IDPS.

TC 7,TC 25

[28]

A1.7 Firmwaremodification

An attacker could upload acustom firmware on the targetECU so that he can gain fullaccess on the ECU and maybeon the connected network

Firmwarevalidation/signingmechanisms thatprevent customfirmware uploads

TC 21,TC 22,TC 23,TC 28

[39]

GatewayECU

A2.1 Bypass Firewall If the firewall is disabled, thenthe attacker can bypass it

Enable firewall TC 31 -Non pu

blish

ed dr

aft

Table 1: Covered Attacks

RelatedAsset

ID Attack Name Short Description PossibleDefense/Obstacle

TestCases

References

GatewayECU

A2.2 Bypass IDPS If firewall is disabled, then theattacker can attempt tobypass the IDPS by carefullyinjecting messages to thenetwork

Enable IDPS, and ingeneral bypass requiressome effort from theattacker

TC 31 [28,34]

A2.3 Denial of Service An attacker can performdenial of service attack on theconnected networks

None TC 6 -

VehicleNetwork

A3.1 Eavesdrop An attacker can eavesdrop thenetwork and the transmitteddataflows

None TC 8 [5]

A3.2 Man in theMiddle (MitM)

An attacker can intercept andtamper with the network’scommunications

None TC 8 [52]

A3.3 Denial of Service(DoS)

An attacker can perform aDoS attack to the network

None TC 9,TC 10,TC 11,TC 24,TC 31

-

A3.4 MessageInjection

An attacker can inject forgedmessages to the network, thatfor example could notifyabout vehicle’s fault or reportfake status (speed, operationmode, etc.)

Attacker must havephysical access to thenetwork layer

TC 25,TC 26,TC 27,TC 29,TC 32

[39,40,52,58]

Non pu

blish

ed dr

aft

Table 1: Covered Attacks

RelatedAsset

ID Attack Name Short Description PossibleDefense/Obstacle

TestCases

References

CANNetwork

A4.1 Exploit CAN’sarbitrationmechanism

By exploiting the arbitrationmechanism for messageprioritization in CAN bus, anattacker could achieveinvalidation of legitimatemessages and/or messagetampering

Requires networkaccess plus effort isneeded from theattacker

TC 9 [35,39]

A4.2 Bus-off attack An attacker can exploit theerror-handling scheme CANto disconnect or shut downgood/uncompromised ECUs

The defense proposedon literature, pluseffort is needed fromthe attacker

TC 9 [6]

FlexRayNetwork

A5.1 Common timebase attack

An attacker that sends morethan needed SYNC messageswithin one communicationcycle can make the wholenetwork inoperable

None, but effort isneeded from theattacker

TC 10 [69]

A5.2 ExploitFlexRay’s BusGuardian

An attacker can utilize BusGuardian to sendwell-directed faked errormessages to deactivatecontrollers. However, BusGuardian is hardened so mucheffort is needed

None, but effort isneeded from theattacker

TC 10 [43,69]

Non pu

blish

ed dr

aft

Table 1: Covered Attacks

RelatedAsset

ID Attack Name Short Description PossibleDefense/Obstacle

TestCases

References

FlexRayNetwork

A5.3 Sleep frameattack

An attacker can sendwell-directed forged sleepframes to deactivatepower-saving capable FlexRaycontrollers

Power-saving featurescan be disabled, pluseffort is needed fromthe attacker

TC 10 [69]

LINNetwork

A6.1 Inject bogus syncbytes

An attacker that sends frameswith bogus synchronizationbytes within the SYNCH fieldcan make the local LINnetwork inoperative or causeat least serious malfunctions

None, but effort isneeded from theattacker

TC 11 [69]

A6.2 Gain LIN accessfrom CAN

An attacker can easily gainaccess to the LIN subnetworkthrough a CAN-bus node

The CAN-bus ECUmust first becompromised

TC 11 [31,54]

A6.3 Inject header ortimed response

An attacker can exploit theerror handling mechanism ofLIN bus to inject forgedheaders or messages to thenetwork, but in general it isnot so easy

The defense proposedin literature, plus effortis needed from theattacker

TC 11 [64]

Non pu

blish

ed dr

aft

A.2 Test Cases

1. CoreMachineTest

TC 1 testMachineAccess

TC 2 testBypassMachineAccess

TC 3 testSoftwareHostToGuest

TC 4 testSoftwareGuestToHost

TC 5 testMachineAccountDataRWD

2. CoreVehicleNetworkTest

TC 6 testGatewayECUAccess

TC 7 simpleServicekMessageInjection

TC 8 testMitmNetwork

TC 9 testCANNetworkSpecificAttacks

TC 10 testFlexNetworkSpecificAttacks

TC 11 testLINNetworkSpecificAttacks

3. CoreDataTest

TC 12 testDataAccess

TC 13 testDataflow1DataAccess

TC 14 testDataflow2DataAccess

4. CoreVulnerabilityTest

TC 15 testVulnerability

TC 16 testSoftware

5. CoreEcuTest

TC 17 testConnectEcuAttacks

TC 18 testConnectEcuAttacks2

TC 19 testAccessEcuAttacks

TC 20 testAccessEcuAttacks2

6. CoreFirmwareTest

TC 21 testFirmwareValidation

TC 22 testFirmwareValidation2

TC 23 testBypassFirmwareValidation

7. MessageInjectionTest

TC 24 testNetworkMessageInjection

TC 25 testServicekMessageInjection1

TC 26 testServicekMessageInjection2

TC 27 testNetworkMessageInjectionAfterVuln

TC 28 testNetworkMessageInjectionAfterFirmwareUpload

TC 29 testProtectedNetworkMessageInjection

TC 30 testProtectedNetworkMessageInjection2

8. AdvancedNetworkTest

TC 31 testDataflowWithFirewallAndIDPS

TC 32 testGainLINaccess

Non pu

blish

ed dr

aft

A.3 Sample Attack

Listing 1.1. Source Code of Sample Attack

1 public void testDataflowWithFirewallAndIDPS () {

2 boolean firewallStatus = false;

3 boolean idpsStatus = false;

4

5 ECU SrvEcu = new ECU("ServiceECU", true , true);

6 ECU ClnEcu = new ECU("ClientECU", true , true);

7 GatewayECU GateEcu = new GatewayECU("GatewayECU",

8 firewallStatus , true , true);

9 VehicleNetwork vNet1 = new VehicleNetwork("vNet1");

10 VehicleNetwork vNet2 = new VehicleNetwork("vNet2");

11 Dataflow dataflow = new Dataflow("Dataflow");

12 Dataflow otherDataflow =

13 new Dataflow("OtherDataflow");

14 NetworkClient client = new NetworkClient("Client");

15 NetworkService service =

16 new NetworkService("Service");

17

18 SrvEcu.addVehiclenetworks(vNet1);

19 ClnEcu.addVehiclenetworks(vNet2);

20 GateEcu.addVehiclenetworks(vNet1);

21 GateEcu.addVehiclenetworks(vNet2);

22 SrvEcu.addExecutees(service );

23 ClnEcu.addExecutees(client );

24 vNet1.addTrafficGatewayECU(GateEcu );

25 vNet2.addTrafficGatewayECU(GateEcu );

26 vNet1.addDataflows(dataflow );

27 vNet2.addDataflows(dataflow );

28 vNet2.addDataflows(otherDataflow );

29 client.addDataflows(dataflow );

30 service.addDataflows(dataflow );

31

32 Attacker attacker = new Attacker ();

33 attacker.addAttackPoint(vNet1.physicalAccess );

34 attacker.attack ();

35

36 dataflow.maliciousRequest

37 .assertCompromisedImmediately ();

38 GateEcu.forwarding

39 .assertCompromisedInstantaneously ();

40 GateEcu.bypassFirewall

41 .assertCompromisedInstantaneously ();

42 GateEcu.gatewayNoIDPS

Non pu

blish

ed dr

aft

43 .assertCompromisedInstantaneously ();

44 GateEcu.gatewayBypassIDPS.assertUncompromised ();

45 otherDataflow.maliciousRespond

46 .assertCompromisedInstantaneously ();

47 SrvEcu.connect.assertCompromisedInstantaneously ();

48 }

Non pu

blish

ed dr

aft