Extending Attack Graphs to Represent Cyber-Attacks in

Extending Attack Graphs to Represent

Cyber-Attacks in Communication Protocols and

Modern IT Networks

Orly Stan

∗

, Ron Bitton

∗

, Michal Ezrets

∗

, Moran Dadon

∗

, Yuval Elovici

∗

, Asaf Shabtai

∗

Masaki Inokuchi

†

, Yoshinobu Ohta

†

, Yoshiyuki Yamada

†

, Tomohiko Yagyu

†

∗

Department of Software and Information Systems Engineering, Ben-Gurion University of the Negev

†

Security Research Laboratories, NEC Corporation

Abstract—An attack graph is a method used to enumerate the

possible paths that an attacker can execute in the organization

network. MulVAL is a known open-source framework used to

automatically generate attack graphs. MulVAL’s default model-

ing has two main shortcomings. First, it lacks the representation

of network protocol vulnerabilities, and thus it cannot be used

to model common network attacks such as ARP poisoning, DNS

spooﬁng, and SYN ﬂooding. Second, it does not support advanced

types of communication such as wireless and bus communication,

and thus it cannot be used to model cyber-attacks on networks

that include IoT devices or industrial components. In this paper,

we present an extended network security model for MulVAL

that: (1) considers the physical network topology, (2) supports

short-range communication protocols (e.g., Bluetooth), (3) models

vulnerabilities in the design of network protocols, and (4)

models speciﬁc industrial communication architectures. Using

the proposed extensions, we were able to model multiple attack

techniques including: spooﬁng, man-in-the-middle, and denial of

service, as well as attacks on advanced types of communication.

We demonstrate the proposed model on a testbed implementing

a simpliﬁed network architecture comprised of both IT and

industrial components.

Index Terms—Attack Graph, MulVAL, Network Protocols,

Network attacks.

I. INTRODUCTION

Risk assessment is a process that enables system stake-

holders to assess the risks to their system and select suitable

countermeasures. An attack graph is a risk assessment method

used to enumerate the possible attack paths that an attacker can

take in order to compromise an organization [1]. This is done

by modeling the prerequisites and consequences of exploiting

software vulnerabilities, as well as the attacker’s potential lat-

eral movements. Using attack graphs, system stakeholders can

identify potential attack paths, assess their risk, visualize an

exhaustive attack surface, and plan efﬁcient countermeasures.

Various types of attack graphs have been proposed in the

literature, including state attack graphs [2], dependency attack

graphs [3], multi-prerequisite graphs [4], and logical attack

graphs [5]. In this research, we focus on the logical attack

graph: a directed and-or graph in which the root represents an

attacker’s goal, nodes represent subgoals (attack steps), and

leafs represent facts about the system. Both facts and subgoals

can be disjunctively or conjunctively connected to the next

subgoals or a ﬁnal goal.

MulVAL, a logic-based network security analyzer [6], is

a well-known open-source framework for automatically con-

structing attack graphs. MulVAL models the interactions of

software vulnerabilities with system and network conﬁgura-

tions, while automatically extracting information from formal

vulnerability databases (such as the National Vulnerability

Database – NVD [7]) and network scanning tools (such as

Nessus [8]).

While the MulVAL framework is a very powerful tool

for generating attack graphs, it currently suffers from the

following major limitations. First, it is broadly focused on

application (software) vulnerabilities and does not properly

incorporate weaknesses in network architectures and proto-

cols. For instance, ARP poisoning, DNS spooﬁng, and SYN

ﬂooding are network attacks that cannot be properly modeled

using only application vulnerabilities. Thus, MulVAL is likely

to create an incomplete view of the possible attacks and

attack paths in an organizational network. Second, MulVAL

is speciﬁcally designed to model traditional IT environments

and does not support advanced communication types such as

wireless and bus communication. Thus, it cannot be used to

model cyber-attacks on modern enterprise networks, such as

those that include IoT or industrial components.

Previous attempts to augment MulVAL for representing

vulnerabilities in network protocols did not provide a compre-

hensive (general) network model but addressed and modeled

speciﬁc network attacks (e.g., ARP poisoning in [9]). In this

paper we extend the MulVAL framework with a compre-

hensive network modeling. The proposed extension considers

the seven layers of the OSI network model (including the

physical network topology), supports short-range communica-

tion protocols which are very common in IoT environments,

and models speciﬁc industrial communication architectures.

Consequently, the extended version of MulVAL supports the

modeling of various network attacks, including attacks on the

physical layer (e.g., bus spooﬁng, WEP cracking, Bluetooth

PIN cracking), data link layer (e.g., ARP poisoning), network

layer (e.g., IP spooﬁng, ICMP ﬂooding), and application layer

(e.g., DNS spooﬁng). We demonstrated the proposed modeling

in a testbed implementing a simpliﬁed network architecture,

which is comprised of both IT and industrial components.

arXiv:1906.09786v1 [cs.CR] 24 Jun 2019

Finally, in order to maintain an end-to-end attack graph gen-

eration process (that is provided by the MulVAL framework),

we present our dedicated agent that was implemented for

automatically scanning the network and translating the scan

results into our extended modeling.

To summarize, the contributions of this paper are as

follows. First, we present comprehensive network modeling

that considers the seven layers of the OSI network model

(including the physical network topology, wireless networks

and bus architecture), which are currently not supported by

the MulVAL framework. Second, we model multiple attack

scenarios that are not addressed by current attack graph

frameworks (e.g., spooﬁng and wireless attacks). Third, we

present the implementation of a dedicated agent which is used

to automatically collect network conﬁgurations and generate

the input for the extended model.

II. PRELIMINARIES

A. The Evolution of Attack Graph Generation Methods

Forward exploration for attack graph generation. The

use of attack graphs for security assessment started almost

30 years ago. Fundamental studies in this domain include

the works of Philips and Swiler [1], [10], which introduced

the concept of graph-based network vulnerability analysis,

and presented an automated tool for generating attack graphs.

Their tool constructs the attack graph using the forward

exploration method, starting from the initial state (the initial

position of the attacker) to any goal state (target). This

approach, however, is not efﬁcient in terms of complexity,

since it evaluates all existing vulnerabilities, including

those that are not relevant to the goal state; therefore, it is

impractical for applying on large-scale networks.

Model checking for efﬁcient security assessment. Ritchey

and Ammann [11] suggested a simple network security

model (consisting of hosts and their vulnerabilities, network

connectivity, current state of the attacker, and available

exploits), on which they apply a model checking technique

(model checker SMV), in order to evaluate the security of

a system by considering the relationships between different

hosts in a network. Ritchey et al. [12] extended the simple

network security model to represent TCP/IP connectivity.

Within their model, which is called topological vulnerability

analysis, the representation of a host was extended to

include network services and conﬁgurations, and the network

connectivity model was extended to support link, transport,

and application layer security. Based on Ritchey’s connectivity

model, Jajodia et al. developed a framework which automates

the vulnerability analysis process by deploying an open-source

version of the Nessus scanner [8] and combining its reports

with a global exploits knowledge base.

Model checking methods are more efﬁcient than generating

an attack graph using forward exploration. However, their

main drawback is that they can only represent one attack

path from source to target, while attack graphs enumerate all

possible attacks.

Model checking for attack graph generation. To address

this limitation, Sheyner et al. [2] introduced the attack graph

toolkit, which utilizes model checking tools for automatically

generating attack graphs, thus improving the efﬁciency and

completeness of the model compared to previous works.

Jha et al. also suggested to use model checking for attack

graph generation [13]. Similar to [2], the authors modiﬁed

the model checker NuSMV in order to produce a complete

attack graph.

However, for the construction of attack graphs, model

checking algorithms doesn’t scale well; for example, in the

work of Sheyner et al. [2] the construction of attack graph

for a network with ﬁve hosts and eight exploits took two

hours and resulted in 5948 nodes and 68364 edges. Ammann

et al. suggested to use a layered model to improve the

scalability [14]. They modeled facts (privileges, connectivity,

and vulnerabilities) as generic attributes (e.g., the attacker has

ftp access to a speciﬁc host) and exploits as transformations

that map a set of preconditions to a set of postconditions. Then,

they arranged the attributes in layers according to amount of

exploits required to obtain them.

Nevertheless, the main shortcoming of the above studies

is that none of them automatically integrates vulnerability

and network connectivity information into the attack graph

generation process, and therefore none of them can support

the analysis of large-scale networks.

End-to-end attack graph generation frameworks. The

ﬁrst framework to provide automatic end-to-end attack graph

generation and analysis is MulVAL [6], a logic-based network

security analyzer. MulVAL leverages exiting vulnerability

databases (e.g., the National Vulnerability Database – NVD)

and network vulnerability assessment tools (e.g., Nessus) to

automatically derive the inputs for the attack graph generation

process. This is done by using Datalog as the modeling

language, which makes the integration of vulnerability

databases and security assessment tools straightforward.

Another beneﬁt of Datalog over model checking tools is

its efﬁciency. The complexity for model checking tools to

enumerate all possible attack paths is exponential in the

size of the network [6]. In contrast, Datalog programs are

polynomial in the size of network.

Following MulVAL, Ingols et al. presented NetSPA, an end-

to-end framework for attack graph generation [4]. NetSPA im-

proves the input generation process by automatically extracting

information from additional data sources such as Check Point

ﬁrewalls and the CVE repository [15].

In 2013, Yi et al. [16] compared several academic attack

graph generation tools (TVA, Attack Graph Toolkit, NetSPA,

and MulVAL), as well as commercial software (Cauldron [17],

[18] which is based on TVA, Firemon [19] which is based on

NetSPA, and Skybox [20]) and concluded that: (1) MulVAL

is the most extendable and scalable framework; (2) TVA and

NetSPA are also scalable, however they are not open-source;

and (3) commercial tools are more scalable and provide an

intuitive graphical user interface, however they are not suitable

for research. Therefore, in this study, we focus on the MulVAL

attack graph framework.

B. The MulVAL Framework

MulVAL is a logic-based security analyzer that models the

interactions between software bugs and network conﬁgurations

(i.e., connectivity), while automating the information gathering

process by deploying host-based scanners. The modeling

language used by MulVAL is Datalog [6], which is a subset

of the Prolog logic programming language. We demonstrate

MulVAL’s modeling using the simple attack scenario

illustrated in Figure 1: the attacker aims to execute malicious

code in the database server by abusing the free access from

the Internet to the server and the vulnerable database software

that allows privilege escalation (CVE-2012-3132).

Datalog primitives and syntax. The Datalog language

consists of facts and rules, which are deﬁned using

predicates. Predicate is an atomic formula of the form:

p(t

, ..., t

)

where, each t

can be either a constant (starting with a

lower-case) or a variable (starting with an upper-case); wild

cards are also supported and are marked with underscore

(” ”). For example, the following predicate states that: some

vulnerability is present in the oracleDB program running on

dbServer.

vulExists(dbServer, V ulID, oracleDB).

Rules (referred to as interaction rules in MulVAL) are

represented using Horn clauses as follows:

: −P

, ..., P

which essentially tells that if the predicates P

, ..., P

are true,

then predicate P

is also true. The left part of the clause (P

)

is called the head and the right part (P

, ..., P

) is called

the body. Facts are clauses with no body. For example, the

following rule tells that a host can be remotely accessed if it

runs a login service using speciﬁc port and protocol and it is

accessible via the same protocol and port.

canAccessHost(H) : −

logInService(H, P rotocol, P or t),

netAccess(H , P rotocol, P ort)).

The XSB system. In order to execute a Datalog program,

MulVAL uses the XSB environment, which is an extended

implementation of the Prolog programming language that

supports tabled execution. Tabled execution prevents the re-

calculation of previously calculated facts (i.e., each fact is

calculated only once). Since the number of facts is polynomial

in the size of the network, executing a Datalog program has

a polynomial time complexity.

Attacks are simulated according to the attackerGoal(p) facts

(where p is a predicate deﬁned in the Datalog program) that

Fig. 1: MulVAL example: code execution scenario.

are speciﬁed in the input to MulVAL (the complete example

input is given in Appendix B). The simulation is performed by

querying the Datalog program for the predicate p; the attack

graph is constructed based on the trace generated by this query.

A detailed description of the Datalog trace analysis and attack

graph construction is provided by Ou et al. in [5].

Attack graph representation. MulVAL generates a logical

attack graph as deﬁned in [5]: AG = (N

, N

, E, L, G),

where N

, N

are the sets of nodes (derivations, primitive

facts, and derived facts correspondingly), E is the set of edges,

L is a mapping from a node to its label (i.e., the predicate it

represents), and G is the node representing the attacker’s goal.

Figure 2 presents the attack graph generated by the MulVAL

