Spelling Corrections in Chapters 1-4

Chapter1.tex

@@ -4,13 +4,13 @@ Cybersecurity has been at the forefront of computing for decades, and vulnerabil
 is to represent a system or a set of systems through graphical means, and encode information into the nodes and edges of the graph. Even as early as the late 1990s,
 experts have composed various graphical models to map devices and vulnerabilities through attack trees, and this work can be seen through the works published by the authors of \cite{phillips_graph-based_1998}.
 This work, and other attack tree discussions of this time such as that conducted by the author of \cite{schneier_modeling_1999}, would later be referred to as early versions of modern-day attack graphs
-\cite{ou_scalable_2006}. By utilizing this graphical approach, cybersecurity postures can be measued at a system's current status, as well as hypothesize and examine other postures based on system changes
+\cite{ou_scalable_2006}. By utilizing this graphical approach, cybersecurity postures can be measured at a system's current status, as well as hypothesize and examine other postures based on system changes
 over time.
 
-Attack Graphs are an appealing approach since they are often designed to be exhaustive: all system properties are represented at its intial state, all attack options are fully enumerated, all permutations are
+Attack Graphs are an appealing approach since they are often designed to be exhaustive: all system properties are represented at its initial state, all attack options are fully enumerated, all permutations are
 examined, and all changes to a system are encoded into their own independent states, where these states are then individually analyzed through the process. The authors of \cite{sheyner_automated_2002} also 
-discuss the advantage of conciseness of attack graphs, where the final graph only incorporates states that an attacker can leverage; no superflous states are generated that can clutter analysis. Despite their
-advantages, attack graphs do suffer from their exhaustiveness. As the authors of \cite{ou_scalable_2006} examine, even very small networks with only 10 hosts and 5 vulnerabilites yield graphs with 10 million
+discuss the advantage of conciseness of attack graphs, where the final graph only incorporates states that an attacker can leverage; no superfluous states are generated that can clutter analysis. Despite their
+advantages, attack graphs do suffer from their exhaustiveness. As the authors of \cite{ou_scalable_2006} examine, even very small networks with only 10 hosts and 5 vulnerabilities yield graphs with 10 million
 edges. When scaling attack graphs to analyze the modern, interconnected state of large networks comprising of a multitude of hosts, and utilizing the entries located in the National Vulnerability Database and any
 custom vulnerability testing, this becomes infeasible. Similar difficulties arise in related fields, where social networks, bio-informatics, and neural network representations also result in graphs with millions of
 states \cite{zhang_boosting_2017}. Various efforts that will be discussed in Section \ref{sec:related_works} demonstrate methods and techniques that can mitigate these difficulties and improve performance.

Chapter3.tex

@@ -6,11 +6,11 @@ analyzing the entire network can be overwhelming complex. As a means of simplify
 the network at a time, rather than feeding the entire network into an analysis algorithm. To aid in this effort, a Path Walking feature was implemented as a
 separate program, and has two primary modes of usage. The goal of this feature is to provide a subset of the network that includes all possible paths from the
 root node to a designated node. The first mode is a manual mode, where a user can input the desired state to walk to, and the program will output a separate
-graph of all possible paths to the specified state. The second mode is an automatic mode, where the program will output seperate subgraphs to all states in
+graph of all possible paths to the specified state. The second mode is an automatic mode, where the program will output separate subgraphs to all states in
 the network that have qualities of $``compliance$\_$vio = true"$ or $``compliance$\_$vios > 0"$. This often produces multiple subgraphs, that can then be 
 separately fed into an analysis program. 
 
-Figure \ref{fig:PW} demonstates an output of the Path Walking feature when walking to state 14. In this figure, the primary observable feature is that the
+Figure \ref{fig:PW} demonstrates an output of the Path Walking feature when walking to state 14. In this figure, the primary observable feature is that the
 network was reduced from 16 states to 6 states, and 32 edges to 12 edges. The reduction from the original network to the subset varies on the overall connectivity 
 of the original Attack Graph, but the reduction can aid in simplifying the analysis process if only certain states of the network are to be analyzed.
 \begin{figure}[htp]
@@ -60,7 +60,7 @@ Figure \ref{fig:CC} displays an example graph that leverages color coding to eas
 
 \TUsection{Intermediate Database Storage}
 \TUsubsection{Memory Constraint Difficulties}
-Previous works with RAGE have been designed around maximizing performance to limit the longer runtimes caused by the state space explosion, such as the works seen by the authors of \cite{cook_rage_2018},
+Previous works with RAGE have been designed around maximizing performance to limit the longer runtime caused by the state space explosion, such as the works seen by the authors of \cite{cook_rage_2018},
 \cite{li_concurrency_2019}, and \cite{li_combining_2019}. To this end, the output graph is stored in memory during the generation process to minimize disk writing and reading, as well as leverage the
 performance benefits of memory operations since graph computation relies less on processor speed than that of data dependency complexity, parallelism coarseness, and memory access time
  \cite{zhang_boosting_2017}, \cite{ainsworth_graph_2016}, \cite{berry_graph_2007}. The author of \cite{cook_rage_2018} does incorporate PostgreSQL as a final storage mechanism to write the resulting
