# Identifying Superspreaders by Ranking System Object Instance Graphs

Rajani Suryavanshi, Xiaoyan Sun, Jun Dai

► To cite this version:

Rajani Suryavanshi, Xiaoyan Sun, Jun Dai. Identifying Superspreaders by Ranking System Object Instance Graphs. 19th IFIP International Conference on Digital Forensics (DigitalForensics), Jan 2023, Arlington, VA, United States. pp.179-201, 10.1007/978-3-031-42991-0_10. hal-05517473

HAL Id: hal-05517473

https://inria.hal.science/hal-05517473v1

Submitted on 18 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Identifying Superspreaders by Ranking System Object Instance Graphs

Rajani Suryavanshi¹, Xiaoyan Sun², and Jun Dai²

¹ KIOXIA America, Folsom, California, USA

² California State University Sacramento, Sacramento, California, USA
xiaoyan.sun@csus.edu

**Abstract.** Defending enterprise networks is very challenging due to the number of cyber attacks and their complexity. It is critical to understand how attacks occur and propagate in networks. System object instance graphs can reveal attack paths at the system level and help understand attack propagation. The graphs capture dependencies between system object instances such as files, processes and sockets, and help compute the infection probabilities of object instances. Attack paths are revealed by connecting instances with high infection probabilities. However, the graphs can be massive and difficult to comprehend.

Identifying the most important objects in system object instance graphs can enhance the understanding of infection propagation and the impacts. Importance in this context means high infection probabilities and large impacts to other objects. Objects on which other objects are heavily dependent have large impacts and need to be scrutinized. If these objects are infected, they can have huge negative impacts by infecting their dependent objects.

This chapter describes an approach for ranking objects using an extension of the AssetRank algorithm. Security analysts can use the dependency rankings to rapidly identify objects with the greatest impacts. When combined with the infection probabilities, the dependency ranking enables security analysts to prioritize the objects that need attention given limited time and resources. Experimental results demonstrate that the proposed dependency ranking approach successfully determines the objects with the largest impacts.

**Keywords:** System Object Instance Graph · Dependency Graph · AssetRank Algorithm

## 1 Introduction

Enterprise networks often incorporate crucial assets and resources that are of considerable interest to malicious entities. Attacks on enterprise networks can lead to security breaches, stolen data, financial losses, disruptions and even business termination. The complete understanding of how attacks occur is indispensable in digital forensics and crucial to recovery and improved cyber defense. However, the increasing numbers and complexity of attacks render attack detection and analysis even more difficult.
Enterprise networks have complex structures, large sizes and several layers of protection. As a result, malicious entities often have to launch multi-host, multi-stage cyber attacks on the networks [4]. The attacks initially explore enterprise networks to discover their configurations and passively monitor their activities. Next, system vulnerabilities are exploited to gain access and escalate privileges. Systems that have already been compromised are often leveraged as stepping stones to compromise other systems. Eventually, malicious code is embedded and/or sensitive data is exfiltrated.

Determining the various attack paths is effective for detecting attacks and understanding how they occur and propagate in enterprise networks. This is facilitated by the fact that most networks are under constant surveillance by security techniques and tools. Security sensors such as Snort, Tripwire, Wireshark and Ntop are often deployed across networks to capture security events. Alerts from a variety of sensors on hosts reveal malicious activities are chained in the form of attack paths. Additionally, system-level logs, such as system calls, capture the activities of malicious entities as well as legitimate users with fine granularity. This information can contribute significantly to understanding how attacks occur and propagate.

Dai et al. [4] have proposed an approach for identifying attack paths in enterprise networks. The approach represents the network-wide attack context as a superset graph of system objects such as files, processes and sockets called a system object dependency graph. A dependency graph is constructed by analyzing system calls from all the hosts in a network. Since system calls are attack neutral, the superset graph captures the activities of malicious entities as well as legitimate users. Forward and backward tracking is performed on the superset graph to identify the attack paths. However, this approach often identifies numerous attack paths, resulting in path explosion.

To address this problem, Sun et al. [27] proposed the ZePro method that identifies attack paths using probability theory. In particular, ZePro employs a system object instance graph instead of a system object dependency graph. A system object instance graph is constructed in a similar manner as a system object dependency graph, except that nodes in the graph are not objects, but instances of objects with specific timestamps. Each instance is a new version of an object at a different point in time, enabling the infection status of the object to be captured at different times. A Bayesian network is then constructed on top of the system object instance graph so that evidence from security sensors can be incorporated to compute the infection probabilities of object instances. An object instance with high infection probability means that the instance is very likely to be infected. An attack path is then manifested by connecting instances with high infection probabilities.

While these approaches help discover attack paths and identify infection propagation, security analysts find it difficult to use the information for two reasons. One is that the size and complexity of system object instance graphs are overwhelming. For example, a 15-minute system call log in an enterprise network can contain 143,120 system calls that involve 913 system objects, 39,361 object
dependencies, 39,840 instances and 74,598 instance dependencies [28]. Even after
system call filtering and graph pruning, the size of the system object instance
graph can be very large.

The second reason is that a revealed attack path may omit objects that have
significant impacts on other objects. This is because attack paths only contain
system object instances with high infection probabilities, but these instances
do not necessarily propagate infections massively. In a typical system object in-
stance graph, some impactful instances have large numbers of dependents and/or
more important dependents, while others do not. Once they are infected, these
impactful instances generate much larger negative impacts by infecting other
instances. Therefore, identifying and scrutinizing the most impactful instances
are critical to understanding the potential risks and attack propagation.

To address the challenges posed by system object instance graph size and
complexity, this chapter describes an approach for ranking object instances based
on their impacts using an extension of the AssetRank algorithm [25], a modifi-
cation of Google's PageRank algorithm [23]. Object instances with high depen-
dency ranks are depended on heavily by other object instances and need security
analyst attention due to their large impacts. Additionally, the dependency ranks
can be used in conjunction with the infection probabilities of object instances
computed by ZePro for better analysis.

