Masaryk University

Faculty of Informatics

Attack Graph Generation

Algorithm Implementation

Bachelor’s Thesis

Jan Klos

Brno, Fall 2018

 Masaryk University
Faculty of Informatics

Attack Graph Generation

Algorithm Implementation

Bachelor’s Thesis

Jan Klos

Brno, Fall 2018

This is where a copy of the official signed thesis assignment and a copy of the
Statement of an Author is located in the printed version of the document.
Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. All sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.

Jan Klos

Advisor: Jana Komárková

i
Acknowledgements
I would like to thank my advisor, RNDr. Jana Komárková, for her
guidance with the thesis. I would also like to thank my colleagues for
their useful advice and to my family for their encouragement.

iii
Abstract
MulVAL is a logic programming based open source framework for
analyzing network for possible attack paths an intruder might take
when exploiting security vulnerabilities. This work is an implemen-
tation of MuPar, a parser that generates MulVAL inputs based on
JSON-formatted description of network topology, physical and virtual
hosts, clusters, running applications, network accesses and vulnerabil-
ity specifications. Inputs generated by MuPar are sourced to MulVAL
to (possibly) generate an attack graph. MuPar is implemented in a
way that allows easy extensibility and straightforward definition of
new vulnerability prerequisites and consequences. Command-line
interface for performing the analysis and conversion of the resulting
graph to JSON format is also provided.

iv
Keywords
attack graph, MulVAL, vulnerability analysis, security analyzer, attack
simulation, interaction rules, MuPar

v
Contents
Introduction 1

1 Attack Graphs 3
1.1 Research and Usage . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Available Tools . . . . . . . . . . . . . . . . . . . . . . . . 4

2 MulVAL 7
2.1 MulVAL Adapters . . . . . . . . . . . . . . . . . . . . . . 7
2.2 MulVAL Analyzer and Graph Generator . . . . . . . . . . . 8
2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Specifications 13
3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Input and Output Specification . . . . . . . . . . . . . . . . 14
3.3 Vulnerability Data Sources . . . . . . . . . . . . . . . . . . 16

4 Implementation 19
4.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Hosts and clusters declaration format . . . . . . . . . . . . 20
4.4 Parsing the input . . . . . . . . . . . . . . . . . . . . . . . 26
4.5 MuPar command line interface and graph generation . . . . 26
4.6 Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Conclusion 29

Bibliography 31

vii
Introduction
Attack graphs are graph-based representations of potential attack
paths an intruder might take in order to compromise computer sys-
tems and networks. They are a useful tool used for identification,
visualization, simulation and analysis of weak spots in cybersecurity
architecture.
Generating attack graphs for real medium-scale and large-scale
networks is a fairly complex task – both implementionally and compu-
tationally – especially if many inputs such as network filtering rules,
running applications, user accounts, credentials and permissions or
virtualization and cluster configurations have to be taken into account
so that a reasonably precise simulation of the security situation in the
network can be performed.
While there is a choice of different attack graph generation tools –
commercial, free or open source – many of them do not fit the criteria
for the task of modelling a sizable modern computer network, failing
in requirements such as computational complexity, extensibility or
interoperability with existing vulnerability scanning solutions and
vulnerability databases. Even more have to be excluded when price
and the amount of active development on the project must be taken
into account.
MulVAL (Multi-host, Multi-stage Vulnerability Analysis Language)
[1] is a framework for generating attack graphs that uses Datalog as
its modeling language. It is an open source project and is therefore
easily extensible. The reasoning engine of MulVAL analyzer scales
with polynomial complexity and is therefore capable of modelling
even enterprise networks of large sizes [2]. MulVAL consists of sev-
eral separately executed parts, out of which the analyzer and graph
generator will be of main interest for the purposes of this thesis.
MuPar has been implemented to address several shortcomings of
the base MulVAL distribution. The most significant one is the absence
of an adapter/parser that would convert all the data required to per-
form an accurate attack simulation from a unified, machine-readable
format to MulVAL Datalog inputs. MuPar sources all required data
(hosts, applications, networks and access rules, vulnerabilities and
their presences on hosts) from one or several JSON files and combines

1
them with an extended rule set that supports, unlike basic MulVAL,
declaration of virtual hosts, subnetworks, clusters and additional vul-
nerability properties.
MuPar also provides a command-line interface to run the parsing,
analysis and graph-generation tasks and adds the possibility to output
the resulting attack graph to JSON format. Most importantly, MuPar
is implemented with extensibility in mind, in order to minimize code
and input format changes required to add new functionality.
This thesis is organized into five chapters. Chapter 1 provides an
insight into the growing body of research regarding attack graphs,
their purpose in cybersecurity and their various applications. It also
provides a brief overview of the available solutions for their genera-
tion.
Chapter 2 describes the MulVAL framework in detail, focusing on
the base distribution’s vulnerability scanner adapters and its analysis
engine that serves as the basis for the MuPar project.
Chapter 3 provides the motivation behind the project, general
specification of inputs and outputs, expected sources of the input data,
a mapping of CVSS [3] metrics to MuPar’s vulnerability specifications.
Chapter 4 contains the technical description of the tool and its
implementation, a sample input file, reasoning behind the program-
matic choices as well as results of verification of MulVAL engine’s
polynomial complexity.
Chapter 5 recapitulates the advantages and addresses the short-
comings of the solution. A brief assessment of the possible future of
the tool and its extensibility potential is provided in this chapter.