tool

for the attack scenario described above.

Derivation nodes (visualized as circles) correspond to inter-

action rules and represent the reason for a fact to become

true, they can be viewed as attack steps (N

= {2, 4}).

Primitive facts (visualized as rectangles) correspond to the

information given as input (N

= {5, 6, 7, 8}), while derived

facts (visualized as diamonds) are the results of applying

interaction rules on the primitive facts (can be viewed as attack

step consequences; i.e., N

= {1, 3}). An edge e ∈ E can

connect between a primitive or derived fact and a derivation

(e ∈ {(N

∪ N

) × N

}), or between a derivation and a

derived fact (e ∈ {N

× N

}). The derivation nodes imply an

and relation between their incoming nodes, which represent

the preconditions for performing the corresponding actions;

while the derived fact nodes imply an or relation between

their incoming nodes, which represent the various actions that

result in the same consequence.

III. RELATED WORK

The main limitation of MulVAL is that it only considers

software vulnerabilities and does not address vulnerabilities in

the design of network protocols. Previous studies focused on

extending the expressibility of MulVAL’s security model. Ap-

pendix A presents a comparison between MulVAL’s modeling,

previously suggested extensions, and our proposed extensions.

Froh et al. [21], [22] developed two extensions for Mul-

VAL. The ﬁrst extension includes three main improvements:

a more realistic network model that includes subnets and

MulVAL tool: http://www.arguslab.org/software/mulval.html

Node Description (L(N ode))

1 execCode(dbServer, root)

2 RULE 2: remote exploit of a server pro-

gram

3 netAccess(dbServer, tcp, 1521)

4 RULE 6: direct network access

5 hacl(internet, dbServer, tcp, 1521)

6 attackerLocated(internet)

7 networkServiceInfo(dbServer, oracleDB,

tcp, 1521, root)

8 vulExists(dbServer, ’CVE-2012-

3132’, oracleDB, remoteExploit,

privEscalation)

Fig. 2: MulVAL example: code execution attack graph.

routers; modeling of data authorization policies; and an al-

gorithm for prioritizing attack paths based on their impact

on the organization. The second extension includes modeling

of additional safeguards (e.g., application level authentication)

and a deﬁnition of high-level IT services for better attack graph

analysis. Although these extensions produce more realistic

modeling, they are limited to software vulnerabilities and

cannot be used to model vulnerabilities in network protocols

or modern IT networks (such as those that include wireless

communication).

These works, however, focus on the efﬁciency and post-

assessment of the attack graph and not on extending the

framework to represent additional scenarios.

Acosta et al. [9] extended MulVAL to represent a speciﬁc

data link vulnerability through which the ARP spooﬁng attack

can be modeled. In this study, we propose a comprehensive

network model, which considers the seven layers of the

OSI model, supports wireless and short-range communication

protocols, and models speciﬁc industrial communication archi-

tectures. Our proposed modeling enables the representation of

various attacks on the physical, data link, network, and appli-

cation layers. Furthermore, we develop a prototype system that

automatically collects network conﬁgurations, converts them

to MulVAL’s input, and generates the attack graph.

IV. NETWORK MODELING

A. Overview

In order to support more realistic network modeling, we

added new predicates and interaction rules to MulVAL’s origi-

nal rule set (presented in [23]). These predicates can be catego-

rized into: physical network topology, network communication,

principal access, host conﬁguration, and vulnerability.

In our extended modeling, IT networks are modeled using

the following three layers: link, end-to-end, and application,

as presented in Figure 3. The link layer integrates the network

topology, users’ actions, protocols, and vulnerabilities that are

associated with a speciﬁc network zone (e.g., ARP spooﬁng in

a subnet or WEP cracking). The end-to-end layer represents

communication between speciﬁc hosts and services in remote

hosts (OSI layers 3-7); it models the ability of two hosts to

communicate using various protocols (e.g., FTP, HTTP) and

the vulnerabilities existing in these protocols. The application

layer represents the user data and the data generated as a

result of an end-to-end communication (e.g., the transmission

of an e-mail). To represent the connectivity between hosts

Fig. 3: Illustration of the three-layer network structure and

related predicates.

in each layer, we deﬁned the l2Connection, aclNW , and

dataF low predicates. We also deﬁned predicates that bind the

different layers of communication. The flowBind predicate

associates an end-to-end protocol with a data ﬂow, and the

relay predicate associates a physical host with a data ﬂow

or an end-to-end communication. Since l2Connection and

relay represent physical connections and components, they are

categorized as physical network topology; aclNW , dataF low,

and f lowBind are related to end-to-end and application

communications, thus, are categorized as network communi-

cation. It is important to bind between the different layers

because attacks on a lower layer can affect the upper layers

of the communication. For example, transmitting plain-text

data over an encrypted end-to-end protocol can be considered

safe; however, if an attacker succeed to break the end-to-end

encryption he/she can read the transmitted data.

We also model principals’ access to hosts in each layer.

The l2Access and netAccess predicates express a princi-

pal’s access to a host in the link and end-to-end layers,

respectively, while the accessLinkF low, accessE2EF low

and acessDataF l ow predicates express the principal’s access

to the corresponding layer’s communication.

Vulnerabilities are classiﬁed into host, protocol, and data,

according to their range of impact, and they are represented

by the following predicates: vulHost, vulLinkP rotocol,

vulE2EP rotocol, and vulData. A detailed description of the

proposed extended network modeling follows.

B. Physical Network Topology

Network Architecture and Components (see Listing 1).

In order to bind an entity (e.g., a user or a host) to a network

zone, MulVAL uses the located predicate (line 1). We ﬁnd this

coarse deﬁnition of zone insufﬁcient for modeling the physical

network topology. Hence, we extend the located predicate to

specify the type (T ype) of a network zone (line 2): an IP

subnet to which Host belongs (ipSubnet), a serial bus to

which Host is physically connected (bus), or the physical

location (position) of Host.

To indicate the usage of a speciﬁc link layer proto-

col in a zone (e.g., serial Modbus in a bus) we intro-

duce the existingProtocol predicate (line 3). For exam-

ple, existingP rotocol(subnet1, arp) indicates that hosts in

subnet1 use ARP.

To be able to model network components (e.g., switch or

router) in the physical network topology, we deﬁne the relay

1 located(Principal, Zone).

2 located(Host,Zone,Type).

3 existingProtocol(Zone,Protocol).

4 relay(RelayHost,SrcHost,DstHost).

5 relay(RelayHost,SrcHost,DstHost,Prot,Port).

6 relay(RelayHost,DataFlow).

7 isGateway(Router,Subnet)

8 isAP(AP,WirelessRange,DstZone,Prot,SecurityConf).

9 isNameResolver(ResolverHost,UserHost,Searched).

10 isMaster(Device,BusID).

11 isSlave(Device,BusID).

Listing 1: Network components.

predicates. We distinguish between three types of network

relays: a link layer relay that controls the entire communi-

cation between SrcHost and DstHost (line 4); a network

layer relay that controls the communication of Sr cHost and

DstHost on a speciﬁc protocol (P rot) and port (Port)

(line 5); and an application layer relay that controls the

communication of a speciﬁc application data ﬂow (line 6).

We also deﬁne predicates that provide an indication about

speciﬁc roles of network components (lines 7-11). The

isGateway predicate indicates that Router is the gateway of

Subnet (line 7). The isAP predicate provides an indication

regarding an access point that broadcasts to a W irelessRange

and is connected to a DstZone (line 8); whereas, the P rot

argument speciﬁes which protocol is used to establish the wire-

less connection (e.g., WEP), and the SecurityConf argument

speciﬁes whether the access point uses a secured protocol

(SecurityConf = secured) or is open to any connection

request (SecurityConf = open). The isN ameResolver

predicate indicates that ResolverHost is the name resolver

that is queried by UserHost for ﬁnding the IP address

associated with the name denoted by Searched (line 9).

Finally, the isMaster and isSlave predicates are used to

indicate master/slave components that are common in serial

buses. The master device issues commands to others (i.e.,

initiates the communication), and the slave components re-

spond to the master’s commands (lines 10-11). It is important

to distinguish between these two roles, since they affect the

attacker’s capabilities in a serial bus.

Network Connectivity (see Listing 2). Within MulVAL, the

communication between hosts is represented by the hacl pred-

icate, which represents an abstraction of some host’s ability

to reach another after considering the network’s topology and

security conﬁgurations [23] (e.g., if there is a ﬁrewall denying

the communication between two hosts, an hacl fact will not be

generated). We ﬁnd this abstraction unsuitable for modeling

the link and physical layers connections. As mentioned, we

distinguish between the link layer connectivity (which is not

addressed by the original MulVAL modeling), and the end-

to-end connectivity (which is originally addressed by the hacl

predicates). A link layer connectivity relates to the connections

between hosts through a shared medium (e.g., Ethernet, Wi-

Fi, Bluetooth, bus, etc.). We represent this type of connectivity

using the l2Connection predicate (line 1), which indicates that

two devices (Dev1 and Dev2) are connected via the same

link (LinkId) of T ype and can communicate using protocol

P rot. We consider the following three medium types:

1) Ethernet: an Ethernet link (ipSubnet) enables the connec-

tivity between two devices (Dev1 and Dev2) located in the

1 l2Connection(Dev1,Dev2,LinkId,Prot,Type)

2 l2Connection(Dev1,Dev2,Link,Prot,ipSubnet):-

3 located(Dev1,LinkId,ipSubnet),

4 located(Dev2,LinkId,ipSubnet),

5 existingProtocol(LinkId,Prot).

6 l2Connection(Dev1,Dev2,Prot,bus):-

7 located(Dev1,BusID,bus),

8 located(Dev2,BusID,bus),

9 existingProtocol(BusID,Prot).

10 l2Connection(Dev,AP,WirelessRange,Prot,wireless):-

11 isAP(AP,WirelessRange,DstZone,Prot,open),

12 located(Dev,WirelessRange,physical).

13 l2Connection(Dev,AP,WirelessRange,Prot,wireless):-

14 isAP(AP,WirelessRange,DstZone,Prot,secured),

15 located(Dev,WirelessRange,physical),

16 isAuthenticated(Principal,Dev,AP).

17 located(Dev,DstZone,Type):-

18 l2Connection(Dev,AP,WirelessRange,Prot,wireless),

19 isAP(AP,WirelessRange,DstZone,Prot,secured),

20 located(_,DstZone,Type).

21 l2Connection(MasterDevice,SlaveDevice,BluetoothRange,bluetooth,wireless):-

22 existingProtocol(BluetoothRange,bluetooth),

23 inDiscoveryMode(SlaveDevice),

24 located(MasterDevice,BluetoothRange,physical),

25 located(SlaveDevice,BluetoothRange,physical).

Listing 2: Network connectivity.

same IP subnet (lines 2-5).

2) Bus: a serial link (bus) enables the connectivity between

two devices (Dev1 and Dev2) connected to it (lines 6-9).

3) Wireless: a wireless link (T ype = wireless) enables the

connectivity between two devices that are located within the

same wireless range (W irelessRange). We support two

wireless technologies: Wi-Fi and Bluetooth.

Wi-Fi enables the connectivity between a wireless device

(Dev) and an access point (AP ). We distinguish between

an open access point (lines 10-12) and a secured access

point (lines 13-16), in which the principal (P rincipal) is

authenticated. When a host connects to an access point

it becomes part of the subnet that the access point is

connected to (denoted by DstZone); thus, we deﬁne the

located interaction rule (lines 17-20).

Bluetooth enables the direct connection between two de-

vices (M asterDevice and SlaveDevice) using the Blue-

tooth technology (T ype = bluetooth). In this type of

connection the two devices must be physically located

within each other’s range (BluetoothRang e). In addition,

the SlaveDevice must be in discovery mode (lines 21-25).

C. Network Communication

Application Layer Communication (see Listing 3). In

our proposed modeling, the application layer represents data

exchange between two entities. We model the communica-

tion in this layer using the dataF low predicate (lines 1-2).

This predicate associates an application layer communication

(F lowName) with the two hosts (SrcHost and DstHost)

that generated it (line 1). For bidirectional communication, the

Direction parameter is set to twoW ay; otherwise, it should

be set to oneW ay. Subsequently, in some cases it is sufﬁcient

to associate only one communication end with F lowName ;

thus, we also deﬁne a shorter version of the dataF low

predicate (line 2), where Host is either the source or des-

tination of the communication represented by F lowN ame.

Communication (data) ﬂows are also associated with end-

to-end protocols (e.g., the transmission of an email can be

associated with SMTP). To express this association, we deﬁne

the flowBind predicate (line 3).

1 dataFlow(SrcHost,DstHost,FlowName,Direction).