Instances with high infection probabilities are very likely to be infected, but
may not necessarily have massive impacts on other instances, and vice versa.
Therefore, based on the instance dependency ranks and their infection probabil-
ities, instances are classified into four categories: instances with high dependency
ranks and high infection probabilities, instances with high dependency ranks but
low infection probabilities, instances with low dependency ranks but high infec-
tion probabilities, and instances with low dependency ranks and low infection
probabilities. This can greatly reduce the manual effort on the part of security
analysts and help prioritize their work given limited time and resources. Specifi-
cally, security analysts would focus first on instances with high dependency ranks
and high infection probabilities because they are the most dangerous and most
impactful. Next, depending on the situation, security analysts would investigate
instances in other categories, namely, those with high dependency ranks or high
infection probabilities. The proposed approach is the first to identify the im-
pactful system objects, including files, processes and sockets, that infect large
numbers of other objects.

2 Background

This section describes system object dependency graphs and system object in-
stance graphs.

## 2.1 System Object Dependency Graphs

System calls are usually the interfaces between user applications and the oper-
ating system kernel. Applications, whether legitimate or malicious, issue system
<figure><img src="image_3.png" /><figcaption>Fig. 1. System object dependency graph.</figcaption></figure>

calls to obtain services provided by the operating system. As a result, system call logs are great resources for revealing and analyzing malicious activities.

In an enterprise network with multiple hosts, system calls can be collected at each individual host. Each system call involves one or more system objects that include files, processes and sockets. Due to the actions produced by system calls, system objects have certain dependencies on each other. For example, when a process reads a file, the process depends on the file for data. Analyzing system calls enables a dependency graph to be constructed for system objects [4].

A system object dependency graph (SODG) is a directed graph with nodes corresponding to operating system objects and edges corresponding to dependencies between objects. A system call is broken down into three components, source object, sink object and dependency relation between the two objects. File, process and socket objects are illustrated as circles/ovals, rectangles and diamonds, respectively.

Consider the following system call log with system calls with timestamps t1, t2 and t3:

t1: file 1 read by process A;
t2: process A creates process B;
t3: process B writes to file 1

The system call at t1 is parsed as the dependency relation Process A depends on File 1: *File 1 → Process A*. The system call at t2 is parsed as the dependency relation Process B depends on Process A: *Process A → Process B*. The system call at t3 is parsed as the dependency relation File 1 depends on Process B: *Process B → File 1*. Figure 1 shows the system object dependency graph created by connecting the dependency relations.

A network-wide system object dependency graph is created by constructing per-host system object dependency graphs and concatenating them. Concatenation is performed when a directed edge exists between two nodes on different hosts. This usually involves socket communications in which nodes correspond to sockets and the directed edge represents the communications between the two sockets. For example, a send system call may indicate that Socket s1 on Machine X sends data to Socket s2 on Machine Y. In this case, the dependency
<figure><img src="image_4.png" /><figcaption>Fig. 2. System object instance graph.</figcaption></figure>

relation *Socket s1* → *Socket s2* is generated. Consequently, the per-host system object dependency graphs for Machine X and Machine Y can be concatenated to create a network-wide system object dependency graph.

A network-wide system object dependency graph is a superset graph with a set of paths. It contains the attack paths if malicious activities are involved. Starting from a triggering node, usually a suspicious object involved in a security alert, forward and backward tracking is performed to reveal the attack paths.

## 2.2 System Object Instance Graphs

ZePro [28] employs a Bayesian network to incorporate attack evidence (security alerts) and infer the infection probabilities of objects. However, as discussed in [28], it is not possible to construct a Bayesian network for a system object dependency graph. This is because a system object dependency graph cannot preserve the temporal information of system calls, which induces incorrect causality inferences. Additionally, a Bayesian network is an acyclic model that does not allow cycles inherited from a system object dependency graph (e.g., cycle involving File 1, Process A and Process B in Figure 1). Therefore, Sun et al. [27] proposed a new type of dependency graph called a system object instance graph for constructing Bayesian networks and computing infection probabilities.

A system object instance graph expresses dependencies between object instances. Each node in a system object instance graph is an instance of the object at a specific point of time. An object may be in a different state (infected or uninfected) at a different point of time. The state of an instance represents the state of an object at a specific time.

Figure 2 shows the system object instance graph generated for the example system call log shown above. The label on each edge shows the time associated with the corresponding system call. Thus, the instance graph reflects correct information flows based on the timestamps. For example, Process B writes to File 1 at time t3. In the system object instance graph, instead of connecting back to File 1, Process B points to the Instance 1 of File 1. The creation of the new
<figure><img src="image_5.png" /><figcaption>Fig. 3. Dependency rank generation.</figcaption></figure>

instance of File 1 also breaks the cycle created in the system object dependency graph by File 1, Process A and Process B.

Given a system object dependency graph, a Bayesian network can be constructed by assigning a conditional probability table to each node. The conditional probability tables define causality relations among nodes such as how the conditions of parent nodes can impact the conditions of child nodes. For example, in the Bayesian network based on Figure 2, the conditional probability table for node Process A Instance 1 specifies the probability of the node being infected based on the infection status of its parent node File 1 Instance 1. The Bayesian network is able to incorporate the evidence gathered from security sensors such as Snort and Tripwire. For example, if a file is observed to be infected, its probability of infection is set into one. This probability affects the infection probabilities of the other nodes in the Bayesian network. After incorporating all the evidence, the infection probabilities of all the nodes are computed. Object instances with high infection probabilities have higher chances of being infected. Therefore, the infection probabilities can be analyzed together with the dependency ranks of the instances to identify the instances that require security analyst attention and further scrutiny.

# 3 Proposed Approach

This section describes the proposed approach that incorporates dependency rank generation and system object instance ranking.

## 3.1 Dependency Rank Generation

Figure 3 shows the steps involved in dependency rank generation. First, system call auditing is performed on each host. The auditing captures malicious and legitimate user activities. Operating-system-aware information such as file inode numbers, process IDs and timestamps are preserved for system calls. Filtering is then applied to remove system calls for redundant and irrelevant objects.

In the next step, dependency relations are extracted by parsing the system calls. An example is a read system call where Process P reads File F is parsed to create the dependency: *File F* → *Process P*. Having specified the dependencies among system objects, a network-wide system object instance graph is created using the graph generation algorithm described in [28].
Next, the network-wide system object instance graph is employed to identify the attack paths (subset of the system object instance graph) or to generate the dependency ranks of all the instances. To reveal the attack paths, a Bayesian network is constructed and the evidence collected from security sensors is incorporated to compute the infection probabilities of the instances. Instances with high infection probabilities form attack paths.

