You are on page 1of 19

k-Zero Day Safety: A Network Security

Metric for Measuring the Risk of Unknown

Lingyu Wang, Sushil Jajodia, Anoop Singhal, Pengsu Cheng,
and Steven Noel
IEEE Transactions on Dependable and Secure Computing,
vol. 11, no. 1, pp. 30-44, 2014

Existing efforts on network security metrics typically assign
numeric scores to vulnerabilities based on known facts about
This paper proposes a novel network security metric, k-zero day
safety, to count how many zero-day vulnerabilities are required
to compromise a network asset.
Instead of measuring which unknown vulnerabilities are more likely to exist
Unknown vulnerabilities are not measurable.

Motivating example

Policy 1. The iptables rules are left in

a default configuration that accepts
all requests.

Policy 2. The iptables rules are

configured to only allow specific IPs,
excluding host 0, to access the ssh

At least one zero-day attack.

At least two zero-day attacks.

Modeling k-zero day safety

Information about the network:

A collection of hosts {0, 1, 2, F} (F for the firewall).
The connectivity relation {<0, F>, <0, 1>, <0, 2>, <1, F>, <1, 0>, <1, 2>, <2,
F>, <2, 0>, <2, 1>.
Services {http, ssh, iptables} on host 1, {ssh} on host 2, and {firewall} on
host F.
Privileges {user, root}.

Modeling k-zero day safety

Definition 1 (Network). The network model includes
the sets of hosts H, services S, and privileges P
the mappings from hosts to sets of services serv(.) :
the relation of connectivity

and privileges

Definition 2 (Zero-day exploit). Given a network,

for each remote service s, we define a zero-day vulnerability vs such that

the zero-day exploit <vs,h,h> has three preconditions, <s,h> (existence of
service), <h,h> (connectivity), and <p,h> (attackers existing privilege); it
has one postcondition <ps,h> where ps is the privilege of service s on h.

for each privilege p, we define a zero-day vulnerability vp such that the

preconditions of the zero-day exploit <vp,h,h> include the privileges of
remote services on h, and the postcondition is <p,h>.

Modeling k-zero day safety

Attack sequence is any sequence of exploits.
a: as the asset
seq(a): for any attack sequence that leads to a.

Attack sequences all lead to the asset <root,2>:

1. <vhttp,0,1>,<vssh,1,2>,
2. <viptables,0,1>,<vssh,1,2>,
3. <viptables,0,1>,<vssh,0,1>,
4. <vfirewall,0,F>,<vssh,0,2>,

Modeling k-zero day safety

The metric function k0d(.) counts how many exploits in their
symmetric difference are distinct.
Not related through

The k-zero day safety metric is defined by applying the metric

function k0d(.) to the minimal attack sequences leading to an

Modeling k-zero day safety

Definition 3 (k-Zero day safety). Given the set of zero-day
exploits E0, we define
a relation
such that
indicates either e and e
involve the same zero-day vulnerability, or e = <vs,h1,h2> and e =
<vp,h2,h2> are true, and exploiting s yields p. e and e are said distinct
a function k0d(.):
k 0d (.) : 2 E0 2 E0 [0, ] as
0d ( F , F ') max({| F '' |: F '' ( F F '), (e1 , e2 F '')(e1 v e2 )}),

where |F| denotes the cardinality, max(.) the maximum value, and
the symmetric difference
; and
for an asset a, we use k=k0d(a) for
where min(.) denotes the minimum value. For any
k-zero day safe.

, we say a is

Modeling k-zero day safety

1. <vhttp,0,1>,<vssh,1,2>, <vroot,2,2>
2. <viptables,0,1>,<vssh,1,2>, <vroot,2,2>
3. <viptables,0,1>,<vssh,0,1>,
4. <vfirewall,0,F>,<vssh,0,2>, <vroot,2,2>

Assume A = {<root,2>} then we have k0d(A) = 2, and the network is 2-zero day

Redefining Network Hardening

Network hardening: rendering a network k-zero day safe for a
larger k.
Under the model, those qualitative approaches essentially
achieve k > 0, meaning that attacks are no longer possible with
known vulnerabilities only.