2 dataFlow(Host,FlowName).

3 flowBind(FlowName,Prot,Port).

4 isPairingProcess(FlowName).

6 aclNW(SrcHostOrsubnet,DstHostOrsubnet,Prot,Port).

Listing 3: Network communication.

1 localAccess(Principal,Host,User).

2 localAccess(attacker,Host,admin):-

3 attackerLocated(Host).

4 localAccess(Principal,HostB, User):-

5 hasAccount(Principal,HostB,User),

6 networkService(HostB,Prog,Prot,Port,LoginServiceUser),

7 netAccess(Principal,HostA,HostB,Prot,Port),

8 aclH(HostB,LoginServiceUser,HostA,HostB,Prot,Port),

9 isLoginService(Prog).

Listing 4: Principal host access.

Some attack scenarios rely on the attacker’s ability to exploit

a speciﬁc type of data ﬂow. For example, in order to execute

a Bluetooth PIN cracking attack, the attacker needs to capture

the packets transmitted during the pairing process. Thus, we

include the deﬁnition of speciﬁc data ﬂow types. An example

is isP airingP rocess (line 4), which indicates that the data

ﬂow (F lowName) is the sequence of packets transmitted

during a Bluetooth pairing process.

Access Control (see Listing 3). MulVAL represents the net-

work access control policy by hacl predicates, which take the

physical topology of the network into account [23]. In our

proposed modeling, we separate between the representation

of physical topology and access control. We represent the

network-based access control rules by the aclNW predicate

(line 6), which indicates that packets of protocol P rot, orig-

inating in host/subnet (SrcHostOrsubnet) and designated

for a speciﬁc port (P ort) in the host/subnet denoted by

DstHostOrsubnet, are allowed. Host-based access control

modeling will be described in Section IV-E.

D. Principal Access

The human aspect must also be taken into account when

modeling network access. To be consistent with our three-layer

network modeling, we deﬁne a principal access predicate for

each layer: host access, network access, and data access.

Host Access (see Listing 4). Refers to the ability of a principal

to login to a host. This type of access is represented by the

localAccess predicate (line 1), which indicates that a principal

(P rincipal) can access a host (Host) using the user account

denoted by U ser. A principal access to a host can also be

inferred from the following two scenarios: (1) an attacker who

is located in a host has access to that host (lines 2-3), and (2)

a principal that has local access to a host (HostA) can use

it to gain access via the network to a remote host (HostB)

by using a network login service and a previously obtained

account (lines 4-9).

Network Access (see Listing 5). Similar to the network

topology and communication, we distinguish between the

principal’s direct access to a host through the link layer (e.g.,

access a component via a serial bus) and by using an end-to-

end protocol (e.g., sending an email using SMTP).

Link layer access is represented by the l2Access predicate

(line 1) which indicates that a principal (P rincipal) can access

DstHost from SrcHost via the medium denoted by LinkID.

1 l2Access(Principal,SrcHost,DstHost,Prot,LinkID,Type).

2 l2Access(Principal,SrcHost,DstHost,Prot,LinkID,Type):-

3 localAccess(Principal,SrcHost,User),

4 l2Connection(SrcHost,DstHost,LinkID,Prot,Type).

6 netAccess(Principal,SrcHost,DstHost,Prot,Port).

7 netAccess(Principal,SrcHost,DstHost,Prot,Port):-

8 localAccess(Principal,SrcHost,SrcUser),

9 aclNW(SrcHost,DstHost,Prot,Port),

10 aclH(SrcHost,SrcUser,SrcHost,DstHost,Prot,Port).

Listing 5: Principal network access.

1 accessFile(Principal,Host,AccessPerm,Path).

3 accessDataFlow(Principal,FlowName,AccessPerm).

4 accessDataFlow(Principal,FlowName,view):-

5 l2Connection(HostA,HostB,WirelessRange,Prot,wireless),

6 located(SideHost,WirelessRange,physical),

7 localAccess(Principal,SideHost,admin),

8 dataFlow(HostA,HostB,FlowName,Direction).

9 accessDataFlow(Principal,FlowName,view):-

10 l2Connection(HostA,RelayHost,WirelessRange,Prot,wireless),

11 located(SideHost,WirelessRange,physical),

12 localAccess(Principal,SideHost,admin),

13 dataFlow(HostA,FlowName),

14 relay(RelayHost,FlowName).

16 accessLinkFlow(Principal, SrcHost, DstHost, Prot, AccessPerm)).

17 accessE2EFlow(Principal, SrcHost, DstHost, Prot, Port, AccessPerm)).

Listing 6: Principal data access.

The T ype argument refers to the type of medium (similar to

the l2Connection predicate), and the P rot argument speciﬁes

the protocol used in that medium (e.g., Modbus, WEP). The

ability of a principle to access a host via a shared commu-

nication medium is inferred by the interaction rule in lines

2-4: a principal (P rincipal) with local access to SrcHost

can access DstHost, assuming that they are both connected

to a shared medium LinkID.

In the end-to-end layer, the ability of a principal to access

hosts is represented by the netAccess predicate (line 6), which

indicates that P rincipal can use SrcHost to communicate

with DstHost on a speciﬁc port (P ort) using the protocol

P rot. This fact is inferred by the interaction rule in lines

7-10: a principal (P rincipal) with local access to SrcHost

can communicate with DstHost on P ort using the protocol

P rot if this communication is enabled by the network access

control mechanisms (represented by aclN W ) as well as the

DstHost’s access control mechanisms (represented by aclH).

Data Access (see Listing 6). We distinguish between two types

of data: data at rest and data in motion. Access to data at

rest is modeled in MulVAL by the accessF ile predicate (line

1), which indicates that P rincipal can access ﬁles in P ath

present in Host with AccessP erm permissions (read, write,

or execute). We extend MulVAL to model access to data in

motion as well by deﬁning the accessDataF low predicate

(line 3), which indicates that P rincipal has access to the data

ﬂow denoted by F lowN ame. There are three possible access

types: (1) view - the principal is able to view F lowName

but not necessarily read its content, (2) read - the principal

can read the content of F lowN ame, i.e., see it in plain

text, and (3) write - the principal can manipulate the data in

F lowName. These access types can contain each other: if a

principal can read a data ﬂow, he/she can also view it; and if

a principal can write to a data ﬂow, he/she can also read it.

The interaction rules in lines 4-8 and 9-14 describe the

ability to view wireless trafﬁc. Lines 4-8 describe a sce-

nario in which a principal’s host (SideHost) is located in

the wireless range (W irelessRange) of the communication

between HostA and HostB. Based on the assumption that

SideHost is equipped with a network interface, P rincipal

can capture the wireless trafﬁc in that range. Similarly, lines

9-14, describe a scenario in which the SideHost is positioned

in the broadcast range of a device (e.g., access point) that

is a relay to the communication that the principal wishes to

capture.

To be consistent with the three-layer network model, we

also deﬁned accessLinkFlow and accessE2EFlow predicates

(lines 16-17) in order to represent a principal’s access to the

communication in these layers. We also included interaction

rules to bind protocol vulnerabilities with the data access level

they permit across the network layers. These deﬁnitions are

important, since actual attacks tend to be executed in this

step-by-step manner, thus they make our model realistic and

practical.

Figure 4 presents an example of this. In the ﬁrst step

(denoted by

), an attacker who can access the link layer

(e.g., by connecting his/her laptop to a layer two switch)

can try to exploit link layer vulnerabilities (speciﬁed by the

vulLinkP rotocol predicate). If the attacker succeeds, he/she

will be able to view the end-to-end layer ﬂow (represented by

accessE2EF low with the view access type). In the next step

(denoted by

), the attacker can try to exploit an end-to-end

protocol vulnerability (represented by the vulE2EP rotocol

predicate). If the attacker succeeds, he/she can read the end-to-

end layer ﬂow (represented by accessE2EF low with the read

access type), which means that the attacker can view the data

ﬂow (represented by accessDataF low with the view access

type). In the ﬁnal step (denoted by

), the attacker can try to

read the data ﬂow (represented by accessDataF low with the

read access type) by attempting to exploit data vulnerabilities

(represented by the vulData predicate).

Fig. 4: Inference structure of accessDataFlow with read access

type

E. Host Conﬁguration

To represent host-based attacks we need to be able to

indicate the characteristics of programs (e.g., login service),

data (e.g., credentials), and access control conﬁguration that

are present on the host. All of the predicates related to host

conﬁguration are presented in Listing 7.

Data. Some attack scenarios rely on the attacker’s ability

to access sensitive content. Therefore, we introduce speciﬁc

predicates to represent special data types. The isCredential

predicate indicates that the data denoted by DataName is the

1 isCredential(DataName,Host,User).

2 isNameResolverRecord(DataName).

3 dataBind(DataName,Host,Path).

5 networkService(Host,Prog,Prot,Port,User).

6 isLoginService(Prog).

7 localService(Host,Prog,User).

8 dependsOn(Host,Prog,Library).

9 bugHype(Host,Prog,Range,Consequence).

11 aclH(Host,User,SrcHostOrSubnet,DstHostOrSubnet,Prot,Port).

Listing 7: Host conﬁguration.

credentials of U ser on Host (line 1). This predicate can also

be used to indicate that a data ﬂow contains credentials (e.g.,

in the case of remote login).

Another sensitive data type relates to name resolvers

(e.g., DNS servers), i.e., the binding between a nam-

ing and an IP address. This data is represented by the

isNameResolverRecord predicate (line 2), which is used

in the modeling of the DNS spooﬁng attack (see subsection

V-A).

In addition, we provide the dataBind predicate (line 3) to

associate data (DataName) with a speciﬁc path (P ath) in a

host (Host).

Program. MulVAL deﬁnes two types of programs: network

services and login services. A network service is a program

running under some user permissions on the host while listen-

ing on a speciﬁc port and communicates with other instances

using a speciﬁc protocol (line 5). A login service is a program

that provides a user the ability to access the host (line 6).

We introduce a third type of program, local service, which

represents any program running on a host, regardless of its

ability to communicate over the network (line 7). This way

we can model multistep attacks that exploit vulnerabilities in

”ofﬂine” services (e.g., exploit a vulnerable PDF reader by

providing it with a malformed ﬁle).

In addition, we include the dependsOn (line 8) and

bugHype (line 9) predicates. The dependsOn predicate in-

dicates that a program (denoted by P rog) running on Host,

depends on some library (denoted by Library). This predicate

is important for representing vulnerabilities that come from

third party libraries or programs.

The bugHype predicate indicates that a software bug is

present in the program (denoted by P rog) running on a

host (denoted by Host). The meaning of the Range and

Consequence arguments is similar to those speciﬁed in the

vulnerability predicates, and are explained in the following

Section.

Access Control. The host-based access control rules are repre-

sented by the aclH predicate (line 11), which indicates that the

local access control mechanism on Host allows User to com-

municate from the host/subnet denoted by SrcHostOrsubnet

with the host/subnet denoted by DstHostOrsubnet on P ort

using the protocol P rot.

F. Vulnerability

Vulnerabilities are modeled in MulVAL using the

vulExists and vulP roperty predicates [23]. These predi-

cates, however, do not provide a clear distinction between

different types of vulnerabilities; thus, we deﬁne three vul-

1 vulHost(Host,VulID,Prog,Range,Consequence).

2 vulHost(Host,VulID,Prog,Range,Consequence):-

3 bugHype(Host,Prog,Range,Consequence).

4 vulHost(Host,VulID,Prog,Range,Consequence):-

5 vulHost(Host,VulID,Library,Range,Consequence),

6 dependsOn(Host,Prog,Library).

Listing 8: Host vulnerability.

1 vulLinkProtocol(LinkID,VulID,Protocol,Range,Consequence).

2 vulLinkProtocol(SrcHost,DstHost,VulID,Protocol,Range,Consequence).

3 vulLinkProtocol(SrcHost,DstHost,VulID,Protocol,Range,Consequence):-

4 vulLinkProtocol(LinkID,VulID,Protocol,Range,Consequence),

5 located(SrcHost,LinkID,Type),

6 located(DstHost,LinkID,Type).

8 vulE2EProtocol(Host,VulID,Protocol,Port,Range,Consequence).

9 vulE2EProtocol(SrcHost,DstHost,VulID,Protocol,Port,Range,Consequence).

Listing 9: Network vulnerability.

nerability predicates according to the assets they affect: host,

network, and data.

Host (see Listing 8). A host vulnerability (e.g., a vulnerability

in a software running on the host) is represented by the

vulHost predicate (line 1) deﬁning a speciﬁc vulnerability

(V ulID) in a program (P rog) that exists in Host. The Range