2
1 Attack Graphs

1.1 Research and Usage

The concept of an attack graph was first proposed by Phillips and

Swiler in 1998 [4]. In their study the authors presumed that a single
source of all possible attacks and their consequences is available, how-
ever, various potential threats have arisen with time and obtaining
adequate data has became a complex part of a security risk assessment.
The authors have followed up on the concept and presented an attack
graph generation tool utilizing an intermediate database serving as an
unified source of vulnerability information with the intent to import
data from various commercially available network monitoring and
scanning tools[5].
Attack graphs are often utilized for real-life scenario attack pre-
dictions [6, 7], possibly taking a probabilistic approach [8] in order to
quantify the likelihood of the predictions becoming real threats. Simi-
lar approaches combined with quantification of attack consequences
allow for scoring and ranking the resulting attack paths [9]. This al-
lows for a wide range of applications: attack graphs can be used not
simply for identification of network security weak points and predict-
ing attacks, but also for determining the optimized order of applying
security patches to help decide which vulnerabilities should be ap-
proached first if limited resources have to be taken into account [10].
Attack graphs can aid in a cost-benefit analysis of security hardening
[11] and provide insights in network security topology design [12].
Attack graphs may be used in intrusion alerts management: com-
bining information stemming from the graph model with actual vul-
nerability scan results may be used to filter out alerts if the hosts are
not vulnerable to them [13], reducing the number of false positives
(intrusion detection refinement). Combining the knowledge about
possible attack paths and their consequences allows for modeling
multi-stage attacks and group such attacks’ alerts together (attack
correlation).
Since the introduction of the concept, various implementations of
the concept have been utilized, trying to overcome common limita-
tions of the concept. NetSPA system, for instance allows defining and

3
1. Attack Graphs

modeling multiple prerequisites of a vulnerability [14]. A common

issue is the complexity and scalability of visual representations of the
attack graphs when modeling complex multi-stage attacks or large
enterprise networks. To overcome such issue, hierarchical aggregation
of graph elements may be used to reduce the number graph elements
by aggregating them [15]. A taxonomy for attack graph generation
and usage in network security, published by K. Kaynar [16], proposes
classification schemes for the attack graph generation. Another novel
approach further expanding on the topic is to employ machine learn-
ing in modeling attack prerequisites. This has been examined by M.
Ugur Aksu, Kemal Bicakci, M. Hadi Dilek, A. Murat Ozbayoglu and E.
ıslam Tatli and presented on CODASPY ’18 [17] and also used together
with data mining for intrusion detection refinement.

1.2 Available Tools

A recent study – An overview of attack graph building tools by S. Yi
et al. [18] compares various tools for attack graph generation, both
open source and commercial:

∙ MulVAL (Multi-host, Multi-stage Vulnerability Analysis Lan-

guage) [1, 19, 20, 2], described in detail in the next chapter

∙ Attack Graph Toolkit from Carnegie Mellon University [21, 22,

23]

∙ TVA (Topological Vulnerability Analysis), a tool developed by

George Mason University [24, 12]

∙ Cauldron, the commercial version of TVA [25, 13]

∙ NetSPA, by Artz, Lippmann and Ingols in Lincoln Laboratory

of MIT [26, 14]

∙ FireMon Risk Analyzer, the commercial version of NetSPA [27]

∙ A commercial range of products by Skybox Security [28]

4
 1. Attack Graphs

Figure 1.1: Cauldron-generated attack graph before remediation. (from

[13])

Out of the listed tools, only MulVAL and Attack Graph Toolkit are
open source. Whereas MulVAL scales well even in large enterprise
network because of its polynomial complexity, the generation algo-
rithm of Attack Graph Toolkit has exponential complexity, making it
unusable for large-scale networks. Also, Attack Graph Toolkit has not
been updated since 2007.

5
2 MulVAL
MulVAL is a GPL-licensed framework aimed at security practitioners
and administrators to better manage and monitor configurations of
enterprise network systems. It leverages results of existing vulnerabil-
ity databases and scan tools and performs an analysis of the network
in order to generate a potential attack trace [19]. If found, such results
may also help in selection of the correct countermeasures, such as
patching the vulnerable application or operating system, changing
the network configuration or modifying access permissions.

2.1 MulVAL Adapters