@@ -104,14 +104,14 @@ performance benefits of memory operations since graph computation relies less on
  \TUsubsection{Portability}
  The intermediate database storage is greatly advantageous in increasing the portability of RAGE across various systems, while still allowing for performance benefits. By allowing for a user-defined argument, users can safely assign
  a value that allows for other processes and for the host OS to continue their workloads. While the ``total memory" component currently utilizes the Linux \textit{sysconf()} function, this is not rigid and is easily adjustable. When 
- working on a High-Perfomance Computing cluster, using this function could lead to difficulties since multiple users may be working on the same nodes, which prevents RAGE from fully using all system memory. This could be prevented 
+ working on a High-Performance Computing cluster, using this function could lead to difficulties since multiple users may be working on the same nodes, which prevents RAGE from fully using all system memory. This could be prevented 
  by using a job scheduler argument such as Slurm's ``--exclusive" option, but this may not be desirable. Instead, a user could pass in the amount of total memory to use (and can be reused from a job scheduler's memory allocation
  request option), and the intermediate database storage process would function in the same fashion.
 
 
 \TUsection{Relational Operators}
 As discussed in Section \ref{sec:compops}, many of the networks previously generated by RAGE compromise of states with an established set of qualities and values. These typically have included $``compliance$\_$vio=true/false"$,
-$``root=true/false"$, or other general $``true/false"$ values or $``version=X"$ qualities. To further expand the dynamism of attack graph generation, it is important to distinguish when a quality has a value that satisifies a
+$``root=true/false"$, or other general $``true/false"$ values or $``version=X"$ qualities. To further expand the dynamism of attack graph generation, it is important to distinguish when a quality has a value that satisfies a
 relational comparison to an exploit. An example application can be seen through CVE-2019-10747, where "set-value is vulnerable to Prototype Pollution in versions lower than 3.0.1" \cite{CVE-2019-10747}. Prior to the implementation
 of relational operators, to determine whether this exploit was applicable to a network state, multiple exploit qualities must be enumerated for all versions prior to 3.0.1. This would mean that the exploit needed to check if 
 \textit{version=3.0.0}, or \textit{version=2.0.0}, or \textit{version=1.0.0}, or \textit{version=0.4.3}, etc. This becomes increasingly tedious when there are many versions, and not only reduces readability, but is also more

Chapter4.tex

@@ -3,8 +3,8 @@
 One main appeal of attack graphs and compliance graphs are their exhaustiveness. The ability to generate all permutations of attack chains or to generate all
 possible ways a system can fall out of compliance is a valuable feature. The disadvantage of this approach is that the generation of the final graph increases
 in time, as does the analysis. One other disadvantage is that this exhaustiveness can produce states that are not actually feasible. When a system has assets that
-have inseperable features, the generation process forcibly seperates features to examine all permutations, since the generation process only modifies one quality at a time. 
-One example of an inseperable feature is time. If two different assets are identical and no constraints dictate othewise, the two assets cannot proceed through times at different rates.
+have inseparable features, the generation process forcibly separates features to examine all permutations, since the generation process only modifies one quality at a time. 
+One example of an inseparable feature is time. If two different assets are identical and no constraints dictate otherwise, the two assets cannot proceed through times at different rates.
 
 For example, if two cars were manufactured at the same
 moment, one of these cars cannot proceed multiple time steps into the future while the other remains at its current time step - each car must step through time at the same rate.
@@ -27,14 +27,14 @@ of this feature, its mentionings in literature, and examine the results when usi
 
 \TUsubsection{Synchronous Firing in Literature}
 Synchronous Firing is discussed by the author of \cite{louthan_hybrid_2011}, where it is described as grouped exploits. The functionality discussed by the author is similar: where
-an exploit should be fired on all possible assets simultaneously. This is also descibred as synchronizing multiple exploits. The methodology is similar to the one implemented in this 
+an exploit should be fired on all possible assets simultaneously. This is also described as synchronizing multiple exploits. The methodology is similar to the one implemented in this 
 work, but there are notable differences. The first, is that the work performed by the author of \cite{louthan_hybrid_2011} utilizes global features with group features. Using the 
 simultaneous exploit firing necessitated a separation of global and group features, and synchronous firing could not be performed on exploits that could be applicable to both sets.
 A second difference is that there is no consistency checking in the work by the author of \cite{louthan_hybrid_2011}, which could lead to indeterminate behavior or race conditions, unless
 additional effort was put into encoding exploits to use precondition guards. A third difference is that the work of \cite{louthan_hybrid_2011} could still lead to a separation of features. The
 behavior of the work would attempt to fire all exploits on all applicable assets simultaneously, but if some assets were not ready or capable to fire, they would not proceed with the exploit firing but
 the other assets would. The last difference is that the work by the author of \cite{louthan_hybrid_2011} was developed in Python, since that was the language of the generator of the tool at the time.
-The work by the author of \cite{cook_rage_2018} led to new development of RAGE in C++ for performance enhancements, so the synchonous firing feature in this new work was likewise developed in C++.
+The work by the author of \cite{cook_rage_2018} led to new development of RAGE in C++ for performance enhancements, so the synchronous firing feature in this new work was likewise developed in C++.
 
 \TUsection{Necessary Components}