argument refers to the context in which the vulnerability can

be exploited and can be set to localExploit, adjacent, or

remoteExploit - similar to the attack vector (AV) metric

of CVSS.

We also include interaction rules that represent a

host vulnerability due to an implementation bug (lines 2-3) or

dependency in a vulnerable library (lines 4-6), similar to their

basic deﬁnition in MulVAL [23].

Network (see Listing 9). A network vulnerability (i.e., a

vulnerability in a communication protocol) is represented by

the vulLinkProtocol (lines 1-2) and vulE2EP rotocol (lines

9-10) predicates. The vulLinkP rotocol predicate in line 1

deﬁnes a vulnerability in a link layer protocol denoted by

P rotocol (e.g., ARP, Bluetooth, WEP) that is used in some

communication medium (LinkID) and contains the vulner-

ability V ulID that can be exploited via Range, and results

in Consequence (e.g., eavesdropping, data falsiﬁcation). The

predicate in line 2 has a similar meaning, except that it

provides an indication of a directed communication between

two speciﬁc hosts (SrcHost and DstHost).

We also deﬁne the vulLinkP rotocol interaction rule in lines

3-7, which infers a vulnerable link layer communication

between SrcHost and DstHost from the fact that they are

connected to the same communication medium (LinkID), in

which a vulnerable link layer protocol (P rotocol) is used.

Note that this interaction rule only holds for ipSubnet or bus

medium types.

The vul E2EP rotocol predicate represents the use of an end-

to-end protocol denoted by P rotocol (e.g., HTTP, SMTP) in

the communication between two hosts on port P ort which

contains the vulnerability V ulID that can be exploited via

Range and results in Consequence. The predicate in line

9 indicates that Host is either the source or destination of

the vulnerable communication, and the predicate in line 10

represents a directed vulnerable communication.

Data (see Listing 10). Representing vulnerable data (e.g.,

unencrypted/unsigned communication between two hosts or

https://www.ﬁrst.org/cvss/

unencrypted ﬁles on a host) is important to avoid detection

of false attack paths. For example, an encrypted sensitive

document will be protected from an eavesdropping attacker

even if it is being exchanged between two hosts over FTP. We

distinguish between vulnerable data at rest (e.g., a ﬁle stored

on a host) and vulnerable data in motion (e.g., network trafﬁc

exchanged between two hosts).

Vulnerable data at rest is represented by the vulData pred-

icate (line 1), where Data (e.g., a ﬁle) has the vulnerability

V ulID (e.g., unsigned) which can result in Consequence

(e.g., data falsiﬁcation). We also provide the ability to associate

a vulnerability with a speciﬁc range in some host’s memory

by deﬁning the vulBind predicate (line 2). This predicate

indicates that upon successful exploitation of V ulID, all of

the data stored in P ath in Host will be affected (e.g., read

by the attacker).

Vulnerable data in motion (i.e., a data ﬂow) is represented

by the vulF low predicate (line 4), which indicates that

F lowName contains a vulnerability denoted by V ulID (e.g.,

unencrypted) that enables Consequence (e.g., eavesdropping).

Since data ﬂows are related to the communication between

two hosts via the network, we infer their vulnerabilities

from communication protocol vulnerabilities. We consider two

vulnerability types: lack of encryption and lack of a signature.

The interaction rule in lines 5-10 describes a scenario of

an insecure data ﬂow between SrcHost and DstHost (rep-

resented by the dataF low and flowBind predicates) that

is exchanged using an insecure end-to-end protocol and an

insecure link protocol (represented by the vulE2EP rotocol

and vulLinkP rotocol predicates), while the payload itself

(e.g., a ﬁle) is not encrypted (represented by the vulData

predicate).

Similarly, in lines 11-17 the ﬂow is only vulnerable within

a speciﬁc zone. This situation can occur when: (1) the ﬂow

is transmitted via a relay host (e.g., a router or proxy) that is

connected to the same zone as SrcHost, in which a vulnerable

link protocol that enables eavesdropping is used (represented

by the vulLinkP rotocol predicate); (2) the ﬂow is transmitted

using a vulnerable end-to-end protocol that can be exploited

from the relay host and enable eavesdropping (represented by

the vulE2EP rotocol predicate). The symmetric case (where

the vulnerability exists in the zone of DstHost) can be deﬁned

in the same manner.

The interaction rule in lines 18-22 describes the scenario of

eavesdropping on an unencrypted link (e.g., bus). In order

for data to be vulnerable to link eavesdropping, it should

be unencrypted (represented by the dataF low and vulData

predicates) and it should also be transmitted via a vulnera-

ble link protocol (represented by the vulLinkP rotocol and

flowBind predicates).

The interaction rule in lines 23-27 describes a scenario in

which unsigned data (represented by the dataF low and

vulData predicates) is transmitted via a vulnerable end-to-

end protocol that enables data falsiﬁcation (represented by the

vulE2EP rotocol and f lowBind predicates).

1 vulData(Data,VulID,Consequence).

2 vulBind(Host,VulID,Path).

4 vulFlow(FlowName,VulID,Consequence).

5 vulFlow(FlowName,unencrypted,Consequence):-

6 dataflow(SrcHost,DstHost,FlowName),

7 flowBind(FlowName,E2EProtocol,E2EPort),

8 vulE2EProtocol(SrcHost,DstHost,VulID1,E2EProtocol,E2EPort,E2ERange,

eavesdropping),