CVE (Common Vulnerabilities and Exposures) [29] is a reference sys-
tem containing publicly disclosed security vulnerabilities. It serves as a
vulnerability dictionary built by CVE Numbering Authorities (CNAs),
various organizations from around the world authorized to assign
CVE IDs to vulnerabilities of products within the organizations’ dis-
tinct scope. Such CVE IDs may be used in public announcements of the
vulnerabilities and are used by researchers, vulnerability disclosers,
information technology vendors and serve as keys in vulnerability
databases.
NVD (National Vulnerability Database) is the U.S. Government
security vulnerability database, a product of Information Technology
Laboratory within NIST (National Institute of Standards and Technol-
ogy). NVD contains results of analyses performed on CVEs that have
been published to the CVE dictionary, which results in assignment
of CVSS (Common Vulnerability Scoring System) scores, CWE (Com-
mon Weakness Enumeration) categories, CPE (Common Platform
Enumeration) names and other metadata [30].
MulVAL distribution contains an NVD (National Vulnerability
Database) parser, which downloads the vulnerability specifications
and synchronizes them with a MySQL database instance. The synchro-
nizing script is intended to be run periodically to keep the database in
sync with up-to-date data.
The database data is utilized by MulVAL’s adapters, which trans-
late vulnerability scan tools’ results into MulVAL analyzer input data.

7
2. MulVAL

MulVAL distribution contains two adapters: one which uses OVAL-

formatted [31] reports as its inputs and another one which utilizes
results in Nessus format [32]. The output of the adapters is a declara-
tion of found vulnerabilities on scanned hosts and the classification in
MulVAL analyzer’s input format.

2.2 MulVAL Analyzer and Graph Generator

MulVAL generates the attack trace from a combination of its rule file
(with the possibility of supplementing an additional one) and input
file. Both files use the Datalog syntax: Datalog is a purely declarative
language and a subset of Prolog with efficient evaluation. The attack
simulation runs on XSB, a Prolog dialect extended with support for
tabled resolution in order to improve performance. This allows for a
clear specification of reasoning logic. MulVAL’s rules can be used to
describe common attack scenarios, such as exploiting various kinds
of software vulnerabilities.[20]
The inputs required to perform MulVAL’s analysis contain the
following:

∙ The declaration of vulnerabilities, their classification and conse-

quences, combined together with specification of their presence
on hosts. This information is typically sourced from the MulVAL
adapter.

∙ Hosts and their configuration: what software they run, under

which privileges and in case of network services, what protocol
and port they are utilizing.

∙ Network configuration: ports and protocols of the hosts that are

accessible from specified networks (or another hosts).

∙ Principals, file accesses and permissions: the users of the network

and how they are able to interact with its components.

∙ Interactions: how all these component interact

∙ Attacker specification: what resources are immediately accessi-

ble for them, what network they are located at, their goal

8
 2. MulVAL

MulVAL’s input files are a human readable set of MulVAL primitive

predicates. There are two types of predicates: primitive, represent-
ing preconditions and configuration of the hosts and networks, and
derived, which are defined by the interaction rules and correspond
to postconditions and results of the interaction rules. To improve the
efficiency of the XSB reasoning, derived predicates should be tabled;
this allows the XSB engine to memorize intermediate results. XSB’s
tabling functionality is utilized to avoid loops in attack graphs, the
attack trace generation therefore has polynomial complexity relative
to the size of the analyzed network [2].
Consider the following simplistic scenario as an example: A host
machine webServer is running httpd and is accessible from the inter-
net on the port httpd listens on. Another host fileServer is running
samba which is only accessible from webServer. However, there are also
remote exploit vulnerabilities present in both software:

attackerLocated(internet).
attackGoal(execCode(fileServer, _)).

hacl(internet, webServer, tcp, 80).

hacl(webServer, fileServer, tcp, _).

vulExists(webServer, ’CVE1’, httpd).

vulProperty(’CVE1’, remoteExploit, privEscalation).
vulExists(fileServer, ’CVE2’, _).
vulProperty(’CVE2’, remoteExploit, privEscalation).

networkServiceInfo(webServer, httpd, tcp, 80, u1).

networkServiceInfo(fileServer, samba, tcp, 445, u2).

In such a scenario, attack may gain multi-hop access to ’fileServer’

and attack it through the vulnerability in Samba. MulVAL’s reasoning
engine is therefore able to find an attack path and generate the attack
trace.
MulVAL’s graph generator can then convert the trace into either a
simple text output, two CSV files containing the attack graph’s arcs
and vertices, a DOT file, or visualize the graph to EPS or PDF formats.

9
2. MulVAL

2.3 Limitations
MulVAL is bundled with a basic set of interaction rules specifying
interactions on the network. The bundled rule set only supports 3
categories of exploitable range:

∙ locally exploitable (the attacker must possess the ability to exe-

cute code on the machine)

∙ remotely exploitable (the attacker must possess the ability to

communicate with the vulnerable machine/application)

∙ exploitable by a remote client vulnerability (attacker exploits a

client program)

Similarly, the rule set only supports privilege escalation as a vul-

nerability consequence. The ability to specify virtual hosts (and the
machines they are running on) is also missing. The standard rule set
does not allow to specify combinations of prerequisites for vulnerabil-
ities, nor hosts in a virtualized environment or clusters.

10
 10:hacl(internet,webServer,tcp,80):1 11:attackerLocated(internet):1

9:RULE 6 (direct network access):0

8:netAccess(webServer,tcp,80):0 12:networkServiceInfo(webServer,httpd,tcp,80,u1):1 13:vulExists(webServer,’CVE1’,httpd,remoteExploit,privEscalation):1

