A Formal Verification Approach to Handle Attack Graphs
Davide Catta
1
, Jean Leneutre
2
, Antonina Mijatovic
2
, Johanna Ulin
2
and Vadim Malvone
2
1
Universit`a degli Studi di Napoli Federico Secondo, Naples, Italy
2
T´el´ecom Paris, Palaiseau, France
Keywords:
Attack Graphs, Formal Verification, Multi-Agent Systems.
Abstract:
We propose a formalization of attack graphs through a multi-agent approach. Specifically, we focus on dy-
namic scenarios that capture the interaction between an attacker and defenders during a cyberattack. We
introduce a formal definition of an attack graph using interpreted systems, demonstrating how this formaliza-
tion enables us to express interesting security properties. Finally, we present a tool AG2IS, which we have
developed as an implementation of our formal definitions, to perform the formal verification of attack graphs.
1 INTRODUCTION
With the increasing use of computer networks and the
internet, cybersecurity has become a major concern.
Malevolent users constantly attempt to exploit vul-
nerabilities in computer systems to gain unauthorized
access to sensitive information, disrupt critical infras-
tructure, or commit other malicious activities. One of
the ways to analyze the security of computer networks
is by using Attack Graphs.
An Attack Graph is a graphical representation of
all possible ways a malevolent user can penetrate a
computer network by exploiting its vulnerabilities.
Attack Graphs are useful for identifying the weakest
links in a network and devising strategies to improve
its security. However, the size and complexity of At-
tack Graphs can make them challenging to analyze
and verify manually.
In recent years, researchers have been exploring
the use of formal methods to analyze Attack Graphs
automatically (Jha et al., 2002; Catta et al., 2023a;
Catta et al., 2023c). Formal methods are mathemati-
cal techniques used to verify the correctness of com-
puter systems. They can be used to model, specify,
and verify the behavior of a system. More in detail,
they can help detect and fix errors early in the design
process, before the system is implemented, thus re-
ducing the risk of costly errors and security breaches.
Most approaches to Attack Graph’s formal verifica-
tion are static and focus on verifying the existence of
critical paths in the graph. Few works address a dy-
namic scenario, that captures the interactions between
a defender and an attacker during an ongoing attack.
In this paper, we demonstrate that multi-agent sys-
tems can offer a more dynamic approach to address
the formal verification of Attack Graphs. We be-
gin by showing how Attack Graphs can be modeled
by means of interpreted systems. In particular, we
will consider interpreted systems with two kinds of
agents: attacker agents and defender agents. An at-
tacker agent represents a malevolent user who is try-
ing to penetrate the network by exploiting its vulnera-
bilities, while a defender agent represents the secu-
rity measures and policies that are in place to pro-
tect the network. The goal of the defender agent is
to prevent the attacker agent from achieving its objec-
tives, while the attacker agent tries to bypass the se-
curity measures and successfully carry out its attack.
We then present an implementation of our theoreti-
cal definitions. More precisely, we build a converter
called AG2IS between the Attack Graph generated by
the Multihost, Multistage Vulnerability Analysis Lan-
guage (MulVAL) (Ou et al., 2005) tool to an inter-
preted system following the Interpreted Systems Pro-
gramming Language (ISPL) format (Lomuscio and
Raimondi, 2006). In addition to specify the attacker’s
goal, the tool AG2IS provides a formula for verifying
the possibility of a successful attack by the attacker in
the interpreted system. The formal verification part is
done via the Model Checking of Multi-Agent Systems
(MCMAS) tool (Lomuscio and Raimondi, 2006).
Related Work. Several existing works have pro-
posed different game-theoretic solutions for finding
an optimal defense policy based on Attack Graphs.
Most of these approaches do not use formal verifi-
cation to analyze the game, but rather try to solve
them using analytic and optimization techniques. The
goal is to find the Nash equilibrium in order to char-
acterize the most promising attacker/defender’s ac-
Catta, D., Leneutre, J., Mijatovic, A., Ulin, J. and Malvone, V.
A Formal Verification Approach to Handle Attack Graphs.
DOI: 10.5220/0012310000003636
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 16th International Conference on Agents and Artificial Intelligence (ICAART 2024) - Volume 3, pages 125-132
ISBN: 978-989-758-680-4; ISSN: 2184-433X
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.
125

tions. The works in (Durkota et al., 2015a; Durkota
et al., 2015b) study the problem of hardening the se-
curity of a network by deploying honeypots to the
network to deceive the attacker. They model the
problem as a Stackelberg security game in which the
attack scenario is represented using Attack Graphs.
The authors in (Nguyen et al., 2017) tackle the prob-
lem of allocating limited security countermeasures to
harden security based on attack scenarios modeled
by Bayesian Attack Graphs using partially observable
stochastic games. A few works adopt a formal ap-
proach to analyze games defined on Attack Graphs.
The work in (Bursztein and Goubault-Larrecq, 2007)
shares some ideas with our approach. However, they
use a timed-logic framework and timed games to ex-
press and evaluate network security properties, which
result in an EXPTIME-complete procedure. Finally,
the works in (Catta et al., 2023a; Catta et al., 2023c;
Catta et al., 2023b) share some ideas with ours on
the cybersecurity side. However, the authors con-
sider turn-based models and do not consider coali-
tions of defenders as we do. Finally, on the im-
plementation side, the PRISM model-checker https:
//www.prismmodelchecker.org/ have been used sev-
eral times to model attack- defence scenarios.
See, for example: https://www.prismmodelchecker.
org/casestudies/index.php#security and https://www.
prismmodelchecker.org/games/casestudies.php.
2 PRELIMINARIES
If X is a set, then X denotes its complement. We de-
note by X
+
the set of finite sequences of elements of
X and by X
ω
the set of infinite (countable) sequences
of elements of X. If ρ ∈ X
+
∪ X
ω
then |ρ| denote its
length, which is ω if ρ is infinite. If i ≤ |ρ| then ρ
i
de-
notes the i-th element of ρ, ρ
≤i
denotes the finite prefix
ρ
1
, . . . , ρ
i
of ρ and ρ
≥i
denotes the suffix of ρ starting
at ρ
i
. Finally, if ρ is finite last(ρ) denotes its last el-
ement ρ
|ρ|
. If l = ⟨x
1
, . . . , x
n
⟩ is a tuple, we denote by
l[i] the i-th component x
i
of the tuple.
Definition 1. Given a non-empty set Ap of atomic
propositions and a non-empty set Σ of labels, a Kripke
Structure based on Ap and Σ is a tuple M = ⟨W,R,L⟩
where W is a non-empty set of worlds (or states),
R ⊆ W × Σ × W is a ternary relation (the transition
relation), and L is the labeling function sending
any world to (an eventually empty) subset of atomic
propositions.
Given a subset ∆ of Σ, we write R
∆
for the restric-
tion of R to elements of ∆, that is R
∆
= {⟨w,a,w
′
⟩ ∈
R | a ∈ ∆}. In the rest of the paper, we will sup-
pose that given a Kripke structure M, it holds that
Ap =
S
w∈W
L(w). A rooted Kripke structure is a pair
formed by a Kripke structure M and a subset W
I
of the
set of worlds of M. Elements of W
I
are called initial
worlds. We now recall the definition of interpreted
systems (Fagin et al., 1995). First, we define agents.
Definition 2 (Agent). Given a finite set of agent index
A = {1, . . . , k}, an agent is a tuple i = ⟨L
i
, act
i
, P
i
, t
i
⟩,
where: L
i
is the finite non-empty set of local states;
act
i
is the finite non-empty set of individual actions.
We denote by ACT the product set Π
i∈A
act
i
and we
call its element joint actions. P
i
: L
i
→ (2
act
i
\ ∅) is the
local protocol function. t
i
: L
i
× ACT → L
i
is the lo-
cal transition function. Such function takes an agent’s
state l and a joint action a = ⟨a
1
, . . . a
k
⟩ and outputs
an agent’s state. The function t
i
(l
i
, a) is defined if and
only if we have that a[i] ∈ P
i
(l
i
).
By the above definition, an agent i is situated in
a local state l ∈ L
i
representing the information it has
about the system. At any state, the agent can perform
the actions in act
i
according to the protocol function
P
i
. A joint action determines a change in the state of
the agent according to the transition function t
i
.
If A is a set of agents of length k, a global state
s ∈ G is a tuple s = ⟨l
1
, . . . , l
k
⟩ where each l
i
is an i
agent’s state for i ≤ k. A history is a finite sequence
h = s
1
, . . . , s
n
of global states. We denote by H the set
of histories. Two global states s and s
′
, are equivalent
for the agent i whenever s[i] = s
′
[i]. We denote such
notion by s ∼
i
s
′
. Two histories h and h
′
are equivalent
for the agent i whenever they have the same length m
and h
j
∼
i
h
′
j
for any j ≤ m.
Definition 3. An interpreted system is a tuple I =
⟨A,G
I
, T,Π⟩ where A is a set of agents, G
I
⊆ G is
the set of global initial states. T : G × ACT → G is
the global transition function such that T(s, a) = s
′
iff
for every i ∈ A, t
i
(s[i], a[i]) = s
′
[i]. Π : G → 2
Ap
is the
labelling function.
A path ρ is an infinite sequence of global states,
ρ = s
1
, s
2
, s
3
, . . . respecting the following constraint:
for every i ≥ 1, there is a joint action a such that
T (s
i
, a) = s
i+1
. We denote paths by ρ,τ, and π.
Definition 4. A uniform strategy (strategy for short)
for an agent i is a function σ
i
: H → act
i
such that:
1. for every h ∈ H we have that σ
i
(h) ∈ P
i
(last(h)).
2. For every pair of histories h and h
′
, h ∼
i
h
′
implies
σ
i
(h) = σ
i
(h
′
).
A strategy is memoryless when for every pair of
histories h and h
′
we have that last(h) = last(h
′
) im-
plies σ(h) = σ(h
′
).
Given a coalition Γ, a uniform strategy for Γ, or
simply Γ-strategy, is a collection σ
Γ
of uniform strate-
gies comprising one strategy σ
i
for each i ∈ Γ. Given
ICAART 2024 - 16th International Conference on Agents and Artificial Intelligence
126

a path ρ, we say that ρ is σ
Γ
-compatible iff for ev-
ery j ≥ 1, ρ
j+1
= T (ρ
j
, a) for some joint action a such
that for every i ∈ Γ, a[i] = σ
i
(ρ
≤ j
), and for every k ∈ Γ,
a[k] ∈ P
k
(ρ
j
). We denote with Out(s, σ
Γ
) the set of all
σ
Γ
-compatible paths whose first state is s.
We now introduce Alternating-time Temporal
Logic (Alur et al., 1997) (ATL, for short) to reason
about strategic abilities of the agents. Formulas of
ATL are defined by the grammar:
φ := ⊤ | p | ¬φ | φ ∧ φ | ⟨Γ⟩X φ | ⟨Γ⟩(φ Uφ) | ⟨Γ⟩(φ R φ)
where p ∈ Ap and Γ ⊆ A. The boolen connective can
be defined as usual as well as the temporal connec-
tives G (globally), F (eventually) and (weak-until) W.
Definition 5. Given an interpreted system I, a global
state s of I, and an ATL formula φ, the satisfaction re-
lation I, s |= φ is defined by induction on the structure
of φ as follows:
• I, s |= ⟨Γ⟩X ψ iff there is a Γ-strategy σ
Γ
such that
for every π ∈ Out(s, σ
Γ
) we have that I, π
2
|= ψ;
• I, s |= ⟨Γ⟩ψ Uθ iff there is a Γ-strategy σ
Γ
such that
for every π ∈ Out(s, σ
Γ
) there is a j ≥ 1 such that
I, τ
j
|= θ and I, τ
i
|= ψ for each 1 ≤ i < j;
• I, s |= ⟨Γ⟩ψ Rθ iff there is a Γ-strategy σ
Γ
such that
for every π ∈ Out(s, σ
Γ
) either I, τ
i
|= θ for all i ≥ 1
or there is a j ≥ 1 such that I,τ
j
|= ψ and I, τ
i
|= θ
for each 1 ≤ i ≤ j.
where the satisfaction clauses for atoms and boolean
connective are standard and thus omitted.
3 FORMAL MODELS
Now that we have laid out the preliminaries for our
work, we can gather together the elements exposed so
far and present our formalization of Attack Graphs.
3.1 Attack Graphs as Kripke Structures
The term attack graph was first introduced by Phillips
and Swiler (Phillips and Swiler, 1998). The general
idea is to represent the possible attack paths in a sys-
tem by means of a directed labeled graph. This graph
is generated based on a description of the system’s ar-
chitecture (including topology and component config-
urations), along with a list of existing vulnerabilities,
the attacker’s profile (including capabilities, knowl-
edge of passwords, and privileges), and attack tem-
plates (which encompass the attacker’s atomic ac-
tions, including preconditions and postconditions).
Each attack path within the graph represents a se-
quence of atomic attacks. Numerous studies have
adopted this approach, e.g., (Sheyner et al., 2002;
Ammann et al., 2002; Noel et al., 2003; Ou et al.,
2006; Ingols et al., 2006), and (Kaynar, 2016) for
a survey. Despite the existence of various, and quite
different, formalizations of the Attack Graph notion,
most authors agree that a formalization of this concept
should adhere to the following two conditions: an At-
tack Graph is said to be complete whenever for every
state q and for every atomic attack att, if the precon-
ditions of the atomic attack hold in q, then there is an
out-coming edge from q labeled with att. An attack
graph is said to be monotone whenever for every state
q and q
′
, if there is an atomic attack that leads from q
to q
′
then the conditions true at q are also true at q
′
.
As we have said, Attack Graphs are generated
from a series of heterogeneous pieces of information.
The primary one among them is provided by the con-
ditions that must be satisfied in a given situation for an
attacker to launch an attack and the effects that such
an attack generates. Such type of information can
be expressed through atomic propositions that serve
as labels for the nodes of the graph. Consequently,
the required information about the preconditions and
postconditions of an attack can be expressed with the
aid of a ternary relation. In each tuple ⟨X,a,Y⟩ of this
relation, X is a set of atomic propositions represent-
ing the necessary conditions for launching the attack,
a is the action undertaken by the attacker (the attack
itself), and Y is the set of postconditions generated
by the attack a starting from X. We call this type of
relation an “attack relation”. It will serve as the foun-
dation for our definition of an Attack Graph.
Definition 6 (Attack Graph). Suppose that win ∈ Ap,
let Σ be a finite alphabet and Att ⊆ 2
Ap
× Σ × (2
Ap
\ ∅)
be a ternary relation dubbed Attack Relation. An
Attack Graph is a tuple AG = ⟨M, W
I
, Att⟩ where
⟨M, W
I
⟩ is a rooted Kripke structure based on Ap and
Σ such that:
1. There is a non-empty subset T of W such that
win ∈ L(w) for all w ∈ T.
2. ⟨w, a, w
′
⟩ ∈ R if and only if w , w
′
, w < T and there
is a tuple ⟨X, a, Y⟩ ∈ Att such that X ⊆ L(w) and
L(w
′
) = L(w) ∪ Y.
3. The relation R is functional (or deterministic): for
every a ∈ Σ and w ∈ W there is at most one w
′
∈ W
such that ⟨w,a,w
′
⟩ ∈ R.
As the reader can see, our definition implies that
the structure of an Attack Graph is determined by the
given attack relation. For instance, suppose that the
relation Att is specified accordingly to Table 1. An
Attack Graph based on this attack relation is showed
in Figure 1.
As an immediate consequence of condition 2 in
the definition of Attack Graph, we get the follow-
A Formal Verification Approach to Handle Attack Graphs
127

webserver : root
server : root
webserver : root
server : root
databaseA : root
webserver : root
password : 1234
server : root
databaseA : root
w
2
w
4
w
7
w
1
webserver : root
w
3
w
5
w
6
webserver : root
password : 1234
webserver : root
password : 1234
server : root
webserver : root
password : 1234
server : root
databaseB : root
att
1
att
2
att
3
att
1
att
4
att
2
att
3
webserver : root
server : root
webserver : root
server : root
databaseA : root
webserver : root
password : 1234
server : root
databaseA : root
w
2
w
4
w
7
webserver : root
w
1
w
3
w
5
w
6
webserver : root
password : 1234
webserver : root
password : 1234
server : root
webserver : root
password : 1234
server : root
databaseB : root
att
1
att
3
att
1
att
4
att
3
att
2
de f
1
att
2
de f
1
Figure 1: Attack Graph (left) and of Attack-Defense Graph (right). Red nodes are those in which win is true.
Table 1: Table specifying the relation Att.
Precondition Label Postcondition
webserver:root att
1
server:root
webserver:root att
2
password:1234
server:root att
3
databaseA:root, win
server:root, password:1234 att
4
databaseB:root, win
ing, in which we express that our definition of an At-
tack Graph implies the properties of monotonicity and
completeness.
Proposition 1. If AG = ⟨M, W
I
, Att⟩ is an Attack
Graph, then the following holds; AG is monotonous:
if ⟨w,a,w
′
⟩ ∈ R then L(w) ⊂ L(w
′
). AG is complete: if
⟨X, a, Y⟩ ∈ Att and there is a world w of AG such that
X ⊆ L(w), then there is a world w
′
of AG such that
⟨w, a, w
′
⟩ ∈ R and Y ⊆ L(w
′
).
3.2 The Countermeasure Relation
In the last subsection, we defined an Attack Graph as
a special kind of Kripke structure in which the tran-
sition relation is determined by an Attack Relation
and in which some other conditions are satisfied. The
Attack Relation represents the possible attacks over
the system, where an attack is identified with a set
of preconditions and postconditions. Our goal is to
model dynamic interaction scenarios between an at-
tacker and defenders using an Attack Graph to repre-
sent the attack scenario. To achieve this, we will sub-
sequently define interpreted system agents (attacker
and defenders) and use ATL to specify their objec-
tives. As an intermediate step towards defining these
agents, we introduce the notion of an Attack-Defense
graph. This graph has two types of edges: edges rep-
resenting the attack relation and edges representing
the defense relation. In this context, a defense is un-
derstood as follows: a defense consists of nullifying
the effects of an attack, thereby restoring the system
state and privileges obtained by the attacker to a state
prior to the attack itself.
Let Ap be a set of atomic propositions, Σ a set
of labels, and M a Kripke structure based on Ap and
Σ, if ∆ ⊆ Σ, the ∆-restriction M
∆
of M is the tuple
⟨W
∆
, R
∆
, Σ
∆
⟩ where W
∆
= {w ∈ W | ∃w
′
∈ W ∧∃a ∈ ∆ ∧
(⟨w, a, w
′
⟩ ∈ R
∆
∨ ⟨w
′
, a, w⟩ ∈ R
∆
)} and L
∆
(w) = L(w)
for every w ∈ W
∆
. We remark that M
∆
is a Kripke
structure whenever R
∆
is not-empty.
Definition 7. Given Ap, Σ, an Attack Relation
Att based on a subset ∆ of Σ, and an indexed
family {X
b
}
b∈∆
of pairwise disjoints subsets of
2
Ap
, an Attack-Defense Graph is a tuple ADG =
⟨M, W
I
, Att, {C
b
}
b∈∆
⟩ where:
1. ⟨M
∆
, W
I
, Att⟩ is an Attack Graph;
2. for every b ∈ ∆, C
b
⊆ W × {b} × W is a ternary re-
lation such that ⟨w, b, w
′
⟩ ∈ C
b
if and only X
b
⊆
L(w), L(w
′
) = L(w) \ X
b
and w, w
′
< T;
3. the relation C =
S
b∈∆
C
b
is functional: if
⟨w, b, w
′
⟩ ∈ C and ⟨w, b
′
, w
′′
⟩ ∈ C then b = b
′
and
w
′
= w
′′
.
In the above definition, the set of labels Σ is par-
titioned into two disjoint subsets, ∆ and its comple-
ment; ∆ represents the set of actions (attacks) of the
attacker, while each element of b of ∆ represents a
countermeasure for a defender. To each countermea-
sure b is associated a subset of atomic propositions
X
b
. This subset represents the effect of an attack that
a defender can nullify by using the given countermea-
sure b. To make things more concrete, let us give an
example. Suppose that Σ = {att
1
, att
2
, att
3
, att
4
, de f
1
}
that ∆ = Σ\{de f
1
} and that X
de f
1
= {password : 1234}.
Suppose that Att is specified as in Table 1. An Attack-
Defense graph is shown in Figure 1 (right).
3.3 Attack Graphs as Interpreted
Systems
We can now finally define agents corresponding to the
attacker and the various defenders of a system. In
the following, we consider an Attack-Defense graph
ADG = ⟨M, W
I
, Att, {C
b
}
b∈∆
⟩ based over an indexed
family {X
b
}
b∈∆
of pairwise disjoints subsets of 2
Ap
,
and whose set of agents is Ag = {att, d
b
1
, . . . , d
b
n
}
where the b
i
s are all only the elements ∆. We de-
note by ACT the set of tuples of length n + 1 where,
in each tuple a, the first member a[1] is either ⋆ (the
idle action) or an element of ∆ and for each 1 < i ≤ |a|,
the i-th component a[i] is either ⋆ or b
i
.
ICAART 2024 - 16th International Conference on Agents and Artificial Intelligence
128

Definition 8 (Attacker agent). Given Ag as above,
the attacker att is the agent ⟨L
att
, act
att
, P
att
, t
att
⟩ such
that:
• the set of local state of the agent is equal to set of
worlds W of the given ADG;
• the set of actions act
att
of the agent is equal to
∆ ∪ {⋆};
• the protocol function P
att
assigns to each local
state l the idle action ⋆ and each member a of
∆ such that ⟨l,a, l
′
⟩ ∈ R, where R is the transition
relation of the Attack Graph;
• given a local state l an element a of ACT such
that a ∈ P
att
(l) the transition function is defined as
follows:
t
att
(l, a) =















l
′
if a[1] = a,a[i] = ⋆ for all i ≥ 2 and ⟨l, a, l
′
⟩ ∈ R
l
′′
if there is i ≥ 2 such that a[ j] = b and ⟨l, b, l
′′
⟩ ∈ C
b
l otherwise
Definition 9 (Defender agent). For i ≥ 2, the i-
Defender agent d
b
i
is the agent ⟨L
d
b
i
, act
d
b
i
, P
d
b
i
, t
d
b
i
⟩
such that:
• the set of local states of the i-Defender is the set
of equivalences classes of worlds of the AGD gen-
erated by the following relation: w ∼
d
i
w
′
if and
only if L(w) ∩ X
b
i
= L(w
′
) ∩ X
b
i
. Remark that this
implies that each defender has exactly two local
states: a state l such that L(w) ∩ X
b
i
= ∅ for all
w ∈ L and a state l
′
such that L(w
′
) ∩ X
b
i
= X
b
i
for all w
′
∈ l
′
. We refer to the former as the empty
state and to the latter as the full state;
• the set of actions of the i-Defender is equal to
{⋆, b
i
};
• the protocol function assigns ⋆ to the empty state
and {⋆, b
i
} to the full state;
• Given a state l and a tuple of actions a ∈ ACT such
that a[i] ∈ P
d
i
(l), the transition function is defined
as follows:
t
d
i
(l, a) =





















l
′
if a[i] = b
i
and
⟨w, b
i
, w
′
⟩ ∈ C
b
i
for some w ∈ l,w
′
∈ l
′
l
′
if a[1] = a ∈ ∆, a[i] = ⋆ for all i ≥ 2 and
⟨w, a,w
′
⟩ ∈ R for some w ∈ l and w
′
∈ l
′
l otherwise
(1)
Finally, an Attack-Defense Interpreted System
ADI is an interpreted system in which the set of play-
ers is composed of an attacker and n ≥ 1 defenders
generated from the same Attack-Defense graph ADG,
and the labeling function is equal to Π(s) = L(s[1])
1
1
We remark that every first component of a global state
s is a world of the ADG. Thus, L(s[1]) is well defined.
for every global state s. We will also say that the In-
terpreted System is based on the ADG.
Why Interpreted System Matters. As we have
argued in the introduction, the risk analysis through
Attack Graph is usually based on detecting critical
paths within the system. In other words, paths that
lead from one of the initial states of the graph to a tar-
get state. This type of analysis is easily simulated in
our framework. Such a reachability goal can be ex-
pressed by the ATL formula ⟨att⟩F win in an Attack-
Defense interpreted system, generated from an attack-
defense graph in which the countermeasure relation is
the empty relation ∅. In our framework, however, we
can specify much more complex objectives. For ex-
ample, suppose Γ is a coalition formed by a group
of defenders; we might be interested in knowing if
the following specifications are satisfied in a dynamic
attack-defense context:
O
1
the attacker is never able to obtain root privilege
on server s unless the defenders are able to obtain
information on its identity;
O
2
while the defenders have not obtained information
about the attacker identity, the attacker does not
have root privilege on server s.
Let a be an atomic proposition that expresses the
fact that the identity of the attacker is known. Let r
s
be an atomic proposition expressing the fact that the
attacker has root privilege on server s. The two se-
curity objectives O
1
and O
2
presented above can be
expressed by ATL formulae. Objective O
1
says that
either we want the attacker to never reach a state sat-
isfying r
s
or if the attacker reaches such a state, then
the defender wants to be able to identify it (a). We
can express O
1
as φ
1
:= ⟨Γ⟩G(¬r
s
∨ (r
s
→ ⟨Γ⟩(Fa))).
Objective O
2
says that we want r
s
to be false until we
have identified the attacker (a) if such identification
ever occurs. Thus, we can write O
2
using the weak-
until connective as: φ
2
:= ⟨Γ⟩(¬r
s
Wa).
4 IMPLEMENTATION
In this section, we present a tool called AG2IS
2
that
represents the practical development of the previous
definitions and concepts. We first provide a high-level
description of the two tools AG2IS uses.
MulVal. MulVal is a tool with two objectives: to gen-
erate an Attack Graph that allows the automated inte-
gration of formal vulnerability specifications, and to
2
You can find the sources at the following link (Impor-
tant: pay attention to the underscore in “view only”,
sometimes copy and paste does not include it):
https://osf.io/5x6j2/?view only=127a477518fc48e2bd5af9b89f937b37.
A Formal Verification Approach to Handle Attack Graphs
129

generate an Attack Graph that has the ability to model
very large networks. To obtain these objectives, the
creators of MulVal have chosen to use logic program-
ming to model the elements of the analysis and Attack
Graph generation. In this work, we do not discuss the
theory behind the Attack Graph generation, as we use
MulVal as a black-box tool. However, we will discuss
the format of the network specification which MulVal
employs to generate Attack Graphs and the format of
the generated Attack Graph.
3
MCMAS. MCMAS is a Model Checker for Multi-
Agent Systems. The tool takes an interpreted sys-
tem and verification formulae as input and employs
Ordered Binary Decision Diagrams (Bryant, 1986) to
return the truth value of the formulae. MCMAS allows
definition of formulae in Alternating-time Temporal
Logic (ATL). Therefore, MCMAS is able to handle both
temporal and strategic properties. Here, we will em-
ploy ATL to verify the existence of attack paths.
4.1 Our Tool AG2IS
The goal of AG2IS is to construct an interpreted sys-
tem in the Interpreted Systems Programming Lan-
guage (ISPL) format from a generated Attack Graph
by MulVAL. The multi-agent systems that can be han-
dled by MCMAS are described as interpreted systems
in the ISPL. This language allows the definition of
agents in terms of variables and evolution by using
Boolean expressions. In particular, in ISPL we con-
sider that there will be three different types of agents:
the attacker, the defender
4
, and the environment. This
latter represents the interpreted system itself.
AG2IS takes three files as input: one file contain-
ing the Attack Graph generated by MulVal on the ba-
sis of a given attack relation. A second file that spec-
ifies what are the initial nodes and target nodes of the
aforementioned Attack Graph; initial nodes will often
be referred to as initial assumptions in the following.
A third file containing the countermeasures for the de-
fender which corresponds to the countermeasure rela-
tion introduced in the previous section.
Our tool then outputs one ISPL file containing the
full interpreted system as well as the formula which
needs to be verified by the model checker MCMAS.
The underlying algorithm of AG2IS works in three
stages; first it constructs the necessary data structures
from the input files, then it writes the interpreted sys-
tem, and it finishes with constructing the evaluation
3
Note that MulVal generates hypergraphs. However,
this is resolved because it is manageable to generate a graph
from a hypergraph (Bartolomeo et al., 2022).
4
Note that, in the current implementation we only con-
sider one defender.
and formula for verification. In what follows, we give
a high-level exposition of each of these three stages.
In the first phase, we construct the data structure we
use to define the attacker’s local model and the de-
fender’s local model. The attacker’s local model is
based upon the information contained in the MulVal-
generated Attack Graph and the corresponding input
of MulVal. The defender’s local model is based on
the information in the file containing the countermea-
sures for the defender, and relate them to nodes in the
MulVal generated Attack Graph.
In the second phase, we specify the interpreted
system based on the data structures obtained in the
preceding phase. First, we construct the Environment
Agent. Then we build the local model for the attacker
using the data structures defined for the attacker. Then
we construct the local model for the defender using
the defender’s data structure.
Finally, we construct the Evaluation of the inter-
preted system, which depends on the attacker’s tar-
get, which is defined in the initial assumptions and its
corresponding nodes in the MulVal generated Attack
Graph. Lastly, we construct the formula that needs to
be verified over the interpreted system, which is fully
independent of the input files and therefore constant
for any Attack Graph.
Example 1. We give an example of input for AG2IS
consisting of: (1) an attack (hyper)graph generated
by MulVal; (2) a simplified
5
example of input file that
specifies the initial node of the Attack Graph and the
attacker’s target state; (3) an example of a file corre-
sponding to the specification of the defender’s coun-
termeasures.
MulVal Hypergraph. In Figure 2 (left) we display
a hypergraph corresponding to a MulVal-generated
Attack Graph. On the right part , we display an At-
tack Graph generated from the one above that re-
spects our definition of Attack Graph In the hyper-
graph, NODE 1 and NODE 3 correspond to the ini-
tial assumptions of the system, NODE 2 is a rule that
the attacker can activate and NODE 4 is the postcon-
dition of activating NODE 2. In the corresponding
graph NODE A corresponds to the state containing
both preconditions NODE 1 and NODE 2. NODE B
contains both the postcondition NODE 4 and the pre-
conditions of the transition. EDGE 1 describes the
transition from NODE A to the node containing the
postcondition NODE B.
Initial nodes and target node. The initial nodes (or
initial assumption) of the Attack Graph described in
the preceding paragraph are NODE 1 and NODE 3
while the attacker’s target state is NODE 4. This kind
5
This file is not in the datalog format of a MulVal input
file.
ICAART 2024 - 16th International Conference on Agents and Artificial Intelligence
130

Figure 2: MulVal-generated Attack Graph (left) and corre-
sponding Attack Graph respecting our definition (right).
of information can be easily specified in MulVal as
follows: attackGoal(node4), node1, node3.
Countermeasures. In our implementation, we have
made the following choice: the defender can ap-
ply countermeasures by considering the actual state
of the Attack Graph. Specifying the availabil-
ity of a countermeasure for the defender is quite
straightforward. Indeed, the file that specifies the
countermeasure is composed of datalog commands
with the following syntax: Countermeasure = Bool :
preCondition(. . .). The interpretation of this com-
mand is straightforward. If the Boolean variable
Bool is True, then the defender has a countermea-
sure against the vulnerability described with the pred-
icate preCondition(...). If the Boolean variable Bool
is False, then the defender does not have a counter-
measure against the related condition. The format
allows the user to not input conditions for any pre-
condition of the transitions of the Attack Graph cor-
responding to the system. In fact, if an assumption is
not contained in the countermeasure input, it is con-
sidered to be assigned with the Boolean variable Bool
as False.
ISPL Generation. After having constructed the nec-
essary data structures, the algorithm begins construct-
ing the interpreted system, in an ISPL format. It con-
structs three agents, an attacker, a defender, and an
environment agent as well as the initial states for the
system, as presented by the specification of MCMAS in
the dedicated paragraph. The implementation has the
following structure: the environment agent contains
all the variables, i.e. all preconditions and postcon-
ditions, of the Attack Graph representing the mod-
eled system, as well as the the evolution of these
variables. The attacker and defender agents contains
solely their own actions and the protocol of these ac-
tions, i.e. when these actions can be activated. Once
we have obtained an interpreted system, we need to
determine the evaluation and formula to be verified
for our model. The evaluation corresponds with the
atomic propositions of the system, which we define
with win. Simply, this propositions is verified if the
attacker can reach any of its objectives. Then, we de-
fine the formula to be verified by MCMAS. The formula
is constructed in ATL as follows: ⟨g
1
⟩Fwin, where
Figure 3: The user interface.
g
1
corresponds to the group which only contains the
attacker. The formula reads as “the attacker has a
strategy to reach in the future one of his objectives”.
User Interface (UI). Our tool AG2IS is provided with
a user interface. In Figure 3, we can observe a sam-
ple view of the interface, which has been designed
for a user-friendly interaction. Upon launching the
interface, users are greeted with a message at the
top, instructing them to upload the required files in a
specific format: Attack Graph, countermeasures, and
game model (containing the specification of the initial
nodes and target states) using an “Open File” button.
As each file is uploaded, the user receives confirma-
tion through messages displayed on the screen. Once
all three files are uploaded, the user is informed that
they can proceed by clicking the “Execute” button in
the upper right corner, which will generate the truth
value for the attacker’s objective written in ATL.
Behind the scenes, the UI utilizes the MCMAS tool
with the provided command, displaying only the rel-
evant output to the user. Additionally, users are in-
formed that if they wish to modify the specifications,
they can click the “Exit” button to restart the process.
5 CONCLUSION AND FUTURE
WORKS
In this paper, we present a formal technique for trans-
forming an Attack Graph, along with countermea-
sures, into a game between an attacker and a coali-
tion of defenders using interpreted systems. We have
proven the correctness of this transformation and sub-
sequently developed a tool called AG2IS that estab-
lishes a connection between the output of an Attack
Graph generator (namely, MulVal) and the input of
a model checker for multi-agent systems (namely,
MCMAS). The ultimate goal of this entire framework is
to determine whether an attacker possesses a strategy
to gain access to certain private resources, regardless
A Formal Verification Approach to Handle Attack Graphs
131

of the countermeasures employed by the defenders.
As future work, we aim to explore various direc-
tions from both theoretical and practical perspectives.
On the theoretical side, we intend to investigate sce-
narios where the game structure involves multiple at-
tackers. This presents a challenging objective due to
our current approach of transforming Attack Graphs
into interpreted systems. To address multiple attack-
ers, we must consider transforming multiple Attack
Graphs into interpreted systems. Currently, merging
several Attack Graphs has not yet been studied. Ini-
tially, we will delve into the amalgamation of multi-
ple Attack Graphs and subsequently devise a formal
framework for generating an interpreted system. On
the practical side, there is much to accomplish. Pri-
marily, we need to enhance our tool to handle multi-
ple defenders. Additionally, we must expand the ca-
pabilities of AG2IS on the specification side. Our cur-
rent implementation only defines a reachability objec-
tive for the attacker. Nonetheless, as demonstrated in
our work, incorporating more intricate temporal ob-
jectives can enhance the verification process. More-
over, our approach in this study involved utilizing two
existing tools for Attack Graph generation and verifi-
cation. However, since MulVal is an outdated tool
without active maintenance, we are considering de-
veloping a new Attack Graph generator. Furthermore,
MCMAS lacks certain extensions in terms of logics for
strategic reasoning. Thus, we have plans to extend it
with more robust logics that are particularly relevant
within the realm of cybersecurity.
ACKNOWLEDGEMENT
The first author is supported by the PRIN project
RIPER (No. 20203FFYLK).
REFERENCES
Alur, R., Henzinger, T. A., and Kupferman, O. (1997).
Alternating-time temporal logic. In FOCS97, pages
100–109.
Ammann, P., Wijesekera, D., and Kaushik, S. (2002).
Scalable, graph-based network vulnerability analysis.
CCS ’02, page 217–224. Association for Computing
Machinery.
Bartolomeo, S. D., Pister, A., Buono, P., Dunne, C., and
Fekete, J.-D. (2022). Six methods for transforming
layered hypergraphs to apply layered graph layout al-
gorithms. EuroVis 2022, 41(3).
Bryant, R. E. (1986). Graph-based algorithms for boolean
function manipulation. IEEE Trans. Computers,
35(8):677–691.
Bursztein, E. and Goubault-Larrecq, J. (2007). A logical
framework for evaluating network resilience against
faults and attacks. In ASIAN 2007, pages 212–227.
Springer.
Catta, D., Leneutre, J., and Malvone, V. (2023a). Attack
graphs & subset sabotage games. Intelligenza Artifi-
ciale, 17(1):77–88.
Catta, D., Leneutre, J., and Malvone, V. (2023b). Obstruc-
tion logic: A strategic temporal logic to reason about
dynamic game models. In ECAI 2023, pages 365–372.
Catta, D., Stasio, A. D., Leneutre, J., Malvone, V., and Mu-
rano, A. (2023c). A game theoretic approach to attack
graphs. In ICAART 2023, pages 347–354.
Durkota, K., Lis
´
y, V., Bosansk
´
y, B., and Kiekintveld,
C. (2015a). Approximate solutions for attack graph
games with imperfect information. In GameSec 2015,
pages 228–249. Springer.
Durkota, K., Lisy, V., Bo
ˇ
sansky, B., and Kiekintveld, C.
(2015b). Optimal network security hardening using
attack graph games. IJCAI’15, page 526–532. AAAI
Press.
Fagin, R., Halpern, J., Moses, Y., and Vardi, M. (1995).
Reasoning about Knowledge. MIT.
Ingols, K., Lippmann, R., and Piwowarski, K. (2006). Prac-
tical attack graph generation for network defense. In
ACSAC’06, pages 121–130.
Jha, S., Sheyner, O., and Wing, J. M. (2002). Two formal
analyses of attack graphs. In CSFW-15, pages 49–63.
Kaynar, K. (2016). A taxonomy for attack graph generation
and usage in network security. J. Inf. Secur. Appl.,
29(C):27–56.
Lomuscio, A. and Raimondi, F. (2006). MCMAS: A model
checker for multi-agent systems. In TACAS 2006,
pages 450–454.
Nguyen, T. H., Wright, M., Wellman, M. P., and Baveja,
S. (2017). Multi-stage attack graph security games:
Heuristic strategies, with empirical game-theoretic
analysis. MTD ’17, page 87–97.
Noel, S., Jajodia, S., O’Berry, B., and Jacobs, M. (2003).
Efficient minimum-cost network hardening via exploit
dependency graphs. In ACSAC 2003, page 86.
Ou, X., Boyer, W. F., and McQueen, M. A. (2006). A
scalable approach to attack graph generation. In CCS
2006, pages 336–345.
Ou, X., Govindavajhala, S., and Appel, A. W. (2005). Mul-
val: A logic-based network security analyzer. In
USENIX Security ’05’, page 8.
Phillips, C. and Swiler, L. P. (1998). A graph-based system
for network-vulnerability analysis. In NSPW 1998,
pages 71–79.
Sheyner, O., Haines, J., Jha, S., Lippmann, R., and Wing, J.
(2002). Automated generation and analysis of attack
graphs. pages 273– 284.
ICAART 2024 - 16th International Conference on Agents and Artificial Intelligence
132