Based on those equations of k = k0d(A), we can see that k may be

increased in many ways, including:
Increasing diversity

Asset backup

Strengthening isolation

Detection and prevention

Disabling services

Security services


Patching known vulnerabilities

Stricter access control


Case study - Diversity


Different services or firewalls involve different zero-day vulnerabilities.

None of the services, except iptables and tcpwrapper, are protected by sufficient isolation.

No known vulnerabilities are assumed in the services.

A = <root, 4>

Case1: the three web servers (host 1 through 3) are providing the http service
using the same software

k would remain the same regardless of the degree of diversity in these http services (k = 2)


Case study - Diversity

Case2: the iptables services on host 4 only accept requests from hosts 2 and 3.

Diversifying the ftp services on hosts 2 and 3 does not help for k. (k = 3)

Case3: ftpx and ftpy indicate two different ways for providing the ftp service on
hosts 2 and 3

The shortest attack sequences do not increase (k = 3).

Increasing diversity in hosts and services would not always help improving a
networks security.


Case study - Known Vulnerability and

Unnecessary Service


An unnecessary rsh service running on host 4 and additionally the effect of introducing a known
vulnerability vrsh into that service.

A = <root, 5>

Case4: without the rsh service on host 4

Totally four different zero-day vulnerabilities will be needed (k = 4).


Case study - Known Vulnerability and

Unnecessary Service

Case5: if service rsh is left running on host 4, but without any known

This does not actually change k (k = 4).

Case6: if vrsh is a known vulnerability

k will be reduced by one (k = 3).

Case7: if there is a known vulnerability in the ftp service on host 2.

This does not actually change k (k = 4). And patching this vulnerability will not help to make the
network more secure.


Case study - Backup of Asset


A known vulnerability exists in the http service on both hosts 1 and 5

Three candidate positions for placing a backup server for host 4 with location a, b, and c.

A = <root, 4>

Case8: without introducing any asset backup

Shortest attack sequences: [<vhttp,0,1>,<vssh,1,3>,<vnfs,3,4>], [<vhttp,0,1>,<vsmtp,1,2>,<vnfs,2,4>],


Two different zero-day vulnerabilities are needed (k = 2).


Case study - Backup of Asset

Case9: the backup server, host 7, at location a.

This does not actually change k, because the same zero-day vulnerability of the nfs service can
compromise both hosts 4 and 7 (k = 2).

Case10: the backup server, host 7, at location b, and changing firewall rules such
that host 4 is directly accessible from host 7 for backup purposes.

The shortest attack sequence: [<vhttp,0,1>,<vhttp,1,5>,<vnfs,5,7>,<vnfs,7,4>]. Only one zero-day

vulnerability is required (k = 1).

Case11: the backup server, host 7, at location c

The shortest attack sequence:

vulnerability is required. (k = 3)




Case study - Firewall



In:5, 7


A = <root, 6>

the personal firewall service on host 3 has a known vulnerability that may allow attackers to establish
connections to the ftp service running on host 3.


Shortest attack sequences: [<vftp,0,2>,<vp_firewall1,2,3>,<vftp,2,3>,<vnfs,3,4>,<vssh,4,5>,<vftp,5,6>],

[<vftp,0,2>,<vfirewall2,2,firewall2>,<vhttp,2,7>,<vftp,7,6>]. Since vp_firewall1 is known, k = 3.

Case13: moving host 3 to location a behind firewall 2, and removing its personal
firewall p firewall1, and adding extra rules to firewall 2 to only allow connection
requests from 1 to 3 and from 3 to 4.

Shortest attack sequences: [<vhttp,0,1>,<vftp,1,3>,<vhttp,3,7>,<vftp,7,6>]. k = 2.


The paper proposes a concept of vulnerability relations that
would replace some relational attack sequences by the same one
with the same vulnerability.
Many unknown vulnerabilities would appear at the same time to
achieve the attack.
The known vulnerabilities are cut-edge path on the attack graph
which decrease the length of zero-day attack sequence.


Thanks for listening !

Questions ?