7:RULE 2 (remote exploit of a server program):0

5:hacl(webServer,fileServer,tcp,445):1 6:execCode(webServer,u1):0

4:RULE 5 (multi-hop access):0

3:netAccess(fileServer,tcp,445):0 14:networkServiceInfo(fileServer,samba,tcp,445,u2):1 15:vulExists(fileServer,’CVE2’,samba,remoteExploit,privEscalation):1

2:RULE 2 (remote exploit of a server program):0

1:execCode(fileServer,u2):0

Figure 2.1: An example of a MulVAL-generated attack graph

11
2. MulVAL
3 Specifications

3.1 Motivation

Base MulVAL distribution provides all the means necessary to specify

complex rules of interaction (preconditions and consequences) be-
tween the various elements of the network – including attributes and
configurations of such elements – and the attacker, their declared goal
and current advancement in reaching it. However, the base interaction
rules files of MulVAL’s open source distribution leave a lot to be de-
sired and many situations common on modern networks thus cannot
be represented.
Modeling the presence of virtual hosts, specifying the physical
host/hypervisor they are running on and describing virtual machine
escape vulnerabilities is not possible, yet such attacks are becoming
more and more common with the proliferation of virtualization in the
computer industry [33]. The same applies for clusters, whose security
is becoming increasingly important [34]. While the base distribution
allows describing network connectivity and filtering rules between the
hosts and networks, the notion of an "adjacent" network (as defined in
[3]) and the possibility to declare vulnerability prerequisites based on
the hosts being connected to the same subnetwork is missing. Similarly,
MulVAL does not support declaring an attacker possessing physical
access to a host or multiple hosts.
Both OVAL and NESSUS MulVAL Adapters support loading vul-
nerability information from the NVD database and parsing vulnerabil-
ity scanner outputs, generating vulnerability specifications and their
presences on hosts in MulVAL’s Datalog syntax as a result. However,
parsers/converters creating all other required inputs – e.g. network
access specification or account information – are missing. Without
an additional software to generate the remaining data, this must be
provided by manually creating the Datalog-formatted input files. This
is almost unfeasible if medium-scale or large-scale network is to be
modelled with accuracy.
To alleviate these shortcomings, this thesis proposes a parser sourc-
ing all the input data in a unified JSON format, making it easy to write
adapters providing the complete specification of security situation on

13
3. Specifications

the network not only from vulnerability scanner reports and vulnera-
bility database data, but also from exports of various configuration
management tools and firewall rules dumps.

3.2 Input and Output Specification

The input is to be provided as one or more JSON files, depending
on whether all the data is provided by a single adapter, or multiple
adapters utilizing different sources specific to distinct parts of the
specification. The input files shall contain the following information:

∙ Specification of hosts
∙ Specification of clusters
∙ Specification of vulnerabilities
∙ Specification of vulnerabilities detected on hosts (scan results)
∙ Optional specification of network access between hosts (filtering
rules) and networks – such information may also be specified
directly in host entries

A host shall contain:

∙ ID of the host (an unique identifier of the host, e.g. its hostname
in DNS).
∙ Whether the host is a virtual machine or not. If it is the case of a
virtual machine, base VM host must be specified.
∙ Declaration of the host’s network memberships. This may in-
clude network ID, host IP address and network mask. If network
ID specification is omitted, host is considered to be a member of
the ’default’ network. Different networks are considered com-
pletely separated and not connected, unless specified in network
access specifications, and hosts with the same IP addresses and
subnetworks may be declared as long as those network declara-
tions belong to different networks. This allows for declaration of
e.g. internal networks in a cluster.

14
 3. Specifications

∙ Optional declaration of host’s cluster memberships.

∙ Applications running on the host. This includes local applica-

tions and network services. For network applications, protocol
and port must be specified.

∙ Host’s network access declaration. This may be omitted if present

in global network connection and access specification. Either
only source of destination shall be specified, the other being
inferred from the host ID.

∙ Host’s function (e.g. serving as a DNS server for a specific net-

work)

A cluster entry shall contain:

∙ ID of the cluster, unique to the cluster.

∙ Cluster endpoint host (optional). Endpoint host may or may not

be member of the cluster.

∙ Cluster functions (similar to host functions).

∙ Applications running on the cluster. For the purposes of the

attack graph generation, an application running on a cluster is
considered to be (also) running on every cluster host.

A vulnerability entry contains:

∙ Vulnerability ID (e.g. a CVE identifier).

∙ Vulnerability prerequisites and consequences. Each prerequi-

site/consequence includes a name corresponding to a MulVAL
predicate and parameters (both required and optional)

A vulnerability presence entry contains:

∙ Host ID

∙ Vulnerability ID

15
3. Specifications

A network access entry contains:

∙ Source - host, network or subnetwork
∙ Destination - host, network or subnetwork
∙ Protocol
∙ Port

To accommodate for the added functionality such as virtual hosts