9 vulLinkProtocol(SrcHost,DstHost,VulID2,LinkProtocol,LinkRange,eavesdropping

10 vulData(FlowName,unencrypted,Consequence).

11 vulFlow(FlowName,unencrypted,Consequence):-

12 vulE2EProtocol(SrcHost,DstHost,VulID1,E2EProtocol,E2EPort,relayingHost,

eavesdropping),

13 vulLinkProtocol(SrcHost,RelayHost,VulID2,LinkProtocol,LinkRange,

eavesdropping),

14 relay(RelayHost,FlowName),

15 vulData(FlowName,unencrypted,Consequence),

16 dataflow(SrcHost,DstHost,FlowName),

17 flowBind(FlowName,E2EProtocol,E2EPort).

18 vulFlow(FlowName,unencrypted,Consequence):-

19 vulLinkProtocol(SrcHost,DstHost,VulID,Protocol,Range,eavesdropping),

20 vulData(FlowName,unencrypted,Consequence),

21 dataflow(SrcHost,DstHost,FlowName),

22 flowBind(FlowName,Protocol,_).

23 vulFlow(FlowName,unsigned,dataFalsification):-

24 vulE2EProtocol(SrcHost,DstHost,VulID,Protocol,Port,reayingHost,

dataFalsification),

25 vulData(FlowName,unsigned,dataFalsification),

26 dataflow(SrcHost,DstHost,FlowName),

27 flowBind(FlowName,Protocol,Port).

Listing 10: Data vulnerability.

V. ATTACK MODELING

In this section, we demonstrate how the proposed network

modeling can be used to model network attacks, including:

spooﬁng attacks, denial of service attacks (DoS), man-in-the-

middle (MITM) attacks, attacks on wireless communication,

and attacks on bus network architecture.

A. Spooﬁng Attacks

We distinguish between two types of spooﬁng attacks:

spooﬁng in the link layer, in which the attacker can spoof the

entire communication between the two hosts, and spooﬁng

in the end-to-end layer, in which the attacker can spoof a

speciﬁc service. These two scenarios are represented using

two predicates: spoof LinkHost (Listing 11, line 1) and

spoofE2EHost (Listing 12, line 1), which specify that a prin-

cipal (P rincipal) can impersonate ImpersonatedHost and

fool F ooledHost using the Spoof ingHost by utilizing a vul-

nerability in a link/end-to-end protocol. The Consequence ar-

gument provides an indication about the outcome of the spoof-

ing attack: (1) the trafﬁc is routed via SpoofingHost, e.g., in

an ARP spooﬁng scenario (Consequence = traff icT hef t);

(2) P rincipal can only deceive F ool edHost, e.g., in bus

spooﬁng scenarios (Consequence = deception). We modeled

the ARP and DNS spooﬁng attacks using these two predicates.

ARP Spooﬁng (see Listing 11). ARP spooﬁng is a technique

by which an attacker can route the trafﬁc intended for some

host to the attacker’s machine. The attacker achieves this by

sending fake ARP messages to a local area network (LAN)

in order to associate the attacker’s MAC address with the

IP address of the victim’s host. In order to perform an ARP

spooﬁng attack, two preconditions must be satisﬁed: (1) the

impersonated host must use the vulnerable ARP protocol; and

(2) the attacker must be able to access the impersonated host

via the link layer.

In our modeling we consider two ARP spooﬁng scenarios:

a scenario in which the impersonated and fooled hosts reside

in the same subnet (lines 3-5), and a scenario in which they

1 spoofLinkHost(Principal,ImpersonatedHost,FooledHost,SpoofingHost,Consequence).

3 spoofLinkHost(Principal,ImpersonatedHost,FooledHost,AttackerHost, trafficTheft

):-

4 vulLinkProtocol(FooledHost,ImpersonatedHost,VulID,Prot,adjacent,

impersonateDst),

5 l2Access(Principal,AttackerHost,ImpersonatedHost,Prot,Zone,ipSubnet).

6 spoofLinkHost(Principal,ImpersonatedHost,FooledHost,AttackerHost,trafficTheft)

7 vulLinkProtocol(RelayHost,ImpersonatedHost,VulID,Prot,adjacent,

impersonateDst),

8 l2Access(Principal,AttackerHost,ImpersonatedHost,Prot,Subnet,ipSubnet),

9 dataFlow(FooledHost,ImpersonatedHost,FlowName),

10 isGateway(RelayHost,Subnet).

Listing 11: ARP spooﬁng.

reside in different subnets (lines 6-10). The two preconditions

for performing this attack are represented in both scenarios by

the vulLinkP rotocol and l2Access predicates.

DNS Spooﬁng (see Listing 12). In our modeling, we consider

three DNS spooﬁng scenarios: (1) a scenario in which the

attacker spoofs as the name server and provides malicious

binding for legitimate requests, (2) a scenario in which the

attacker provides a fake response by utilizing a race condition

(i.e., answers faster than the legitimate server), and (3) a

scenario in which the attacker changes DNS records in the

name server/host cache.

The ﬁrst DNS spooﬁng scenario can be represented di-

rectly by the spoof E2EHost interaction rules that result in

trafficT heft, in which the argument ImpersonatedHost

matches the identiﬁer of the DNS server.

The second DNS spooﬁng scenario is more complicated,

since the attacker utilizes the response time of a higher DNS

resolver in order to send a fake response to the querying

DNS server, binding the attacker’s host’s IP address to the

queried naming. Hence, in order to execute this attack, the

DNS server should communicate using a vulnerable version

of the DNS protocol. As can be seen in lines 3-6, this prereq-

uisite is represented by the isNameResolver and netAccess

predicates. Following the successful execution of this attack,

the querying host (F ooledHost) will initiate communication

with the attacker’s host (which can be AttackerHost or any

other host) instead of the real host.

The third DNS spooﬁng scenario can be executed by gaining

access to the DNS server with admin privileges. We modeled

this scenario in lines 7-11; as can be seen, the attacker

(P rincipal) can log in using local access (localAccess pred-

icates) to the DNS server and modify the DNS records to

associate the attacker’s host with a naming of his/hers choice.

The success of the attack depends on the ability of the

fooled host to access the attacker’s host through the network

(expressed by the netAccess predicate). Alternatively, this

scenario can be executed by gaining write access permission

to some path in the DNS server, which happens to contain a

DNS record. We modeled this scenario in lines 12-16.

B. Denial of Service Attacks

We extend MulVAL’s dos predicate in order to indicate who

is performing the attack (see Listing 13, line 1) as well as

to support host-based (lines 3-7) and network-based (lines

8-13) DoS attacks. In a host-based DoS attack, the attacker

P rincipal (represented by the malicious predicate) exploits

his/her login access to Host (represented by the localAccess

1 spoofE2EHost(Principal,ImpersonatedHost,FooledHost,SpoofingHost,Prot,Port,

Consequence).

3 spoofE2EHost(Principal, ImpersonatedHost, FooledHost, AttackerHost, Prot, Port

, trafficTheft):-

4 isNameResolver(NameResolver, FooledHost, ImpersonatedHost),

5 vulE2EProtocol(FooledHost, NameResolver, dnsCachePoisoning, dns, DNSPort,

remoteExploit, dataFalsification),

6 netAccess(Principal, AttackerHost, NameResolver, dns, DNSPort).

7 spoofE2EHost(Principal, ImpersonatedHost, FooledHost, AttackerHost, Prot, Port

, trafficTheft):-

8 isNameResolver(NameResolver, FooledHost, ImpersonatedHost),

9 localAccess(Principal, NameResolver, admin),

10 netAccess(Principal2, FooledHost, AttackerHost, Prot, Port),

11 localAccess(Principal, AttackerHost, User).

12 spoofE2EHost(Principal, ImpersonatedHost, FooledHost, AttackerHost, Prot, Port

, trafficTheft):-

13 isNameResolver(NameResolver, FooledHost, ImpersonatedHost),

14 accessFile(Principal, NameResolver, write, RecoredPath),

15 dataBind(NameResolverRecord, NameResolver, RecoredPath),

16 isNameResolverRecord(NameResolverRecord).

Listing 12: DNS spooﬁng.

1 dos(Principal,Host).

3 dos(Principal,Host):-

4 localAccess(Principal,Host,User),

5 localService(Host,Prog,User),

6 vulHost(Host,VulID,Prog,localExploit,dos),

7 malicious(Principal).

8 dos(Principal,DstHost):-

9 networkService(DstHost,Prog,Prot,Port,NetworkServiceUser),

10 aclH(DstHost,NetworkServiceUser,SrcHost,DstHost,Prot,Port),

11 vulHost(DstHost,VulID,Prog,remoteExploit,dos),

12 netAccess(Principal,SrcHost,DstHost,Prot,Port),

13 malicious(Principal).

Listing 13: DoS attacks.

predicate) which runs a vulnerable service that allows DoS

(represented by the localService and vulHost predicates). In

a network-based DoS attack, the attacker P rincipal exploits

his/her access to a network service running on DstHost

(represented by the netAccess, aclH, and networkService pred-

icates), which contains a vulnerability that enables DoS upon

successful exploitation (represented by the vulHost predi-

cate).

C. Man-in-the-Middle Attacks

A man-in-the-middle (MITM) attack is a scenario in which

the attacker manages to pose as a relay of the communication

between two hosts. We distinguish between a MITM attack

in the link layer (Listing 14, lines 1-6), in which the entire

communication between SrcHost and DstHost is routed

through the attacker’s host (AttackerHost); and a MITM

attack in the end-to-end layer (Listing 14, lines 8-12), in which

only a speciﬁc application layer protocol (represented by the

P ort and P rot arguments) is routed through the attacker’s

host.

D. Attacks on Wireless Communication

One of the main contributions of this work is the ability

to model attacks on wireless communication. Speciﬁcally,

we model two common attacks on wireless protocols: WEP

cracking and Bluetooth PIN cracking, both of which enable

the attacker to derive the encryption key used for the secured

communication.

WEP Cracking (see Listing 15). The Wired Equivalent Pri-

vacy (WEP) algorithm is based on the RC4 stream cipher

which has weak key scheduling and uses a small initial vector

(IV) of 24 bits [24]. In order to crack WEP’s encryption, the

following two preconditions must be satisﬁed: (1) the attacker

must capture a large amount of legitimate packets transmitted

to/from the access point; and (2) the access point must use the

1 mitmLink(Principal,SrcHost,DstHost,SpoofingHost):-

2 spoofLinkHost(Principal,SrcHost,DstHost,SpoofingHost,trafficTheft),

3 spoofLinkHost(Principal,DstHost,SrcHost,SpoofingHost,trafficTheft).

4 relay(MITMHost,FlowName):-

5 mitmLink(Principal,SrcHost,DstHost,MITMHost),

6 dataFlow(SrcHost,DstHost,FlowName,Direction).

8 mitmE2E(Principal,SrcHost,DstHost,SpoofingHost,Prot,Port):-

9 spoofE2EHost(Principal,SrcHost,DstHost,SpoofingHost,Prot,Port,trafficTheft)

10 spoofE2EHost(Principal,DstHost,SrcHost,SpoofingHost,Prot,Port,trafficTheft)

11 relay(MITMHost,SrcHost,DstHost,Prot,Port):-

12 mitmE2E(Principal,SrcHost,DstHost,MITMHost,Prot,Port).

Listing 14: MiTM attacks.

1 crackAPEncKey(Principal,AP):-

2 malicious(Principal),

3 accessDataFlow(Principal,FlowName,view),

4 relay(AP,FlowName),

5 isAP(AP,WirelessRange,DstZone,Prot,secured),

6 vulLinkProtocol(WirelessRange,weakEncryption,Prot,remoteExploit,

keyExtraction).

8 accessDataFlow(Principal,FlowName,read):-

9 crackAPEncKey(Principal,AP),

10 relay(AP,FlowName),

11 dataFlow(Host,FlowName),

12 flowBind(FlowName,Prot,Port),

13 vulE2EProtocol(Host,VulID,Prot,Port,remoteExploit,eavesdropping),

14 isAP(AP,WirelessRange,DstZone,WirelessProt,secured),

15 located(AttackerHost,WirelessRange,physical),

16 localAccess(Principal,AttackerHost,admin).

18 isAuthenticated(Principal,AttackerHost,AP):-

19 crackAPEncKey(Principal,AP),

20 isAP(AP,WirelessRange,DstZone,Prot,secured),

21 localAccess(Principal,AttackerHost,admin),

22 located(AttackerHost,WirelessRange,physical).

Listing 15: WEP cracking attack.

vulnerable WEP protocol. Afterwards the attacker can crack

the encryption key by performing ofﬂine analysis [24]. These

two preconditions are modeled by the crackAP EncKey in-

teraction rule (lines 1-6), which utilizes the accessDataF low,

relay, isAP , and vulLinkP rotocol predicates.

By cracking the encryption key, the attacker can (1)

eavesdrop on all of the trafﬁc broadcasted by the com-

promised access point; and (2) authenticate to the access

point. These two different consequences are represented by

the accessDataF low and isAuthenticated interaction rules

(lines 8-22).

WPA2 Key Reinstallation. (see Listing 16). The Wi-ﬁ Pro-

tected Access II (WPA2) protocol is widely used for protecting

wireless networks. The Key Reinstallation Attack on the

WPA2 protocol, which exploits a vulnerability in the 4-way

handshake and tricks the victim into reinstalling an already

in-used key, was published in 2017 by Vanhoef and Piessens

[25]. The 4-way handshake is used for assuring that both client

and access point has the correct credentials, and to negotiate

an encryption key for encrypting future communication. The

encryption key is installed in the client after receiving the

handshake message. If no acknowledgment is received

(i.e., the 4

handshake message), the access point might

retransmit the 3

handshake message to handle messages loss.

Upon receiving this message, the client reinstalls the same

encryption key and resets the nonce, which is also used in

the derivation of the encryption key. As a result, an already

used encryption key with a previously used nonce is used

to further encrypt packets. Then, the attacker can derive the

WPA2’s encryption protocols keystream by using an encrypted

message with a known content (or other methods when no such

messages are found). In short, the key reinstallation attack

is performed by the following two steps: (1) The attacker

1 accessLinkFlow(Principal, Host, AP, Protocol, read):-

2 malicious(Principal),

3 localAccess(Principal, AttackerHost, admin),

4 located(AttackerHost, WirelessRange, physical),

5 flowBind(Flowname, Protocol, Port),

6 isCredential(Flowname, DstZone, User),

7 vulLinkProtocol(WirelessRange, VulID, Protocol, adjacent, keyReinstallation

8 isAP(AP, WirelessRange, DstZone, Protocol, secured),

9 located(Host, WirelessRange, physical).

10 crackAPEncKey3(Principal, Host, AP):-

11 malicious1(Principal),

12 accessLinkFlow5(Principal, Host, AP, Protocol, read),

13 isAP5(AP, WirelessRange, DstZone, Protocol, secured),

14 vulLinkProtocol5(WirelessRange, VulID1, Protocol, adjacent,

keyReinstallation),

15 vulHost5(Host, VulID2, wpaSupplicant, localExploit, keyExtraction).

Listing 16: WPA2 key reinstallation attack.

becomes a MITM between the host and the access point (e.g.,

by channel-based MITM technique [26]); and (2) the attacker

prevents the 4

handshake message from reaching the access

point, which causes the retransmission of the 3

message.

This scenario is represented by the interaction rule in

lines 1-9. Lines 1-4 and 9 describe that the attacker’s host

(AttackerHost) and the victim’s host (Host) are located in

the same zone, so that the attacker is able to perform the ﬁrst

step of the attack (MITM). The f lowBind predicate in line 5

suggests that a data ﬂow is transmitted using a speciﬁc proto-

col; in addition, the isCredential predicate in line 6 provides

indication that this data ﬂow is part of the protocol’s handshake

(which the attacker plans to interrupt). Lines 7-8 describe that

the access point that deﬁned the zone (W irelessRange), in

which both the attacker’s host and victim’s host are locates,

uses a vulnerable communication protocol version that allows

the execution of the key reinstallation attack. Thus, enabling

the attacker to decipher future communication between the

victim’s host and the access point.

Furthermore, the authors in [25] found an additional vul-

nerability in several WPA2 implementations that reinstall an

all-zero encryption key upon retransmission of 3

handshake

message. The corresponding interaction rule is presented in

lines 10-15. This rule uniquely described this version of the

key reinstallation attack by requiring that the communication

protocol will be vulnerable to key reinstallation attack and that

the victim’s host (Host) will run a vulnerable version of the

process (wpa supplicant) that enables for reinstalling the all-

zero key. The accessLink F low in line 12 implies that the

attacker (P rincipal) managed to crack the encryption of the

communication protocol (P rotocol) that is used to communi-

cate with the access point; together with the requirement vul-

nerability requirement in line 14, the accessLinkF low pred-

icate should represent the successful exploitation of the key

reinstallation attack (i.e., the rule in lines 1-9 is derived). Note

that since the attacker knows the actual key after performing

this attack (sequence of zeros), this scenario is represented by a

CrackAP EncKey rather than an acessLinkF low predicate.

Bluetooth PIN Cracking (see Listing 17). In 2005, Shaked

et al. [27] presented a method for cracking the shared secret

(referred to as PIN code) of two devices establishing a

Bluetooth communication (using ofﬂine analysis). In order to

execute the attack, the attacker must eavesdrop on the entire

pairing process between the two devices. This precondition

1 crackPINCode(Principal,SrcHost,DstHost):-

2 malicious(Principal),

3 accessDataFlow(Principal,FlowName,read),

4 dataFlow(SrcHost,DstHost,FlowName,Direction),

5 flowBind(FlowName,bluetooth,_),

6 isPairingProcess(FlowName).

8 accessDataFlow(Principal,FlowName,read):-

9 crackPINCode(Principal,SrcHost,DstHost),

10 dataFlow(SrcHost,DstHost,FlowName,Direction),

11 flowBind(FlowName,bluetooth,_),

12 located(AttackerHost,BluetoothRange,physical),

13 localAccess(Principal,AttackerHost,admin).

Listing 17: PIN cracking attack.

is represented by the crackP IN Code interaction rule (lines

1-6). As can be seen, the attacker P rincipal (represented by

the malicious predicate) can read the messages exchanged by

two devices (represented by the accessDataF low, dataF low,

and f lowBind predicates) during their pairing process (repre-

sented by the isP airingP rocess predicate). After capturing

the messages, the attacker can perform the ofﬂine analysis

presented in [27]. The consequence of this attack is that the

attacker acquires the capability to decipher the communication

between SrcHost and DstHost; we represent this capability

using the accessDataFlow interaction rule (lines 8-13).

E. Attacks on Bus Communication

Another major contribution of our work is the deﬁnition

of serial bus topology, which can be found in critical infras-

tructure. In this section, we describe how DoS and spooﬁng

attacks can be applied to bus architecture and how they can

be modeled using our suggested network modeling.

Denial of Service. In bus topology, all of the devices are

physically connected to the same physical medium in order to

communicate. A DoS attack on a serial bus can be executed

in several ways, e.g., a compromised device can continually

broadcast data and cause collisions on the bus, or a compro-

mised device can broadcast data when detecting a data transfer

to/from a speciﬁc device in order to prevent it from requesting

service or transmitting data (i.e., DoS for a speciﬁc device).

Therefore, just one of the devices connected to a bus needs to

be compromised in order to cause a DoS for all of the other

connected devices.

To represent these scenarios, we deﬁne the dos interaction

rule (Listing 18, lines 1-3), which reﬂects the fact that the

attacker P rincipal (represented by the malicious predicate)

can utilize his/her local access (i.e., login or ability to execute

code) to a device connected to a bus in order to deny service

to any other device connected to that bus (represented by the

l2Access predicate).

Master/Slave Spooﬁng. Spooﬁng attacks on serial protocols

are largely feasible due to the lack of authentication (e.g.,

serial Modbus used in OT systems). In our current modeling,

we only consider master/slave buses. We distinguish between

two spooﬁng scenarios: (1) a compromised device connected

to the bus masquerades as the master and sends fake data

and commands, and (2) a compromised device connected to

the bus masquerades as a slave and sends false data. We

distinguish between these two cases, since the abilities of

the attacker can be affected by the role of the compromised

component (i.e., a master or slave). Since we represent serial

1 dos(Principal,DstHost):-

2 malicious(Principal),

3 l2Access(Principal,SrcHost,DstHost,Port,BusID,bus).

5 spoofLinkHost(Principal,ImpersonatedHost,FooledHost,AttackerHost,deception):-

6 vulLinkProtocol(ImpersonatedHost,FooledHost,VulID,Prot,adjacent,

impersonateSrc),

7 l2Connection(AttackerHost,FooledHost,BusID,Prot,bus),

8 localAccess(Principal,AttackerHost,User),

9 isMaster(ImpersonatedHost,BusID).

10 spoofLinkHost(Principal,ImpersonatedHost,FooledHost,AttackerHost,deception):-

11 vulLinkProtocol(ImpersonatedHost,FooledHost,VulID,Prot,adjacent,

impersonatedSrc),

12 l2Connection(AttackerHost,FooledHost,BusID,Prot,bus),

13 localAccess(Principal,AttackerHost,User),

14 isSlave(ImpersonatedHost,BusID).

Listing 18: Attacks on serial bus.

bus communication, the bus spooﬁng attack scenarios are

represented as spoofLinkHost interaction rules.

The master spooﬁng scenario is represented by the interac-

tion rule in Listing 18, lines 5-9. In this scenario, the attacker

P rincipal can log in to the AttackerHost (represented by

the localAccess predicate) which is connected to the same bus

as F ooledHost (represented by the l2Connection predicate).

By exploiting a vulnerability in the communication protocol

used by ImpersonatesHost and F ooledHost (represented

by the vulLinkP rotocol predicate), P rincipal is able to

impersonate as ImpersonatesHost, which is the master in

the bus (isM aster).

The slave spooﬁng scenario is represented by the interaction

rule in Listing 18, lines 10-14, which is similar to the master

spooﬁng scenario, except for the fact that ImpersonatesHost

is a slave in the bus (represented by the isSlave predicate)

and not the master.

VI. PROTOTYPE IMPLEMENTATION OF AUTOMATIC FACT

GENERATION PROCESS

The main advantage of MulVAL over other attack graph

solutions is that it provides an end-to-end framework for

attack graph generation. In order to preserve this strength,

we developed a prototype system which automatically collects

relevant information from the target system and generates the

facts about the system with respect to the new network model-

ing (presented in Section IV). This prototype implements the

following four fact generation methods:

Scan: facts that are generated directly from scan results; i.e.,

there is a complete mapping between the predicate’s arguments

and data in the scan results. A summary of the various tools

that are used by the prototype system is presented in Table

I. It should be noted that the current version of the prototype

implementation supports the scanning of IP networks only.

Knowledge: facts that are generated using a knowledge base.

The knowledge base contains general and system speciﬁc

information, such as program characteristics, system conﬁg-

uration, etc.

Assumption: facts that are generated with default values (e.g.,

unknown or a wildcard).

Manual: facts that are generated manually, based on in-

formation provided by the operator/security expert, such as

attackerLocated, attackGoal and malicious(attacker).

A complete mapping of the four methods to predicates is

presented in Appendix C.

Fig. 5: Testbed network topology

VII. EVALUATION

In order to evaluate the application of our proposed mod-

eling in a real environment, we established an operational

testbed simulating a simple thermal power plant process (see

Figure 5).

The testbed consists of: ﬁve generators, a boiler, a control

panel, three programmable logic controllers (PLCs), an engi-

neering work station (EWS), a historian, a human machine

interface (HMI), a Windows workstation, a Windows server,

a DNS server, an access point, and a laptop. There are two

subnets: IT Network (the enterprise environment) and OT Net-

work (the OT environment) which are connected by a ﬁrewall.

IT Network is also connected to the Internet. Bluetooth Zone

deﬁnes the range in which PLC#1 can communicate with

Generator#3 using Bluetooth. IT Wiﬁ Zone is deﬁned by the

access point (denoted by AP), which provides access to IT

Network for each authorized wireless device (e.g., the laptop)

within IT Wiﬁ Zone. DNS Server is the name resolver in IT

Network, which uses a vulnerable DNS protocol and accepts

incoming communication from any host in IT Network.

The enterprise hosts, HMI, EWS, and historian are virtual

machines, that run a Windows Operating System, except for

the historian which runs Linux. The behavior of the boiler and

generators is simulated in the PLCs. In order to collect real

data from the testbed, we connect an instance of the prototype

system to each network switch (denoted by agent in Figure

5).

To ease readability, the graphs’ nodes are marked as follows:

blue nodes are associated with the system’s topology and

connectivity; red nodes are associated with vulnerabilities and

the attacker’s state; orange nodes are associated with software

and services; and purple nodes are associated with data ﬂows.

In this section, we evaluate the attack scenarios presented

in Section V.

TABLE I: Information collected by the agent

Type Information collected Tools (Windows/Linux)

Topology IP address, netmask, etc. nmap

OS information Type and version nmap

Software and services

Network: port number, protocol, service name, etc. nmap, netstat

Local: ID, name, executable, user, etc. WMI / dpkg-query, rpm, ps (login)

Users and groups ID, name, type, access permissions, etc. WMI/passwd or sudo ﬁle (login)

Firewall Host-based ﬁrewall rules netstat ﬁrewall, advﬁrewall/ iptables-save, iptables-xml

Vulnerability CVE-ID, CVSS score, CWE, related CPEs, etc. OpenVAS, NVD

A. ARP Spooﬁng Attack

Commonly used in IP networks, ARP is also used in the OT

Network. For simplicity and readability of the attack graph,

we assume that the attacker has already managed to gain

access to the HMI in order to execute the attack. After placing

him/herself in the OT Network, the attacker can further exploit

the use of ARP to impersonate any of the components in

the subnet and eventually obtain a MITM position in the

communication between the components. The attack graph

presented in Figure 6 illustrates the attacker’s steps in this

attack scenario, where the attacker’s goal is to become a

MITM in the communication between EWS and PLC#1. Since

the attacker is located in HMI (nodes 7-9), which resides

in the OT network as EWS and PLC#1 (nodes 15, 18, 23),

he/she can access them both utilizing ARP that is used in

this subnet (nodes 5-6, 10-12, 29-32). Then, by exploiting the

vulnerable ARP bidirectional communication between EWS

and PLC#1 (nodes 19-20, 26, 33-34), the attacker is able to

impersonate both EWS and PLC#1 (nodes 3-4, 27-28). Finally,

as a result of this bidirectional spooﬁng which causes the entire

communication between EWS and PLC#1 to be routed via the

attacker, we infer that the attacker is a MITM (nodes 1-2).

1-2 mitmLink(attacker, ’EWS’,’PLC1’, ’HMI’)

3-4 spoofLinkHost(attacker, ’PLC1’, ’EWS’,

’HMI’, trafﬁcTheft)

5-6 l2Access(attacker, ’HMI’, ’PLC1’, arp, ’OT

Network’,ipSubnet)

7-8 localAccess(attacker, ’HMI’, admin)

9 attackerLocated(’HMI’)

10-11 l2Connection(’HMI’, ’PLC1’, ’OT Network’,

arp, ipSubnet)

12 existingProtocol(’OT Network’, arp)

15 located(’PLC1’, ’OT Network’, ipSubnet)

18 located(’HMI’, ’OT Network’, ipSubnet)

19-20 vulLinkProtocol(’EWS’, ’PLC1’, arpSpoof-

ing, arp, adjacent, impersonateDst)

23 located(’EWS’, ’OT Network’, ipSubnet)

26 vulLinkProtocol(’OT Network’, arpSpooﬁng,

arp, adjacent, impersonateDst)

27-28 spoofLinkHost(attacker, ’EWS’, ’PLC1’,

’HMI’, trafﬁcTheft)

29-30 l2Access(attacker, ’HMI’, ’EWS’, arp, ’OT

Network’, ipSubnet)

31-32 l2Connection(’HMI’, ’EWS’, ’OT Network’,

arp, ipSubnet)

33-34 vulLinkProtocol(’PLC1’, ’EWS’, arpSpoof-

ing, arp, adjacent, impersonateDst)

Fig. 6: MITM attack graph.

B. DNS Spooﬁng Attack

In this scenario, an attacker that placed his/her host in the

IT Wiﬁ Zone, manages to connect to the IT Network via AP.

Then, the attacker exploits the vulnerable DNS protocol used

by DNS Server to poison its cache and bind Windows Server’s

naming to the attacker’s IP address; the next time that someone

queries for Windows Server’s address, the attacker’s IP will

be returned, and the user will communicate with the attacker

thinking it is really Windows Server.

The attack graph generated for this scenario is presented

in Figure 7. The attacker can become a part of IT Network

(nodes 10-11) by connecting to AP (nodes 15-17, 20, 23),

which is linked to that subnet. In so doing, the attacker can

communicate with DNS Server (nodes 3-4), since they are

both connected to the same subnet (nodes 5-6, 9-10), and the

attacker controls his/her device’s conﬁguration (nodes 26-29).

Then, the attacker can exploit the vulnerability in the DNS

protocol (nodes 32-33) and execute the DNS spooﬁng attack.

1-2 spoofE2EHost(attacker, ’Windows Server’,

’Windows 7’, ’Attacker Laptop’, , , trafﬁc-

Theft)

3-4 netAccess(attacker, ’Attacker Laptop’, ’DNS

Server’, dns, 53)

5-6 aclNW(’Attacker Laptop’, ’DNS Server’, dns,

53)

9 located(’DNS Server’, ’IT Network’, ipSub-

net)

10-11 located(’Attacker Laptop’, ’IT Network’, ip-

Subnet)

14 located(’AP’, ’IT Network’, ipSubnet)

15 isAP(’AP’, ’IT Wiﬁ Zone’, ’IT Network’,

wep, secured)

16-17 l2Connection(’Attacker Laptop’, ’AP’, ’IT

Wiﬁ Zone’, wep, wireless)

20 located(’Attacker Laptop’, ’IT Wiﬁ Zone’,

physical)

23 isAuthenticated(attacker, ’Attacker Laptop’,

’AP’)

26 aclH(’Attacker Laptop’, admin, ’Attacker

Laptop’, ’DNS Server’, dns, 53)

27-27 localAccess(attacker, ’Attacker Laptop’, ad-

min)

29 attackerLocated(’Attacker Laptop’)

32 vulE2EProtocol(’DNS Server’, ’Windows 7’,

dnsCachePoisoning, dns, 53, remoteExploit,

dataFalsiﬁcation, twoWay)

33 isNameResolver(’DNS Server’, ’Windows 7’,

’Windows Server’)

Fig. 7: DNS spooﬁng attack graph.

C. SYN Flooding Attack

SYN ﬂooding is a network-based DoS attack in which an

attacker starts multiple TCP connections with the target host

but doesn’t complete them. In the vulnerable TCP implemen-

tation, the target host saves all of the half-open connections,

which eventually exhausts the host’s resources and makes it

unresponsive to other connections.

Within the testbed, the Historian supports remote connec-

tion via SSH, which relies on TCP, and contains a vulnerable

TCP implementation that allows the execution of the SYN

ﬂooding attack. In this scenario we assume that the attacker

managed to gain access to Windows Server and execute the

attack from it. The attack graph for this scenario is presented

in Figure 8. The attacker, who is located on Windows Server

(nodes 16-18), can utilize it to start a TCP connection with

Historian on port 22 (nodes 3-4), since both the network-

based and the host’s host-based ﬁrewalls allow this connection

(nodes 5-6, 9, 12 15). The SSH service executed by Historian

(node 29) is vulnerable to the SYN ﬂooding attack (nodes

20-22, 25), and together with the facts that (1) Historian

allows incoming communication from Windows Server on port

22 (node 28), and (2) the attacker is able to initiate this

communication (nodes 3-4), we conclude that the attacker can

perform an SYN ﬂooding attack on Historian (nodes 1-2).

1-2 dos(attacker, ’Historian’)

3-4 netAccess(attacker, ’Windows Server’, ’Histo-

rian’, tcp, 22)

5-6 aclNW(’Windows Server’, ’Historian’, tcp,

22)

9 aclNW(’Windows Server’, ’OT Network’, tcp,

22)

12 located(’Historian’, ’OT Network’, ipSubnet)

15 aclH(’Windows Server’, admin, ’Windows

Server’, ’Historian’, tcp, 22)

16-17 localAccess(attacker, ’Windows Server’, ad-

min)

18 attackerLocated(’Windows Server’)

19 malicious(attacker)

20-21 vulHost(’Historian’, synFlood, ssh, remoteEx-

ploit, dos)

22 dependsOn(’Historian’, ssh, tcp)

25 vulHost(’Historian’, synFlood, tcp, remoteEx-

ploit, dos)

28 aclH(’Historian’, , ’Windows Server’, ’His-

torian’, tcp, 22)

29 networkService(’Historian’, ssh, tcp, 22, )

Fig. 8: SYN ﬂooding attack graph.

D. WEP Cracking Attack

In this scenario, the attacker physically places his/her host

in the range of the access point (i.e., in IT Wiﬁ Zone), which

is connected to IT Network. Based on the assumption that the

attacker’s host is adequately equipped to execute this attack,

we infer that the attacker can capture the wireless signals

transmitted in IT Wiﬁ Zone. The access point uses WEP, which

has a known vulnerability that allows key extraction, as its

security protocol. One of Laptop’s uses is to browse emails

which results in communication with Windows Server.

The attack graph for this scenario is presented in Figure 9.

As can be seen, AP connects IT Network with IT Wiﬁ Zone

(node 12). Since Windows Server is connected to AP in IT

Network (nodes 26-28, 31, 34), and Laptop can connect to

AP in IT Wiﬁ Zone (nodes 11-12, 35-36, 39), we can infer

that AP is a relay to the communication between Laptop and

Windows Server (nodes 21-23). Since the attacker physically

located his/her device in IT Wiﬁ Zone (nodes 3-5 and 8),

the attacker can capture the communication between Laptop

and Windows Server that is transmitted in the wireless zone

(nodes 45-46). Now, the attacker can exploit WEP’s the weak

encryption, which is used by AP (node 44), and perform

ofﬂine analysis on the captured trafﬁc in order to extract AP’s

encryption key (nodes 40-41). There are two consequences of

1-2 accessDataFlow(attacker, emailFlow, read)

3-4 localAccess(attacker, ’Attacker Laptop’, admin)

5 attackerLocated(’Attacker Laptop’)

8 located(’Attacker Laptop’, ’IT Wiﬁ Zone’, physical)

11 isAuthenticated(’LaptopUser’, ’Laptop’, ’AP’)

12 isAP(’AP’, ’IT Wiﬁ Zone’,’IT Network’, wep, secured)

15 vulE2EProtocol(’Laptop’,’Windows Server’, unencrypted, smtp, 25, remoteExploit, eavesdrop-

ping, twoWay)

18 ﬂowBind(emailFlow, smtp, 25)

21 dataFlow(’Laptop’, ’Windows Server’, emailFlow, twoWay)

22-23 relay(’AP’, emailFlow)

26-27 l2Connection(’AP’, ’Windows Server’, ’IT Network’, arp, ipSubnet)

28 existingProtocol(’IT Network’, arp)

31 located(’Windows Server’, ’IT Network’, ipSubnet)

34 located(’AP’, ’IT Network’, ipSubnet)

35-36 l2Connection(’Laptop’, ’AP’, ’IT Wiﬁ Zone’, wep, wireless)

39 located(’Laptop’, ’IT Wiﬁ Zone’, physical)

40-41 crackAPEncKey(attacker, ’AP’)

44 vulLinkProtocol(’IT Wiﬁ Zone’, weakEncryption, wep, remoteExploit, keyExtraction)

45-46 accessDataFlow(attacker, emailFlow, view)

47 malicious(attacker)

48-49 isAuthenticated(attacker, ’Attacker Laptop’, ’AP’)

Fig. 9: WEP cracking attack graph.

this attack: (1) the attacker’s device is authenticated by AP,

thus he/she is able to communicate freely with other hosts in

IT Network (nodes 48-49); (2) the attacker can decipher the

communication between any host and AP (nodes 1-2, 18).

E. Bluetooth PIN Cracking Attack

In this attack scenario, the attacker uses his/her device

in order to capture the communication between two other

Bluetooth components, which enables the attacker to perform

the PIN cracking attack described in Subsection V-D.

In this scenario, the attacker is located in Bluetooth Zone

with Attacker Device that is able to capture Bluetooth com-

munication. The attack graph generated for this scenario is

presented in Figure 10. The attacker, who managed to place

his/her device in Bluetooth Zone (nodes 3-5 and 8), can

view the communication between PLC#1 and Generator#3

(nodes 25-30, 33, 36-37). Given that this communication is the

Bluetooth pairing process (nodes 19, 22), we can infer that the

attacker can perform the PIN cracking attack (nodes 17-18).

After executing this attack, the attacker has the encryption key

of the Bluetooth communication between PLC#1 and Gener-

ator#3 and can read their future communication (nodes 1-2,

11, 14). Since the extracted key is symmetric, the encryption

cracking also applies to the inverse communication direction

(nodes 16-15, 39-17).

1-2 accessDataFlow(attacker, statusUpdate, read)

3-4 localAccess(attacker, ’Attacker Device’, admin)

5 attackerLocated(’Attacker Device’)

8 located(’Attacker Device’, bluetoothZone, physical)

11 ﬂowBind(statusUpdate, bluetooth, )

14 dataFlow(’Generator3’, ’PLC1’, statusUpdate,

oneWay)

15-16 crackPINCode(attacker, ’Generator3’, ’PLC1’)

17-18 crackPINCode(attacker, ’PLC1’,

’Generator3’)17-39

19 isPairingProcess(pairingProcessPlc1Gen3)

22 ﬂowBind(pairingProcessPlc1Gen3, bluetooth, )

25 dataFlow(’PLC1’, ’Generator3’, pairingProcess-

Plc1Gen3, twoWay)

26-27 accessDataFlow(attacker, pairingProcessPlc1Gen3,

view)

28-29 l2Connection(’PLC1’, ’Generator3’, bluetoothZone,

bluetooth, wireless)

30 existingProtocol(bluetoothZone, bluetooth)

33 located(’Generator3’, bluetoothZone, physical)

36 located(’PLC1’, bluetoothZone, physical)

37 inDiscoveryMode(’Generator3’)

38 malicious(attacker)

Fig. 10: Bluetooth PIN cracking attack graph.

F. Bus Denial of Service Attack

To demonstrate attacks on the serial bus, we introduce the

Serial Bus component, which connects PLC#2, two more

generators (Generator#4 and Generator#5), and a third PLC

(PLC#3). The serial Modbus is the communication protocol

in this bus, and the master is PLC#2.

The attack graph generated for this attack scenario is pre-

sented in Figure 11. The attacker is located in HMI (nodes 24-

26), which can communicate with other components connected

to OT Network, in particular with PLC#2 on port 22 (nodes 11-

14, 17, 20, 23). PLC#2 enables remote login via SSH service

(nodes 7, 27). The attacker that managed to obtain PLC#2’s

admin account (node 30) can now connect to it on port 22,

since inbound communication from HMI is allowed (node 10),

enabling the attacker to gain local access (nodes 5-6).

PLC#2 and Generator#4 can communicate via the bus using

the Modbus protocol (nodes 31-33, 36, 39). Since the attacker

has local access to PLC#2 (node 5), we infer that he/she can

abuse it to access Generator#4 via the bus (nodes 3-4) and

thus deny service to Generator#4 (nodes 1-2).

G. Bus Spooﬁng Attacks

The Modbus protocol used in Serial Bus is a master/slave

communication protocol. In this type of communication, only

one component (referred to as the master) is responsible for

managing the operation of the other components (referred to

as slaves) by sending command messages; the slaves only

respond to the master’s commands.

The ﬁrst spooﬁng attack scenario is focused on imper-

sonating the bus master. We demonstrate how an attacker

located in PLC#3 can exploit the lack of authentication in the

serial Modbus protocol and impersonate the master of the bus

(PLC#2) in order to send fake commands to Generator#4. The

attack graph representing this scenario is presented in Figure

12a.

PLC#3 and Generator#4 can communicate via the bus

(nodes 7-9, 12, 15). PLC#2 and Generator#4 can also commu-

1-2 dos(attacker, ’Generator4’)

3-4 l2Access(attacker, ’PLC2’, ’Generator4’, modbus,

’Serial Bus’, bus)

5-6 localAccess(attacker, ’PLC2’, admin)

7 isLoginService(ssh)

10 aclH(’PLC2’, admin, ’HMI’, ’PLC2’,tcp, 22)

11-12 netAccess(attacker, ’HMI’, ’PLC2’, tcp, 22)

13-14 aclNW(’HMI’, ’PLC2’, tcp, 22)

17 located(’PLC2’, ’OT Network’, ipSubnet)

20 located(’HMI’, ’OT Network’, ipSubnet)

23 aclH(’HMI’, admin, ’HMI’, ’PLC2’, tcp, 22)

24-25 localAccess(attacker, ’HMI’, admin)

26 attackerLocated(’HMI’)

27 networkService(’PLC2’, ssh, tcp, 22, admin)

30 hasAccount(attacker, ’PLC2’, admin)

31-32 l2Connection(’PLC2’, ’Generator4’, ’Serial Bus’,

modbus, bus)

33 existingProtocol(’Serial Bus’, modbus)

36 located(’Generator4’, ’Serial Bus’, bus)

39 located(’PLC2’, ’Serial Bus’, bus)

40 malicious(attacker)

Fig. 11: Bus denial of service attack graph.

nicate via the bus using Modbus, which lacks authentication

(nodes 12, 16-17, 20, 23). The attacker can exploit his/her

access to the bus via PLC#3 (nodes 4-6, 15) and Modbus’s

vulnerability and impersonate PLC#2 (the master) against

Generator#4 (nodes 1-3).

The second spooﬁng attack is focused on spooﬁng as a slave

(Generator#5) in order to provide a fake response to the master

(PLC#2). The attack graph (see Figure 12b) is quite similar

to the master spooﬁng scenario; the only difference is that we

require the source of the vulnerable communication (node 16)

to be a slave in the bus (node 3).

VIII. CONCLUSION AND FUTURE WORK

In this paper, we introduce an extended network modeling

for the MulVAL framework and evaluated it in an opera-

tional testbed simulating a simpliﬁed thermal power plant

process. The proposed modeling considers the physical net-

work topology, supports short-range communication protocols,

and models speciﬁc industrial communication architectures.

Furthermore, we model various network attacks, including

bus spooﬁng, WEP cracking, Bluetooth PIN cracking, ARP

spooﬁng, and DNS spooﬁng.

In future work, we plan to (1) extend the capabilities of

the prototype system to support the automatic extraction of

additional facts (such as obtaining information about wireless

devices); (2) model additional network protocols (such as

Zigbee and BLE), wireless communication types (e.g., cellular

communication) including the modeling of device mobility,

and attack techniques; and (3) develop a process which utilizes

the attack graph generated according to the extended modeling

we presented in this paper to associate attack graph nodes with

potential mitigation actions, resulting in a countermeasure plan

that reduces the potential risk to the system.

1-2 spoofLinkHost(attacker, ’PLC2’, ’Generator4’, ’PLC3’,

deception)

3 isMaster(’PLC2’, ’Serial Bus’)

4-5 localAccess(attacker, ’PLC3’, admin)

6 attackerLocated(’PLC3’)

7-8 l2Connection(’PLC3’, ’Generator4’, ’Serial Bus’, mod-

bus, bus)

9 existingProtocol(’Serial Bus’, modbus)

12 located(’Generator4’, ’Serial Bus’, bus)

15 located(’PLC3’, ’Serial Bus’, bus)

16-17 vulLinkProtocol(’PLC2’, ’Generator4’, noAuthentication,

modbus, adjacent, impersonateSrc)

20 located(’PLC2’, ’Serial Bus’, bus)

23 vulLinkProtocol(’Serial Bus’, noAuthentication, modbus,

adjacent, impersonateSrc)

(a) Spooﬁng as bus master attack graph.

1-2 spoofLinkHost(attacker, ’Generator5’, ’PLC2’, ’PLC3’,

deception)

3 isSlave(’Generator5’, ’Serial Bus’)

4-5 localAccess(attacker, ’PLC3’, admin)

6 attackerLocated(’PLC3’)

7-8 l2Connection(’PLC3’, ’PLC2’, ’Serial Bus’, modbus,

bus)

9 existingProtocol(’Serial Bus’, modbus)

12 located(’PLC2’, ’Serial Bus’, bus)

15 located(’PLC3’, ’Serial Bus’, bus)

16-17 vulLinkProtocol(’Generator5’, ’PLC2’, noAuthentication,

modbus, adjacent, impersonateSrc)

20 located(’Generator5’, ’Serial Bus’, bus)

23 vulLinkProtocol(’Serial Bus’, noAuthentication, modbus,

adjacent, impersonateSrc)

(b) Spooﬁng as bus slave attack graph.

Fig. 12: Bus spooﬁng attack graphs.

REFERENCES

[1] C. Phillips and L. P. Swiler, “A graph-based system for network-

vulnerability analysis,” in Proceedings of the 1998 workshop on New

security paradigms. ACM, 1998, pp. 71–79.

[2] O. Sheyner, J. Haines, S. Jha, R. Lippmann, and J. M. Wing, “Automated

generation and analysis of attack graphs,” in Security and privacy, 2002.

Proceedings. 2002 IEEE Symposium on. IEEE, 2002, pp. 273–284.

[3] S. Jajodia, S. Noel, and B. O’Berry, Topological Analysis of Network

Attack Vulnerability. Springer US, 2005, pp. 247–266.

[4] K. Ingols, R. Lippmann, and K. Piwowarski, “Practical attack graph

generation for network defense,” in Computer Security Applications

Conference, 2006. ACSAC’06. 22nd Annual. IEEE, 2006, pp. 121–

130.

[5] X. Ou, W. F. Boyer, and M. A. McQueen, “A scalable approach to

attack graph generation,” in Proceedings of the 13th ACM conference

on Computer and communications security. ACM, 2006, pp. 336–345.

[6] X. Ou, S. Govindavajhala, and A. W. Appel, “Mulval: A logic-based

network security analyzer.” in USENIX Security Symposium. Baltimore,

MD, 2005, pp. 8–8.

[7] “NVD national vulnerability database,” http://www.nvd.nist.gov, [On-

line].

[8] “Nessus security scanner,” http://www.nessus.org, [Online].

[9] J. C. Acosta, E. Padilla, and J. Homer, “Augmenting attack graphs

to represent data link and network layer vulnerabilities,” in Military

Communications Conference, MILCOM 2016-2016 IEEE. IEEE, 2016,

pp. 1010–1015.

[10] L. P. Swiler, C. Phillips, D. Ellis, and S. Chakerian, “Computer-attack

graph generation tool,” in discex. IEEE, 2001, p. 1307.

[11] R. W. Ritchey and P. Ammann, “Using model checking to analyze

network vulnerabilities,” in Security and Privacy, 2000. S&P 2000.

Proceedings. 2000 IEEE Symposium on. IEEE, 2000, pp. 156–165.

[12] R. Ritchey, B. O’Berry, and S. Noel, “Representing tcp/ip connectivity

for topological analysis of network security,” in Computer Security

Applications Conference, 2002. Proceedings. 18th Annual. IEEE, 2002,

pp. 25–31.

[13] S. Jha, O. Sheyner, and J. Wing, “Two formal analyses of attack graphs,”

in Proceedings 15th IEEE Computer Security Foundations Workshop.

CSFW-15, June 2002, pp. 49–63.

[14] P. Ammann, D. Wijesekera, and S. Kaushik, “Scalable, graph-

based network vulnerability analysis,” in Proceedings of the 9th ACM

Conference on Computer and Communications Security, ser. CCS ’02.

ACM, 2002, pp. 217–224. [Online]. Available: http://doi.acm.org/10.

1145/586110.586140

[15] “Common vulnerabilities and exposures dictionary.” http://www.cve.

mitre.com, [Online].

[16] S. Yi, Y. Peng, Q. Xiong, T. Wang, Z. Dai, H. Gao, J. Xu, J. Wang,

and L. Xu, “Overview on attack graph generation and visualization

technology,” in Anti-counterfeiting, security and identiﬁcation (asid),

2013 IEEE international conference on. IEEE, 2013, pp. 1–6.

[17] S. Jajodia, S. Noel, P. Kalapa, M. Albanese, and J. Williams, “Cauldron

mission-centric cyber situational awareness with defense in depth,” in

2011 - MILCOM 2011 Military Communications Conference, Nov 2011,

pp. 1339–1344.

[18] “Cauldron, a cost-effective, nimble, adaptable and automated network vi-

sualization and modeling tool,” https://cyvision.net/cauldron/, [Online].

[19] “Firemon,” http://ﬁremon.com, [Online].

[20] “Skybox security,” http://www.skyboxsecurity.com, [Online].

[21] E. Bacic, M. Froh, and G. Henderson, “Mulval extensions for dy-

namic asset protection,” CINNABAR NETWORKS INC OTTAWA

(ONTARIO), Tech. Rep., 2006.

[22] M. J. Froh and G. Henderson, MulVAL extensions II. Defence R & D

Canada-Ottawa, 2009.

[23] X. Ou and A. W. Appel, A logic-programming approach to network

security analysis. Princeton University Princeton, 2005.

[24] S. Fluhrer, I. Mantin, and A. Shamir, “Weaknesses in the key scheduling

algorithm of rc4,” in Selected Areas in Cryptography, S. Vaudenay and

A. M. Youssef, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg,

2001, pp. 1–24.

[25] M. Vanhoef and F. Piessens, “Key reinstallation attacks: Forcing nonce

reuse in wpa2,” in Proceedings of the 2017 ACM SIGSAC Conference on

Computer and Communications Security. ACM, 2017, pp. 1313–1328.

[26] ——, “Advanced wi-ﬁ attacks using commodity hardware,” in Proceed-

ings of the 30th Annual Computer Security Applications Conference.

ACM, 2014, pp. 256–265.

[27] Y. Shaked and A. Wool, “Cracking the bluetooth pin,” in Proceedings of

the 3rd International Conference on Mobile Systems, Applications, and

Services, ser. MobiSys ’05. New York, NY, USA: ACM, 2005, pp. 39–

50. [Online]. Available: http://doi.acm.org/10.1145/1067170.1067176

APPENDIX A

COMPARISON BETWEEN MULVAL EXTENSIONS

Work Vulnerability Modeling Host Modeling Network Modeling Data Modeling User Modeling Safeguard Modeling

Ou et al.

[6]

(baseline)

Characterized by exploitation

range (local or remote) and

consequence (impacting CIA,

DoS, or privilege escalation);

Associated with a speciﬁc

program running on a host

Characterized by

running programs

Connectivity among

hosts is represented by

the hacl predicate which

is an abstraction of

routing information and

access controls

Associated with paths

in a speciﬁc host and

principals’ access to

ﬁles

User accounts to hosts

and their privileges;

Principal characteristic

(malicious or

incompetent)

–

Bacic et

al. [21]

–

Model host classiﬁcation

(derived from the assets

it contains) and software

availability

Model subnets and

inter-subnet

communication

Model assets/data

value (in terms of

CIA) and classiﬁcation

Model principal’s

clearance level

–

Froh et al.

[22]

–

Model the value of IT

services (in terms of

CIA) and associate them

with host and program

Associate hosts to

networks; Represent

network components

(routers)

Model assets/data

value (in terms of

CIA)

–

Represent security

requirements (e.g.,

applicationAccount)

and incorporate them

in the interaction

rules; Consider their

(or other primitives)

absence an indication

to safeguard

deployment

Liu et al.

[?]

Represent vulnerability

exploitation based on

evidence collected from hosts

– – – – –

Acosta et

al. [9]

Model ARP spooﬁng attack;

Model null/weak

authentication in OLSR

–

Model network

components (gateways;

Model cross-subnet

network access

Represent data ﬂows

(trafﬁc generated by a

user in a speciﬁc

protocol that is

exchanged between

two hosts)

– –

Our

approach

Represent protocol design

vulnerabilities; Represent data

vulnerabilities (e.g., lack of

encryption); Model spooﬁng

attacks, MITM, DoS, and

attacks on wireless and bus

communication

Represent local services

Represent hosts

connectivity at different

network layers;

Represent wireless and

serial communications;

Distinguish between host

and network-based

ﬁrewall rules

Represent speciﬁc data

types (e.g.,

credentials);

Distinguish between

data at rest and data in

motion

Represent user access

to hosts at different

network layers

–

APPENDIX B

COMPLETE INPUT FOR THE MULVAL EXAMPLE

1 /

attacker state and goals

2 attackerLocated(internet).

3 attackGoal(execCode(dbServer,_)).

4 malicious(attacker).

5 /

host connectivity

6 hacl(internet, dbServer, tcp, 1521).

7 hacl(internet, host1, tcp, 80).

8 hacl(internet, host2, tcp, 80).

9 hacl(internet, host3, tcp, 80).

10 hacl(host1, dbServer, _, _).

11 hacl(host2, dbServer, _, _).

12 hacl(host3, dbServer, _, _).

13 hacl(dbServer, host1, _, _).

14 hacl(dbServer, host2, _, _).

15 hacl(dbServer, host3, _, _).

16 hacl(dbServer, host1, _, _).

17 hacl(host2, host1, _, _).

18 hacl(host3, host1, _, _).

19 hacl(host1, dbServer, _, _).

20 hacl(host1, host2, _, _).

21 hacl(host1, host3, _, _).

22 hacl(dbServer, host2, _, _).

23 hacl(host1, host2, _, _).

24 hacl(host3, host2, _, _).

25 hacl(host2, dbServer, _, _).

26 hacl(host2, host1, _, _).

27 hacl(host2, host3, _, _).

28 hacl(dbServer, host3, _, _).

29 hacl(host2, host3, _, _).

30 hacl(host1, host3, _, _).

31 hacl(host3, dbServer, _, _).

32 hacl(host3, host2, _, _).

33 hacl(host3, host1, _, _).

34 /

vulnerability information

35 vulExists(dbServer, 'CVE-2012-3132', oracleDB).

36 vulProperty('CVE-2012-3132', remoteExploit, privEscalation).

37 networkServiceInfo(dbServer ,oracleDB, tcp ,1521 ,root).

38 /

victims host configurations

39 hasAccount(user, victim, localAdmin).

40 inCompetent(user).

APPENDIX C

FACT GENERATION METHODS

Fact Generation method

Description

isLoginService Knowledge, Manual

Utilizing common knowledge or expert input to classify a service as a login service. For example: SSH and Remote

Desktop are known services that enable users to log in to a machine.

networkService Assumption, Scan

Identifying network services directly from scan results. If the Protocol or Port arguments could not be detected, they

are set to unknown; if the User argument is not detected, it is set to a wildcard.

localService Scan

Identify local services directly from host scans.

isCredential Assumption, Manual

Categorize data as containing credentials, for example: if some host runs a program that is deﬁned as both isLoginService

and networkService, an isCredential fact is generated for each existing hasAccount fact involving that host to indicate

that the login data ﬂow contains credentials (i.e., the remote login attempt): the User and Host arguments get the values

of the User and Host arguments of hasAccount predicate, and the DataName argument is set to ”user hostCredentials”

(where user and host correspond to the User and Host arguments of hasAccount predicate).

dataFlow, ﬂowBind Knowledge, Manual

Generate data ﬂows according to common knowledge, for example: the port number can provide an indication about

the protocol used to send some data ﬂow.

dataBind Assumption, Knowledge

Associating data with a speciﬁc path, for example: we know that a DNS server holds an IP to naming mapping in its

cache, but we cannot get this memory mapping from a scan. Thus, in order to represent this knowledge, this data is

associated with a generic representation of this path.

existingProtocol Scan, Manual

Specify which protocol is used within different parts of the network (e.g., the usage of ARP within a subnet) directly

from scan results or from expert’s input.

located Scan

Identify the position of each device in the network directly from scan results.

vulLinkProtocol, vulE2EProtocol Knowledge

Associate protocol vulnerabilities to communications identiﬁed in the network by using a predeﬁned knowledge base

(e.g., NIST NVD).

vulHost Scan

Identify the vulnerabilities in each host directly from scan results (e.g., using Nessus).

vulData Manual

Associate vulnerabilities with data (e.g., unencrypted or unsinged) based on expert’s input.

hasAccount Assumption, Scan

Associate user accounts to hosts directly from scans. If the Principal argument could not be detected, it is set to:

”host nameUser” (where host name is the value of the Host argument); if the User argument could not be detected, it

is set to admin.

localAccess Assumption, Scan

Infer a principal’s access to hosts directly from scans. If the Principal argument could not be detected, it is set as the

hasAccount predicate.

aclNW Assumption, Scan

Infer network-based ﬁrewall rules directly from scans. If a networkService fact with an unknown protocol and port was

generated, a corresponding aclNW with an unknown protocol and port arguments is generated.

aclH Assumption, Scan

Infer host-based ﬁrewall rules directly from scans. Similar to aclNW; if a network service with an unknown protocol

and port was generated, a corresponding aclH is generated, and the User argument is set to a wildcard.