The dependency ranks are generated by parsing graph information such as node shapes and dependency relations to the node types (AND, OR and SINK) required by AssetRank algorithm. The parsed node type information is written to a TXT file. Finally, the AssetRank algorithm processes the TXT file as input to compute the dependency ranks of all the instances.

## 3.2 System Object Instance Ranking

Google's PageRank algorithm [23] was developed to compute the importance of web pages based on the number of web pages linked to it. The algorithm uses the web page link structure to compute a rank and evaluate web page importance. The computations involved in the PageRank algorithm are general and can be applied to any problem that is represented in terms of a dependency graph [6].

In the PageRank algorithm, a page has its own intrinsic value that indicates its independent and individual importance. However, the page also gains extrinsic value from the pages linked to it. The page rank can become higher if a page has more links. However, a page that is linked by a few important pages with high intrinsic values may have a higher rank than a page linked by many less important pages.

In order to rank system object instances, the proposed approach applies an extension of the AssetRank algorithm [25], a modification of the generalized PageRank algorithm. The AssetRank algorithm is applicable to graphs that model dependency relationships among vertices. It can be applied to system object instance graphs because they describe dependencies among instances.

The AssetRank algorithm is implemented to suit the semantics of system object instance graphs. The algorithm computes the dependency rank values of system object instances. The rank of an instance reflects how much other system object instances depend on it. The higher the rank, the greater the impact the instance may have on other instances.

In the AssetRank algorithm, every vertex has a numeric value based on its importance in the network. The numeric value is computed by summing the intrinsic value of a vertex and the value that the vertex receives from its dependents [25].

Figure 4 shows the value flow among vertices in the AssetRank algorithm. Vertices $v_1$ and $v_2$ depend on $v_3$, and vertices $v_3$ and $v_4$ depend on $v_5$. If $v_1$ depends on $v_3$, which means $v_3$ is important to $v_1$, then the value of $v_1$ flows to $v_3$ and the value of $v_3$ is increased. The more nodes depend on $v_3$, the higher the value of $v_3$. As a result, $v_3$ has a darker shade in the figure.

In the case of $v_5$, some of the values of $v_3$ and $v_4$ flow to it and increase its value. However, the value of $v_5$ is lower than that of $v_3$ because $v_4$ has a
<figure><img src="image_6.png" /><figcaption>Fig. 4. Value flow in the AssetRank algorithm.</figcaption></figure>

low value. Note that the arrows in Figure 4 show the value flows instead of the dependency relations among vertices. Value flows have the opposite directions of dependencies in a system object instance graph, where $v_1$ depends on $v_3$ is denoted as $v_3 \to v_1$.

In the original PageRank algorithm [23], a vertex can have OR or AND relations. An OR vertex relation requires one of its preconditions (represented as out-neighbors) to be met. An AND vertex relation means all the preconditions present in the out-neighbors must be satisfied to reach the vertex. SINK denotes a vertex that does not have out-neighbors. Considering the special causality relations among vertices in a system object instance graph, vertices will only have OR relations. Specifically, consider a Process A that depends on File B and File C because it reads them. As long as File B or File C is infected, Process A will be infected.

Formally, a graph is defined as $G = (V, A, f, g, h)$ where $V$ is a set of vertices, $A$ is a set of arcs, $f$ is a mapping of weights to vertices, $g$ is a mapping of weights to arcs and $h$ is a mapping of vertices to their types [25]. The out-neighborhood $N^+(v)$ and in-neighborhood $N^-(v)$ of a vertex $v$ are defined as:

$$N^+(v) = \{w \in V : (v, w) \in A\}$$

$$N^-(v) = \{u \in V : (u, v) \in A\}$$

The sum of all the vertex weights is equal to one. If a vertex $v$ has type OR, the sum of all the arc weights is equal to one. If vertex $v$ has type AND, the sum of all the arc weights is equal to the number of out-neighborhoods. If vertex $v$ has type SINK, the sum of all the arc weights is equal to 0:

$$\Sigma_{w \in N^+(v)} g(v, w) = \begin{cases} 1, & \text{if } h(v) = \text{OR} \\ |N^+(v)|, & \text{if } h(v) = \text{AND} \\ 0, & \text{if } h(v) = \text{SINK} \end{cases}$$

where $|N^+(v)|$ denotes the cardinality of set $N^+(v)$.

The value $x_v$ of vertex $v$ is the sum of its intrinsic value and the value it obtains from its dependents:
$$x_v = \delta \sum_{u \in N^-(v)} g(u, v) x_u + (1 - \delta) f(v)$$

where $\delta$ is a damping factor that defines the ratio between the value a vertex receives from its dependents and its intrinsic value.

The values $x_v$ of all the vertices are placed in a vector $X$. All the dependencies between vertices are placed in a weighed adjacency matrix $D$ where $D_{vu} = g(u, v)$. Upon applying the Jacobi iteration method to the sequence, vector $X$ becomes:

$$X = \delta DX + (1 - \delta) IV$$

$$X_t = \delta DX_{t-1} + (1 - \delta) IV$$

The ranks of AND and OR vertices are computed differently. When a vertex has an OR type, the value of the vertex is split equally between all its dependents. However, when a vertex has an AND type, the value of the vertex is replicated to all its dependents. Since only OR vertices are considered in this work, the normalized equation becomes:

$$X_{t'} = \delta DX_{t-1} + (1 - \delta) IV$$

$$X_t = \frac{1}{\|X_{t'}\|} X_{t'}$$

The above sequence is expected to converge to one. However, due to the large scale of a system object instance graph, in rare cases, the sequence may not converge to one in a finite number of iterations. Therefore, the maximum number of iterations in the algorithm is set to 1,000, after which, the algorithm terminates even if the sequence has not converged to one.

# 4 Implementation

The first step in the implementation is to parse the system calls to generate a network-wide system object instance graph that is stored as a DOT file. DOT is a description language that is used to describe graphs such as flowcharts and dependency trees. The DOT file for a system object instance graph contains information such as node label (instance ID, instance name), shape (corresponding to the file, process or socket instance type), color (infection probability or dependency rank) and edge directions (dependencies among instances). In the research, Graphviz software was used to process and visualize DOT files.

A Perl parsing script was developed to process the network-wide system object instance graph. Eclipse IDE (Neon version with the EPIC plugin) was used to code the parser. The script parses node information such as node shape and dependency relations with regular expressions, and converts the information to node type (AND, OR, SINK) with the respective outward nodes. The node type information is stored in a TXT file that is passed as input to a Java program that implements the AssetRank algorithm.

The following is the DOT format representation of the simple system object instance graph shown in Figure 5:
<figure><img src="image_7.png" /><figcaption>Fig. 5. Simple system object instance graph.</figcaption></figure>

```perl
Digraph ABC {
  1 label = "1", shape = box, fillcolor = white;
  2 label = "2", shape = box, fillcolor = white;
  3 label = "3", shape = ellipse, fillcolor = white;
  4 label = "4", shape = diamond, fillcolor = white;
  5 label = "5", shape = box, fillcolor = white;
  6 label = "6", shape = box, fillcolor = white;
  7 label = "7", shape = ellipse, fillcolor = white;
  1->3;
  2->3;
  3->4;
  4->7;
  5->7;
  6->7;
}
```

The Perl script parses the DOT file into a series of node types along with dependent information. The following output produced by the script is stored in a TXT file for input to the Java program that computes the dependency ranks:

```
SINK
SINK
AND, 1, 2
OR, 3
SINK
SINK
AND, 4, 5, 6
OR, 7
```

The Java dependency ranking program stores node information and relative dependencies in an adjacency matrix. Vertex weights are computed by applying the AssetRank algorithm to the adjacency matrix. The results, a list of system object instance graph nodes and their ranks sorted in decreasing rank order, are stored in a CSV file. If desired, the CSV file and the original DOT file containing
<figure><img src="image_8.png" /><figcaption>Fig. 6. Attack scenario.</figcaption></figure>

node information could be used to visualize the ranks of instances in the system object instance graph. This is accomplished by invoking another Perl script that parses the node ranks and assigns colors to instances based on their ranks. For example, the top 10% ranked nodes are colored crimson and nodes in the 10% to 50% ranks are colored coral.

# 5 Attack Scenario and Results

This section presents the network-wide system object instance graph corresponding to an attack scenario, an identified zero-day attack path and detailed results.

## 5.1 Attack Scenario

A ZePro attack scenario described in [27, 28] is employed to analyze the dependency ranking of system object instances along with their infection rates. This enables the infection rates computed by ZePro to be used in this work.

Figure 6 shows the attack scenario [27, 28]. The malicious entity first gains root privileges on an SSH server by exploiting the CVE-2008-0166 vulnerability [16] and accesses an NFS server using SSH as a stepping stone. Due to an incorrect setup of the export table on the NFS server, the malicious entity uploads an executable containing a Trojan horse that exploits CVE-2009-2692 [17] to a public directory on the file server. The malicious executable is downloaded and installed on a workstation by an unwitting user. The malicious entity is then able to execute arbitrary code on the workstation. Snort, Tripwire, Wireshark and Ntop security sensors are deployed to capture security events that can be used as evidence of attacks.

Given the attack scenario, ZePro is employed to generate a system object instance graph for the network. The system object instance graph captures malicious and legitimate user activities during a 15-minute time period. Since the graph is extremely large, it is not possible to display the entire graph in this chapter. However, Figures 7 through 9 show different portions of the graph for
<figure><img src="image_9.png" /><figcaption>Fig. 7. Snippet of the system object instance graph of the SSH server.</figcaption></figure>
<figure><img src="image_10.png" /><figcaption>Fig. 8. System object instance graph of the NFS server.</figcaption></figure>
<figure><img src="image_11.png" /><figcaption>**Fig. 9.** Snippet of the system object instance graph of the workstation.</figcaption></figure>
<figure><img src="image_12.png" /><figcaption>Fig. 10. Magnified view of the dotted oval portion in Figure 7.</figcaption></figure>

each host involved in the attack scenario. Of course, readers are not expected to comprehend the details of these system object instance graphs.

However, to enable readers to visualize nodes and edges in a system object instance graph, Figure 10 shows a magnified view of the dotted oval portion in Figure 7. In this graph, file, process and socket instances are represented using ovals, rectangles and diamonds, respectively. For example, x198.1:(192.168.202.2:36057) is a socket on the machine with IP address 192.168.202.2 and port number 36057 and x199.1:(6692:4935:sshd) is a process with PID 6692, 4935 and process name sshd.

<table><caption>Table 1. Infection probabilities of representative instances.</caption><tbody><tr><th scope="row">Instance</th><td>x4.2</td><td>x69.1</td><td>x142.25</td><td>x253.8</td><td>x254.7</td><td>x259.1</td><td>x260.1</td></tr><tr><th scope="row">Prob.</th><td>0.87</td><td>0.01</td><td>0.99</td><td>0.99</td><td>0.95</td><td>0.92</td><td>0.89</td></tr><tr><th scope="row">Instance</th><td>x1007.6</td><td>x1008.5</td><td>x1017.1</td><td>x2005.1</td><td>x2006.3</td><td>x2083.1</td><td>x2082.2</td></tr><tr><th scope="row">Prob.</th><td>0.82</td><td>0.84</td><td>0.77</td><td>0.048</td><td>0.81</td><td>0.79</td><td>0.80</td></tr><tr><th scope="row">Instance</th><td>x2086.5</td><td>x2114.2</td><td>x2147.2</td><td>x2158.5</td><td>x2397.21</td><td>x2383.3</td><td>x2429.14</td></tr><tr><th scope="row">Prob.</th><td>0.82</td><td>0.83</td><td>0.84</td><td>0.77</td><td>0.96</td><td>0.76</td><td>0.99</td></tr></tbody></table>

The ZePro system is able to compute the infection probabilities for all the system object instances in the graphs. Due to the large number of instances, it is not possible to present the infection probabilities for all nodes. However, Table 1 shows the infection probabilities of representative instances.

Of course, readers are not expected to understand the details of the graphs. Indeed, the figures show how difficult it is to identify the system object instances that are depended on the most by other instances and that can infect most system objects. When analyzed together with the infection probabilities, the dependency ranking can help security analysts quickly identify the most important objects that need attention.
<figure><img src="image_13.png" /><figcaption>Fig. 11. Identified zero-day attack path [27, 28].</figcaption></figure>
Since a system object instance graph captures malicious activities, instances with high infection probabilities can be identified and revealed. These instances create an attack path, even a zero-day attack path if one or more zero-days are involved [27, 28]. Figure 11 shows a zero-day attack path identified in the system object instance graph that is used for result analysis.

## 5.2 Results

Dependency ranks were computed for all 1,853 nodes in the network-wide graph created from the system object instance graphs shown in Figures 7 through 9. The damping factor was set to 0.85, the standard value maintained in experiments involving the PageRank algorithm. All the nodes were given equal importance at the beginning of the algorithm and their ranks were computed iteratively until convergence to one or the maximum iteration count of 1,000 was reached.

Due to limited space, Table 2 shows the instances with the top 50 dependency rank values. Instances with greater numbers of out-going edges tend to have higher dependency rank values. This is because the AssetRank of an instance comprises two components, its intrinsic value and the value it gains from its dependents. Vertices with multiple dependents tend to have higher ranks. Analysis can be conducted based on the instance ranks and infection probabilities computed in [27, 28]. Examination of Table 2 and Figure 11 reveals that instances with the highest dependency ranks may not have the highest infection probabilities, and vice versa.

The system object instances in the network-wide graph are divided into four categories:

- **High Dependency Rank; High Infection Probability:** Instances in this category deserve the most attention from security analysts. A high dependency rank means that the instance has many dependents connected to it throughout the network. Since the infection probability is also high, an attack will propagate through the network very easily. For example, Instance 2086.5 (Process tar) and Instance 2147.2 (Process exploit.sh) appear in Table 2 and Figure 11 and are, therefore, critical to the success of the attack. Table 1 lists the infection probability of Instance 2086.5 as 0.82, indicating it is very likely to be infected; meanwhile, it is ranked one in Table 2, which means that many instances depend on it and the instance may propagate infections to them very easily. Therefore, security analysts should identify instances of this category as soon as possible and take countermeasures to eliminate or contain attacks. Security analysts should also check potential vulnerabilities associated with these instances and perform network hardening to prevent repeat attacks.

- **High Dependency Rank; Low Infection Probability:** Instances in this category have low likelihood of being infected. Their high dependency ranks could be due to multiple dependents contributing to their extrinsic values. Although, their infection probabilities are low, if these instances are attacked, the attack propagation could be severe because they have multiple
<table><caption>**Table 2.** Dependency ranks of the top 50 instances in the graph.</caption><thead><tr><th>Rank</th><th>Instance</th><th>Object</th><th>Rank Value</th></tr></thead><tbody><tr><td>1</td><td>2086.5</td><td>6763:6719:tar</td><td>0.0005927777894456</td></tr><tr><td>2</td><td>290.1</td><td>6729:6724:savelog</td><td>0.0005830315634006</td></tr><tr><td>3</td><td>2005.1</td><td>/etc/locale.alias</td><td>0.0005746923615380</td></tr><tr><td>4</td><td>69.1</td><td>/etc/nsswitch.conf:8798393</td><td>0.0005713089890883</td></tr><tr><td>5</td><td>25.1</td><td>5908:5897:apt</td><td>0.0005639606663220</td></tr><tr><td>6</td><td>2023.2</td><td>2816:1:udevd</td><td>0.0005630498216020</td></tr><tr><td>7</td><td>2147.2</td><td>6783:6781:exploit.sh</td><td>0.0005597664307222</td></tr><tr><td>8</td><td>101.4</td><td>6620:6604:cupsys</td><td>0.0005597639076630</td></tr><tr><td>9</td><td>2124.1</td><td>6285:5798:bash</td><td>0.0005597588152304</td></tr><tr><td>10</td><td>2493.12</td><td>6815:6813:bash</td><td>0.0005581044873810</td></tr><tr><td>11</td><td>263.2</td><td>6709:5897:run-parts</td><td>0.0005564425363920</td></tr><tr><td>12</td><td>223.2</td><td>2774:1:udevd</td><td>0.0005564349986352</td></tr><tr><td>13</td><td>2091.1</td><td>/etc/nsswitch.conf:1491129</td><td>0.0005532248168440</td></tr><tr><td>14</td><td>2429.14</td><td>6811:6803:useradd</td><td>0.0005531413877282</td></tr><tr><td>15</td><td>45.1</td><td>/etc/localtime:8798371</td><td>0.0005523218315349</td></tr><tr><td>16</td><td>188.1</td><td>/proc/sys/kernel/ngroups_max:12635</td><td>0.0005515249821289</td></tr><tr><td>17</td><td>2026.2</td><td>/:2</td><td>0.0005514693370436</td></tr><tr><td>18</td><td>52.1</td><td>5897:5896:run-parts</td><td>0.0005481961040248</td></tr><tr><td>19</td><td>183.1</td><td>/etc/pam.d/common-account:8799591</td><td>0.0005481935267130</td></tr><tr><td>20</td><td>78.2</td><td>6604:6603:sh</td><td>0.0005481833960051</td></tr><tr><td>21</td><td>182.1</td><td>/etc/pam.d/common-auth:8799592</td><td>0.0005481783462166</td></tr><tr><td>22</td><td>186.1</td><td>/etc/pam.d/other</td><td>0.0005481783345730</td></tr><tr><td>23</td><td>181.1</td><td>/etc/pam.d/sshd:8800291</td><td>0.0005481783345611</td></tr><tr><td>24</td><td>184.1</td><td>/etc/pam.d/common-session:8799594</td><td>0.0005481783345492</td></tr><tr><td>25</td><td>185.1</td><td>/etc/pam.d/common-password:8799593</td><td>0.0005481783345434</td></tr><tr><td>26</td><td>62.1</td><td>/proc/filesystems:4026531844</td><td>0.0005481783345433</td></tr><tr><td>27</td><td>2076.1</td><td>/bin/ls:532536</td><td>0.0005481783345137</td></tr><tr><td>28</td><td>2074.1</td><td>6719:6718:bash</td><td>0.0005481758038124</td></tr><tr><td>29</td><td>189.1</td><td>/home/jun/.ssh/authorized_keys:4636779</td><td>0.0005473713971032</td></tr><tr><td>30</td><td>4.1</td><td>6560:6559:mount.nfs</td><td>0.0005473562399357</td></tr><tr><td>31</td><td>2375.1</td><td>6796:6793:collect2</td><td>0.0005473473551626</td></tr><tr><td>32</td><td>2390.1</td><td>6801:6798:collect2</td><td>0.0005473473551626</td></tr><tr><td>33</td><td>226.2</td><td>/:2</td><td>0.0005465138528115</td></tr><tr><td>34</td><td>223.1</td><td>2774:1:udevd</td><td>0.0005457474421339</td></tr><tr><td>35</td><td>2023.1</td><td>2816:1:udevd</td><td>0.0005457335034186</td></tr><tr><td>36</td><td>144.1</td><td>/usr/sbin/sshd:9462668</td><td>0.0005457094577282</td></tr><tr><td>37</td><td>153.7</td><td>6687:4935:sshd</td><td>0.0005457043885236</td></tr><tr><td>38</td><td>2006.2</td><td>6737:6736:mount</td><td>0.0005457031115441</td></tr><tr><td>39</td><td>152.1</td><td>/etc/hosts.deny:8798361</td><td>0.0005457018810209</td></tr><tr><td>40</td><td>2081.1</td><td>/proc/filesystems:4026531844</td><td>0.0005456993367521</td></tr><tr><td>41</td><td>2308.3</td><td>6793:6783:cc</td><td>0.0005456968001993</td></tr><tr><td>42</td><td>2383.3</td><td>6798:6783:cc</td><td>0.0005456968001993</td></tr><tr><td>43</td><td>123.1</td><td>/etc/hosts:8798410</td><td>0.0005456967964019</td></tr><tr><td>44</td><td>301.1</td><td>/bin/mv:966724</td><td>0.0005456967963309</td></tr><tr><td>45</td><td>194.16</td><td>6690:4935:sshd</td><td>0.0005456942656000</td></tr><tr><td>46</td><td>162.1</td><td>6679:4935:sshd</td><td>0.0005456942578573</td></tr><tr><td>47</td><td>2397.1</td><td>6803:6783:wunderbar_empor</td><td>0.0005456917348751</td></tr><tr><td>48</td><td>2311.16</td><td>6699:4935:sshd</td><td>0.0005456892041560</td></tr><tr><td>49</td><td>160.1</td><td>6680:4935:sshd</td><td>0.0005456892041382</td></tr><tr><td>50</td><td>164.1</td><td>6682:4935:sshd</td><td>0.0005456892041382</td></tr></tbody></table>
dependents. For example, some instances have high ranks in Table 2 but are
not included in Figure 11. These instances may have very high impacts on
other objects, but low infection probabilities. One example is Instance 69.1
(File /etc/nsswitch.conf), which is used by applications to determine the
sources for obtaining name-service information in a range of categories as
well as their order. Although the file has a low infection probability of 0.01
(Table 1), security analysts must examine it carefully due to its significant
impact (rank four in Table 2).

- **Low Dependency Rank; High Infection Probability:** Instances in this category have high likelihoods of being infected despite their low dependency ranks. Analyzing these objects can help security analysts understand which objects are impacted by malicious activities and how the impacts occur. It would also be helpful to check the dependency ranks of these instances to ensure that the negative impacts do not propagate. Table 3 shows the dependency ranks of the top 50 instances in the zero-day attack path. Many instances, such as Instance 2114.2 (File /home/user/test-bed/workstationattack/wunderbar emporium/pwnkernel.c), have high infection probabilities but relatively low dependency ranks. The infection probability of Instance 2114.2 is 0.83, but its dependency rank is not among the top 50 instances in the attack path. Such instances do not have many dependent instances, but they need to be carefully checked by security analysts due to their high infection probabilities.

- **Low Dependency Rank; Low Infection Probability:** Instances in this category have very low likelihoods of being infected. Their low dependency ranks imply that they do not have many dependent instances. Thus, if these instances are infected, the propagation will occur in a controlled manner. Security analysts should give these instances the lowest priority when resources are limited.

The proposed approach enables security analysts to identify the most critical
object instances in terms of their dependency ranks and infection probabilities.
The two perspectives enable the prioritization of object instances for investiga-
tion, enabling security analysts to focus their limited time and scarce resources
to good effect.

6 Related Work

This research has drawn on previous work on zero-day attack path detection [4, 27, 28] that utilizes dependency relations among system objects to capture malicious activities at the system level. Dai et al. [4] proposed the construction of system object dependency graphs based on system calls and using them to reveal zero-day attack paths by tracking system objects involved in security alerts. Sun et al. [27, 28] subsequently proposed the creation of Bayesian networks on top of system object instance graphs, enabling the computation of object instance infection probabilities, and connecting object instances with high infection probabilities to reveal zero-day attack paths. These approaches focus on recognizing
<table><caption>**Table 3.** Dependency ranks of the top 50 instances in the zero-day attack path.</caption><thead><tr><th>Rank</th><th>Instance</th><th>Object</th><th>Rank Value</th></tr></thead><tbody><tr><td>1</td><td>2086.5</td><td>6763:6719:tar</td><td>0.0005927777894456</td></tr><tr><td>2</td><td>2147.2</td><td>6783:6781:exploit.sh</td><td>0.0005597664307222</td></tr><tr><td>3</td><td>2493.12</td><td>6815:6813:bash</td><td>0.0005581044873810</td></tr><tr><td>4</td><td>2429.14</td><td>6811:6803:useradd</td><td>0.0005531413877282</td></tr><tr><td>5</td><td>4.1</td><td>6560:6559:mount.nfs</td><td>0.0005473562399357</td></tr><tr><td>6</td><td>2006.2</td><td>6737:6736:mount</td><td>0.0005457031115441</td></tr><tr><td>7</td><td>2383.3</td><td>6798:6783:cc</td><td>0.0005456968001993</td></tr><tr><td>8</td><td>2308.3</td><td>6793:6783:cc</td><td>0.0005456968001993</td></tr><tr><td>9</td><td>2397.101</td><td>wunderbar_empor</td><td>0.0005456917348751</td></tr><tr><td>10</td><td>2429.7</td><td>6811:6803:useradd</td><td>0.0005440424297800</td></tr><tr><td>11</td><td>1008.4</td><td>5118:1:unfsd</td><td>0.0005440411760642</td></tr><tr><td>12</td><td>2397.8</td><td>wunderbar_empor</td><td>0.0005440411760287</td></tr><tr><td>13</td><td>2397.11</td><td>wunderbar_empor</td><td>0.0005440399068096</td></tr><tr><td>14</td><td>1008.2</td><td>5118:1:unfsd</td><td>0.0005440373838006</td></tr><tr><td>15</td><td>253.8</td><td>6706:6703:sshd</td><td>0.0005432279583837</td></tr><tr><td>16</td><td>2144.4</td><td>6781:6285:bash</td><td>0.0005432128164641</td></tr><tr><td>17</td><td>2086.4</td><td>6763:6719:tar</td><td>0.0005424676923594</td></tr><tr><td>18</td><td>1008.1</td><td>5118:1:unfsd</td><td>0.0005423956554335</td></tr><tr><td>19</td><td>2493.11</td><td>6815:6813:bash</td><td>0.0005423906095075</td></tr><tr><td>20</td><td>2429.9</td><td>6811:6803:useradd</td><td>0.0005423906094453</td></tr><tr><td>21</td><td>2429.101</td><td>6811:6803:useradd</td><td>0.0005423906055799</td></tr><tr><td>22</td><td>2429.11</td><td>6811:6803:useradd</td><td>0.0005423906055798</td></tr><tr><td>23</td><td>2397.201</td><td>wunderbar_empor</td><td>0.0005423880748490</td></tr><tr><td>24</td><td>2114.2</td><td>...wunderbar_emporium/pwnkernel.c</td><td>0.0005423868133430</td></tr><tr><td>25</td><td>2397.14</td><td>wunderbar_empor</td><td>0.0005423855518548</td></tr><tr><td>26</td><td>2397.9</td><td>wunderbar_empor</td><td>0.0005423855479953</td></tr><tr><td>27</td><td>2397.19</td><td>wunderbar_empor</td><td>0.0005423855479894</td></tr><tr><td>28</td><td>10.1</td><td>/etc/mtab:8798397</td><td>0.0005415710300122</td></tr><tr><td>29</td><td>1007.1</td><td>172.18.34.5:2049</td><td>0.0005415659839528</td></tr><tr><td>30</td><td>259.1</td><td>/mnt/workstationattack.tar.gz:9453574</td><td>0.0005415634378076</td></tr><tr><td>31</td><td>2114.1</td><td>...wunderbar_emporium/pwnkernel.c</td><td>0.0005415634281084</td></tr><tr><td>32</td><td>2082.2</td><td>/home/...attack.tar.gz</td><td>0.0005415622864635</td></tr><tr><td>33</td><td>1008.5</td><td>5118:1:unfsd</td><td>0.0005415609225679</td></tr><tr><td>34</td><td>2397.21</td><td>wunderbar_empor</td><td>0.0005415608993991</td></tr><tr><td>35</td><td>2006.3</td><td>6737:6736:mount</td><td>0.0005415608993162</td></tr><tr><td>36</td><td>2503.1</td><td>6818:6815:bash</td><td>0.0005415608993102</td></tr><tr><td>37</td><td>2385.301</td><td>6799:6798:cc1</td><td>0.0005415608993102</td></tr><tr><td>38</td><td>2385.3</td><td>6799:6798:cc1</td><td>0.0005415608993102</td></tr><tr><td>39</td><td>2311.401</td><td>6794:6793:cc1</td><td>0.0005415608993102</td></tr><tr><td>40</td><td>2152.3</td><td>...wunderbar_emporium/pwnkernel.c</td><td>0.0005415608993102</td></tr><tr><td>41</td><td>2452.1</td><td>/etc/shadow+:1493108</td><td>0.0005415608954389</td></tr><tr><td>42</td><td>2388.2</td><td>/tmp/ccUZcd3t.o:2984227</td><td>0.0005415608954389</td></tr><tr><td>43</td><td>2372.2</td><td>/tmp/ccfRR34r.o:2984223</td><td>0.0005415608954389</td></tr><tr><td>44</td><td>2527.3</td><td>6830:6815:bash</td><td>0.0005415583685793</td></tr><tr><td>45</td><td>2458.1</td><td>/etc/gshadow+:1493110</td><td>0.0005415583685793</td></tr><tr><td>46</td><td>2455.1</td><td>/etc/group+:1493109</td><td>0.0005415583685793</td></tr><tr><td>47</td><td>2449.1</td><td>/etc/passwd+:1493107</td><td>0.0005415583685793</td></tr><tr><td>48</td><td>2443.1</td><td>/etc/gshadow.6811:1493106</td><td>0.0005415583685793</td></tr><tr><td>49</td><td>2440.1</td><td>/etc/group.6811:1493105</td><td>0.0005415583685793</td></tr><tr><td>50</td><td>2437.1</td><td>/etc/shadow.6811:1493104</td><td>0.0005415583685793</td></tr></tbody></table>
objects and instances that are potentially compromised, but they do not investi-
gate objects and instances that have large impacts and may infect more objects
or instances.

This research is also related to system-level provenance tracking that mon-
itors system activities for intrusion forensics and recovery. Several works have
tracked malicious activities at the system level [2, 3, 5, 7–9, 13–15, 18, 24]. Like
these works, this research leverages the dependencies among system objects such
as files, processes and sockets. However, its main purpose is to determine high-
impact system instances based on their dependencies instead of merely tracking
malicious activities.

The research on capturing dependencies and ranking dependency graphs is related to work on logical attack graphs [1, 10–12, 19–22]. Attack graphs are used to generate potential attack paths by analyzing the causality relations involved in vulnerability exploitation. Dependency attack graphs are essentially attack graphs that capture dependencies among facts. For example, a fact that “vulnerability X is exploited” may depend on the facts: “a host runs a service” and “the service has vulnerability X.” Some researchers [4, 26] have proposed the ranking of attack graphs to identify the critical attack assets in enterprise networks, such as servers with key vulnerabilities. This research also ranks the dependency graphs, but the dependency graphs are of a different type and are at a different abstract level. In particular, work on logical attack graphs is at the application level and identifies critical attack assets associated with applications and services whereas this research is at the system level and identifies impactful object instances in enterprise systems.

7 Conclusions

System object instance graphs reveal attack paths by connecting object instances
with high infection probabilities. However, the graphs can be very large and
overwhelming, which makes them difficult for security analysts to comprehend.
In the experiments, system calls were collected over a small timeframe, but the
number of calls was still huge. Indeed, the complexity of system object instance
graphs keeps increasing as more and more instances are created when objects
are accessed by other objects.

Combining the dependency ranks of object instances with their infection
probabilities significantly reduces the time and resources needed for security
analysts to understand complex system object instance graphs. Indeed, this ap-
proach can be used in combination with other intrusion detection techniques
and tools to narrow down the suspicious system objects and focus on the most
critical objects in attack paths.

**Acknowledgment** This research was supported by the National Science Foundation under Grant no. DGE 2105801.
References

1. P. Ammann, D. Wijesekera and S. Kaushik, Scalable graph-based network vul-
nerability analysis, *Proceedings of the Ninth ACM Conference on Computer and
Communications Security*, pp. 217–224, 2002.

2. A. Bates, D. Tian, K. Butler and T. Moyer, Trustworthy whole-system provenance for the Linux kernel, *Proceedings of the Twenty-Fourth USENIX Security Symposium*, pp. 319–334, 2015.

3. U. Braun, S. Garfinkel, D. Holland, K. Muniswamy-Reddy and M. Seltzer, Issues in automatic provenance collection, in *Provenance and Annotation of Data*, L. Moreau and I. Foster (Eds.), Springer, Berlin Heidelberg, Germany, pp. 171–183, 2006.

4. J. Dai, X. Sun and P. Liu, Patrol: Revealing zero-day attack paths through network-wide system object dependencies, *Proceedings of the Eighteenth European Symposium on Research in Computer Security*, pp. 536–555, 2013.

5. A. Gehani and D. Tariq, SPADE: Support for provenance auditing in distributed environments, *Proceedings of the Thirteenth ACM/ IFIP/USENIX International Middleware Conference*, pp. 101–120, 2012.

6. D. Gleich, PageRank beyond the web, *SIAM Review*, vol. 57(3), pp. 321–363, 2015.

7. A. Goel, W. Feng, D. Maier, W. Feng and J. Walpol, Forensix: A robust high-
performance reconstruction system, *Proceedings of the Twenty-Fifth IEEE Inter-
national Conference on Distributed Computing Systems*, pp. 155–162, 2005.

8. A. Goel, K. Po, K. Farhadi, Z. Li and E. de Lara, The Taser intrusion recovery system, *ACM SIGOPS Operating Systems Review*, vol. 39(5), pp. 163–176, 2005.

9. M. Hossain, S. Milajerdi, J. Wang, B. Eshete, R. Gjomemo, R. Sekar, S. Stoller and V. Venkatakrishnan, SLEUTH: Real-time attack scenario reconstruction from COTS audit data, *Proceedings of the Twenty-Sixth USENIX Security Symposium*, pp. 487–504, 2017.

10. H. Huang, S. Zhang, X. Ou, A. Prakash and K. Sakallah, Distilling critical attack graph surface iteratively through minimum-cost SAT solving, *Proceedings of the Twenty-Seventh Annual Computer Security Applications Conference*, pp. 31–40, 2011.

11. K. Ingols, R. Lippmann and K. Piwowarski, Practical attack graph generation for network defense, *Proceedings of the Twenty-Second Annual Computer Security Applications Conference*, pp. 121–130, 2006.

12. S. Jajodia, S. Noel and B. O'Berry, Topological analysis of network attack vul-
nerability, in *Managing Cyber Threats*, V. Kumar, J. Srivastava and A. Lazarevic
(Eds.), Springer, Boston, Massachusetts, pp. 247–266, 2005.

13. X. Jiang, A. Walters, D. Xu, E. Spafford, F. Buchholz and Y. Wang, Provenance-aware tracing of worm break-in and contaminations: A process coloring approach, *Proceedings of the Twenty-Sixth IEEE International Conference on Distributed Computing Systems*, 2006.

14. S. King and P. Chen, Backtracking intrusions, *ACM SIGOPS Operating Systems Review*, vol. 37(5), pp. 223–236, 2003.

15. S. Ma, X. Zhang and D. Xu, ProTracer: Towards practical provenance tracing by alternating between logging and tainting, *Proceedings of the Twenty-Third Annual Network and Distributed System Security Symposium*, 2016.

16. MITRE Corporation, CVE-2008-0166, Common Vulnerabilities and Exposures, Bedford, Massachusetts (cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166), January 9, 2008.
17. MITRE Corporation, CVE-2009-2692, Common Vulnerabilities and Exposures, Bedford, Massachusetts (cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2692), August 5, 2009.

18. K. Muniswamy-Reddy, D. Holland, U. Braun and M. Seltzer, Provenance-aware storage systems, *Proceedings of the USENIX Annual Technical Conference*, pp. 43–56, 2006.

19. S. Noel and S. Jajodia, Managing attack graph complexity through visual hierarchical aggregation, *Proceedings of the ACM Workshop on Visualization and Data Mining for Computer Security*, pp. 109–118, 2004.

20. S. Noel, S. Jajodia, B. O'Berry and M. Jacobs, Efficient minimum-cost network hardening via exploit dependency graphs, *Proceedings of the Nineteenth Annual Computer Security Applications Conference*, pp. 86–95, 2003.

21. X. Ou, W. Boyer and M. McQueen, A scalable approach to attack graph generation, *Proceedings of the Thirteenth ACM Conference on Computer and Communications Security*, pp. 336–345, 2006.

22. X. Ou, S. Govindavajhala and A. Appel, MulVAL: A logic-based network security analyzer, *Proceedings of the Fourteenth USENIX Security Symposium*, 2005.

23. L. Page, S. Brin, R. Motwani and T. Winograd, The Page-Rank Citation Ranking: Bringing Order to the Web, Technical Report SIDL-WP-1999-0120, Stanford Digital Library Technologies Project, Stanford University, Palo Alto, California, 1998.

24. D. Pohly, S. McLaughlin, P. McDaniel and K. Butler, Hi-Fi: Collecting high-fidelity whole-system provenance, *Proceedings of the Twenty-Eighth Annual Computer Security Applications Conference*, pp. 259–268, 2012.

25. R. Sawilla and X. Ou, Googling Attack Graphs, DRDC Ottawa TM 2007-205, Defence Research and Development Canada, Ottawa, Canada, 2007.

26. R. Sawilla and X. Ou, Identifying critical attack assets in dependency attack graphs, *Proceedings of the Thirteenth European Symposium on Research in Computer Security*, pp. 18–34, 2008.

27. X. Sun, J. Dai, P. Liu, A. Singhal and J. Yen, Towards probabilistic identification of zero-day attack paths, *Proceedings of the IEEE Conference on Communications and Network Security*, pp. 64–72, 2016.

28. X. Sun, J. Dai, P. Liu, A. Singhal and J. Yen, Using Bayesian networks for probabilistic identification of zero-day attack paths, *IEEE Transactions on Information Forensics and Security*, vol. 13(10), pp. 2506–2521, 2018.