or clusters specification, the base MulVAL set must be extended accord-
ingly. To complement the JSON-formatted input, support for JSON-
formatted attack graph output should be implemented: it shall include
all the information provided in formats natively supported by Mul-
VAL, separating edges and vertices of the graph into a separate list.
Command-line interface to perform all MuPar functions shall be
provided, allowing to specify names of the input/output files and
specifying the operation to be performed.

3.3 Vulnerability Data Sources

The work is intended to source vulnerability specifications from NVD.
NVD’s Common Vulnerability Scoring System (CVSS) scores and
categorizes vulnerabilities based on metrics: CVSS 3.0 [3] specifications
of vulnerability categories translatable into the JSON input format are
as follows:
∙ Attack Vector: The context in which the vulnerability is exploitable.
The possible values are: Network, Adjacent – which translates
to the same subnetwork for the purposes of this work, Local
– which translates to the requirement of being able to execute
code or read or write files on the machine, and Physical – which
translates to attacker requiring physical access to the machine
∙ Privileges Required: None – attacker does not require a valid
account, Low – which translates to the attacker requiring a non-
administrative account, High – which translates to the require-
ment of possessing root/administrator privileges

16
 3. Specifications

∙ Scope: Unchanged or Changed, which translates to privilege

escalation and breaking out of a virtual machine

To allow the specification of complex prerequisite combinations,

the possibility to dynamically generate vulnerability-specific interac-
tion rules shall be implemented, to be provided to MulVAL’s reasoning
engine dynamically.

17
4 Implementation

4.1 Challenges
One of the ambitions of the MuPar Project is to add the ability to
describe network infrastructure and filtering rules generated by other
sources and translate them to ’hacl’ MulVAL predicates. This allows
for precise modeling of vulnerabilities’ consequences as networks
often have far more complex configurations than simply allowing
everyone from inside network to connect. However, modeling very
complicated network routing rules is hardly trivial. MuPar adopted a
middle-ground approach: Hosts may be declared members of mul-
tiple networks and the relationships between the networks may be
specified using the hacl predicates. One network may also have multi-
ple subnets. While this allows for a reasonable granularity and may
closely resemble most of the network configurations. Complex net-
work routing schemes and features such as layer 2 filtering cannot be,
however, accurately represented. For the purposes of vulnerabilities
with Adjacent Attack Vector, all hosts within the same subnet are con-
sidered adjacent, even though that may not be necessarily true with
managed switches and VLAN configurations.
Another requirement was to model host ’functions’ and ’roles’.
This allows declaring role-consequence relationships such as "if a
DNS server for a network is compromised, that network loses integrity
and confidentiality". Functions may also have multiple arity: A DNS
server role has one parameter (a network), but a computer routing
communication between two networks has two. Function specification
has been implemented in such a way that declaring new roles and
functions is possible with as few changes as possible.

4.2 Requirements
MuPar is implemented in Python [35] and requires at least Python
version 3.6 to run. From Python dependencies, Jinja2 [36] package for
rendering MulVAL input files (rules and the starting script) is the only
additional requirement – all the other dependencies are part of the
base Python distribution.

19
4. Implementation

For attack trace and attack graph generation, MuPar utilises Mul-
VAL’s reasoning engine and therefore requires XSB installed with its
binary on PATH. Mulval installation path has to be supplied in an
environmental variable.
Memory requirements of the analysis vary depending on the size
of the modelled network, the number of attack paths and the number
of predicates.

4.3 Hosts and clusters declaration format

MuPar accepts an arbitrary number of JSON input files – all data
may be provided in one global file, but the expected use case is for
different adapters to provide specific parts of the data. The type of
data is unambiguously specified by the key name of the parent JSON
object"
{
"hosts": HOSTS_LIST,
"clusters": CLUSTERS_LIST,
"vulnerabilities": VULNERABILITIES_LIST,
"vulnerability_presences": PRESENCES_LIST,
"network_accesses": ACCESSES_LIST
}
Following example demonstrates the format of host and cluster
declarations. Worth noting are network declarations of vmhost1.domain
and vmhost2.domain hosts. Instead of using IP address/subnet pair,
CIDR notation may be used. Specifying IP address is not manda-
tory. Host dnsserver.domain demonstrates a host with a function. The
function_name parameter identifies the correct class (inheriting from
Function), all the other parameters are mapped to the constructor of
the class:
{
"hosts": [
{
"host_id": "dnsserver.domain",
"networks": [
{
"ip": "10.0.0.1",
"subnet": "10.0.0.0/8"

20
 4. Implementation

}
],
"apps": [
{
"user": "dnsuser",
"app_id": "bind",
"protocol": "tcp",
"port": 53
}
],
"accesses": [
{
"src": "default",
"protocol": "tcp",
"port": 53
}
],
"functions": [
{
"function_name": "DnsServer",
"network": "default"
}
]
},
{
"host_id": "vmhost1.domain",
"networks": [
{
"ip": "10.0.0.2",
"subnet": "10.0.0.0/8"
},
{
"interface": "192.168.0.1/24",
"network_id": "hostonly1"
}
],
"apps": [
{
"user": "vmuser",
"app_id": "qemu"

21
4. Implementation

}
],
"accesses": [
{
"src": "hostonly1",
"protocol": "*",
"port": "*"
}
]
},
{
"host_id": "vmhost2.domain",
"networks": [
{
"ip": "10.0.0.3",
"subnet": "10.0.0.0/8"
},
{
"interface": "192.168.0.1/24",
"network_id": "hostonly2"
}
],
"apps": [
{
"user": "vmuser",
"app_id": "qemu"
}
],
"accesses": [
{
"src": "hostonly2",
"protocol": "*",
"port": "*"
}
]
},
{
"host_id": "vm1.virtualnet",
"is_virtual": true,
"vm_host": "vmhost1.domain",

22
 4. Implementation

"cluster_membership": "nginxcluster",
"networks": [
{
"ip": "10.0.0.4",
"subnet": "10.0.0.0/8"
},
{
"ip": "192.168.0.2",
"subnet": "192.168.0.0/24",
"network_id": "hostonly1"
}
],
"accesses": [
{
"src": "hostonly1",
"protocol": "*",
"port": "*"
},
{
"src": "default",
"protocol": "tcp",
"port": 80
},
{
"src": {
"type": "Host",
"id": "vmhost1.domain"
},
"protocol": "tcp",
"port": "vm_management_port"
}
]
},
{
"host_id": "vm2.virtualnet",
"is_virtual": true,
"vm_host": "vmhost2.domain",
"cluster_membership": "nginxcluster",
"networks": [
{

23
4. Implementation

"ip": "10.0.0.5",
"subnet": "10.0.0.0/8"
},
{
"ip": "192.168.0.2",
"subnet": "192.168.0.0/24",
"network_id": "hostonly2"
}
],
"accesses": [
{
"src": "hostonly2",
"protocol": "*",
"port": "*"
},
{
"src": "default",
"protocol": "tcp",
"port": 80
},
{
"src": {
"type": "Host",
"id": "vmhost2.domain"
},
"protocol": "tcp",
"port": "vm_management_port"
}
]
}
],
"clusters": [
{
"cluster_id": "nginxcluster",
"apps": [
{
"user": "nginxuser",
"app_id": "nginx",
"protocol": "tcp",
"port": 80

24
 4. Implementation

}
]
}
]
}

Complex vulnerabilities with multiple prerequisites and conse-

quences are specified using a list of JSON objects. Such objects cor-
respond to Predicate subclass which is selected based on the object’s
attribute. Other attributes are used as parameters when the corre-
sponding instances are created. Predicate subclasses have to implement
mulval_output() method, which outputs the corresponding MulVAL
predicate.

{
"vulnerabilities": [
{
"vulnerability_id": "CVE-bind-remote-code-execution",
"prerequisites": [
{
"name": "NetAccess"
},
{
"name": "RunningNetworkService",
"app": "bind"
}
],
"consequences": [{
"name": "ExecCode"
}]
}
],
"vulnerability_presences": [
{
"vulnerability": "CVE-bind-remote-code-execution",
"host": "dnsserver.domain"
}
]
}

25
4. Implementation

4.4 Parsing the input

Atom names generated by MuPar utilize Prolog’s quoted syntax. Every
entity that needs to be addressable as an atom is assigned MuId, an
unique identifier containing two parts separated by a space character:
the type (equal to the name of Python class representing it in MuParser)
and the ID part, constructed from ID elements provided in the JSON
input. This verbosity was implemented in order to address human
readability of MulVAL inputs, providing clear distinction between the
types of entities MulVAL atoms may represent. Following is a partial
result of the parser running on the JSON example from previous
section.
% Hosts description:
isHost(’Host dnsserver.domain’).
dnsServer(’Host dnsserver.domain’, ’Network default’, \
’App bind’).
inNetwork(’Host dnsserver.domain’, ’Network default’).
inSubnet(’Host dnsserver.domain’, \
’Subnet 10.0.0.0/8 in default’).
hasIp(’Host dnsserver.domain’, ’Ip 10.0.0.1 in default’).
hacl(’Network default’, ’Host dnsserver.domain’, \
’Protocol tcp’, ’Port 53’).
networkServiceInfo(’Host dnsserver.domain’, ’App bind’, \
’Protocol tcp’, ’Port 53’, ’User dnsuser’).
setuidProgramInfo(’Host dnsserver.domain’, ’App logrotate’, \
’User root’).

4.5 MuPar command line interface and graph

generation
While MulVAL provides a Bash script to provide a command line
interface for running attack traces and generating graphs, MuPar
provides its command line interface through mupar module’s main
method.
There are three actions MuPar may or may not run based on speci-
fied parameters:

∙ Parsing input JSON and generating MulVAL input files

26
 4. Implementation

∙ Running MulVAL analysis engine and generating an attack trace

∙ Converting the attack trace into graph in JSON format

4.6 Complexity
To validate the expectation that the attack path generation will scale
polynomially [19, 2, 20], a benchmark similar to [20] was conducted.
On Intel Core i7-3610QM locked at 2.3 GHz and 8 GiB RAM, running
Ubuntu 18.04 and with the XSB process constrained to a single CPU
core, the results for a test run with increasing number of hosts are as
follows:

Hosts Time
102 0.21 s
510 0.94 s
1003 6.41 s
2006 31.97 s
4998 219.74 s

27
5 Conclusion
Compared to base MulVAL distribution, following features have been
implemented as part of MuPar project:
∙ JSON-formatted input containing all the data about the mod-
elled network

∙ support for more accurate network connections representation

provided by implementing network interface parsing

∙ specification of clusters and virtual hosts

∙ declaration of host and cluster functions, with various arity

∙ a simple way of specifying vulnerabilities with a combination

of prerequisites and consequences

∙ translation of network filtering rules to MulVAL predicates

∙ attack graph in JSON format

∙ a simple multi-platform command-line interface

∙ JSON graph output

At this time, the detailed usage pattern of MuPar is uncertain: it has
to be yet decided how many adapters are to be implemented to provide
the data and from which sources. Without doubt, the vulnerability
specifications will be adapted from NVD (and possibly other vulner-
ability databases) and vulnerability scan results will be converted
from reports of vulnerability scanners such as Qualys [37], Nessus
or OpenVAS [38] – presumably in OVAL XML format – similarly to
the adapters supplied with MulVAL. However, the exact nature of the
other inputs is not completely determined at this moment: whether
input data such as network access rules are to be provided as a direct
result of parsing firewall rule dumps, or only a subset of data relevant
to the analyzed model will be supplied as an input remains to be seen.
Implementing a filter that removes protocol/port pairs that do not
appear in supplied vulnerability or application specifications would
be trivial to implement in MuPar, if required.

29
5. Conclusion

MuPar adds additional primitive and derived predicates and in-

teraction rules to the base MulVAL rule set, yet these additions are
far from extensive. To accurately model specific scenarios on modern
networks, MuPar’s base rule set will have to be broadened with addi-
tional functions declaring specific roles of hosts in the network and
the complementing predicates and interaction rules. However, MuPar
was designed with this exact extensibility in mind and such changes
should be simple to implement on an as-needed basis.

30
Bibliography
1. The MulVAL Project [online]. 2013 [visited on 2018-12-11]. Avail-
able from: http://people.cs.ksu.edu/~xou/mulval/.
2. OU, Xinming; BOYER, Wayne F; MCQUEEN, Miles A. A scalable
approach to attack graph generation. In: Proceedings of the 13th
ACM conference on Computer and communications security. 2006,
pp. 336–345. 556 cit.
3. CVSS v3.0 Specification Document [online]. 2018 [visited on
2018-12-06]. Available from: https://www.first.org/cvss/
specification-document.
4. PHILLIPS, Cynthia; SWILER, Laura Painton. A graph-based sys-
tem for network-vulnerability analysis. In: Proceedings of the 1998
workshop on New security paradigms. 1998, pp. 71–79. 778 cit.
5. SWILER, Laura P; PHILLIPS, Cynthia; ELLIS, David; CHAKE-
RIAN, Stefan. Computer-attack graph generation tool. In: discex.
2001, p. 1307. 425 cit.
6. LI, Zhi-tang; LEI, Jie; WANG, Li; LI, Dong. A data mining ap-
proach to generating network attack graph for intrusion predic-
tion. In: Fuzzy Systems and Knowledge Discovery, 2007. FSKD 2007.
Fourth International Conference on. 2007, vol. 4, pp. 307–311. 42 cit.
7. QIN, Xinzhou; LEE, Wenke. Attack plan recognition and pre-
diction using causal networks. In: Computer Security Applications
Conference, 2004. 20th Annual. 2004, pp. 370–379. 214 cit.
8. WANG, Lingyu; ISLAM, Tania; LONG, Tao; SINGHAL, Anoop;
JAJODIA, Sushil. An attack graph-based probabilistic security
metric. In: IFIP Annual Conference on Data and Applications Secu-
rity and Privacy. 2008, pp. 283–296. 305 cit.
9. MEHTA, Vaibhav; BARTZIS, Constantinos; ZHU, Haifeng;
CLARKE, Edmund; WING, Jeannette. Ranking attack graphs. In:
International Workshop on Recent Advances in Intrusion Detection.
2006, pp. 127–144. 222 cit.

31
BIBLIOGRAPHY

10. WANG, Lingyu; NOEL, Steven; JAJODIA, Sushil. Minimum-cost

network hardening using attack graphs. Computer Communica-
tions. 2006, vol. 29, no. 18, pp. 3812–3824. 267 cit.
11. WANG, Shuzhen; ZHANG, Zonghua; KADOBAYASHI, Youki.
Exploring attack graph for cost-benefit security hardening: A
probabilistic approach. Computers & security. 2013, vol. 32, pp.
158–169. 76 cit.
12. JAJODIA, Sushil; NOEL, Steven. Topological vulnerability anal-
ysis. In: Cyber situational awareness. Springer, 2010, pp. 139–154.
85 cit.
13. JAJODIA, Sushil; NOEL, Steven; KALAPA, Pramod; ALBANESE,
Massimiliano; WILLIAMS, John. Cauldron mission-centric cyber
situational awareness with defense in depth. In: Military Com-
munications Conference, 2011-MILCOM 2011. 2011, pp. 1339–1344.
91 cit.
14. INGOLS, Kyle; LIPPMANN, Richard; PIWOWARSKI, Keith. Prac-
tical attack graph generation for network defense. In: Computer
Security Applications Conference, 2006. ACSAC’06. 22nd Annual.
2006, pp. 121–130. 353 cit.
15. NOEL, Steven; JAJODIA, Sushil. Managing attack graph complex-
ity through visual hierarchical aggregation. In: Proceedings of the
2004 ACM workshop on Visualization and data mining for computer
security. 2004, pp. 109–118. 275 cit.
16. KAYNAR, Kerem. A taxonomy for attack graph generation and
usage in network security. Journal of Information Security and Ap-
plications. 2016, vol. 29, pp. 27–56. 18 cit.
17. AKSU, M. Ugur; BICAKCI, Kemal; DILEK, M. Hadi; OZBAYO-
GLU, A. Murat; TATLI, Emin Islam. Automated Generation of
Attack Graphs Using NVD. In: Automated Generation of Attack
Graphs Using NVD. 2018. 4 cit.
18. YI, Shengwei; PENG, Yong; XIONG, Qi; WANG, Ting; DAI,
Zhonghua; GAO, Haihui; XU, Junfeng; WANG, Jiteng; XU,
Lijuan. Overview on attack graph generation and visualization
technology. In: Anti-counterfeiting, security and identification
(asid), 2013 ieee international conference on. 2013, pp. 1–6. 22 cit.

32
 BIBLIOGRAPHY

19. OU, Xinming; GOVINDAVAJHALA, Sudhakar; APPEL, An-

drew W. MulVAL: A Logic-based Network Security Analyzer.
In: USENIX Security Symposium. 2005, vol. 8. 507 cit.
20. OU, Xinming; APPEL, Andrew W. A logic-programming approach
to network security analysis. Princeton University Princeton, 2005.
38 cit.
21. Scenario Graphs and Attack Graphs Project Webpage [online]. 2006
[visited on 2018-11-23]. Available from: http://www.cs.cmu.
edu/~odobzins/scenariograph/.
22. SHEYNER, Oleg; WING, Jeannette. Tools for generating and
analyzing attack graphs. In: International Symposium on Formal
Methods for Components and Objects. 2003, pp. 344–371. 245 cit.
23. SHEYNER, Oleg M. Scenario graphs and attack graphs. 2004.
Technical report. CARNEGIE-MELLON UNIV PITTSBURGH
PA SCHOOL OF COMPUTER SCIENCE. 264 cit.
24. JAJODIA, Sushil; NOEL, Steven; O’BERRY, Brian. Topological
analysis of network attack vulnerability. In: Managing Cyber
Threats. Springer, 2005, pp. 247–266. 477 cit.
25. Cauldron by Cyvision [online]. 2018 [visited on 2018-11-27]. Avail-
able from: http://www.benvenisti.net/cauldron/.
26. ARTZ, Michael Lyle. Netspa: A network security planning architec-
ture. 2002. Master’s thesis. Massachusetts Institute of Technology.
69 cit.
27. FireMon Risk Analyzer [online]. 2018 [visited on 2018-12-06].
Available from: https://www.firemon.com/products/risk-
analyzer/.
28. Skybox Security [online]. 2018 [visited on 2018-12-06]. Available
from: https://www.skyboxsecurity.com/.
29. Common Vulnerabilities and Exposures [online]. 2018 [visited on
2018-12-05]. Available from: https://cve.mitre.org/.
30. National Vulnerability Database [online]. 2018 [visited on 2018-12-
09]. Available from: https://nvd.nist.gov.
31. Open Vulnerability and Assessment Language [online]. 2018 [visited
on 2018-04-27]. Available from: https://oval.mitre.org.

33
BIBLIOGRAPHY

32. TENABLETM . Nessus Professional [online]. 2018 [visited on 2018-

10-27]. Available from: https://www.tenable.com/products/
nessus/nessus-professional.
33. FERRIE, Peter. Attacks on more virtual machine emulators.
Symantec Technology Exchange. 2007, vol. 55. 369 cit.
34. SMITH, Matthew; ENGEL, Michael; FRIESE, Thomas;
FREISLEBEN, Bernd; KOENIG, Gregory A; YURCIK, William.
Security issues in on-demand grid and cluster computing. In:
Sixth IEEE International Symposium on Cluster Computing and the
Grid (CCGRID’06). 2006, vol. 2, 14–pp. 31 cit.
35. Python [online]. 2018 [visited on 2018-05-27]. Available from:
https://www.python.org/.
36. Jinja2 Python Template Engine [online]. 2018 [visited on 2018-12-
17]. Available from: http://jinja.pocoo.org/.
37. Qualys Continuous Monitoring [online]. 2018 [visited on 2018-
12-13]. Available from: https : / / www . qualys . com / apps /
continuous-monitoring/.
38. OpenVAS [online]. 2018 [visited on 2018-10-27]. Available from:
http://www.openvas.org/.

34