Conclusions

Chapter3.tex

@@ -1,6 +1,6 @@
 \TUchapter{UTILITY EXTENSIONS TO THE RAGE ATTACK GRAPH GENERATOR}
 
-\TUsection{Path Walking}
+\TUsection{Path Walking} \label{sec:PW}
 \par Due to the large-scale nature of attack graphs, analysis can become difficult and time-consuming. With some graphs reaching millions of states and edges, 
 analyzing the entire graph can be overwhelmingly complex. As a means of simplifying analysis, a potential strategy could be to consider only small subsets of
 the graph at a time, rather than feeding the entire graph into an analysis algorithm. To aid in this effort, a path walking feature was implemented as a
@@ -111,7 +111,7 @@ performance benefits of memory operations, since graph computation relies less o
  request option), and the intermediate database storage process would function in the same fashion.
 
 
-\TUsection{Relational Operators}
+\TUsection{Relational Operators} \label{sec:relops}
 As discussed in Section \ref{sec:compops}, many of the graphs previously generated by RAGE comprise 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 graph generation, it is important to distinguish when a quality has a value that satisfies a
 relational comparison to an exploit. An example application for attack graphs 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}. An example compliance graph application using the aforementioned car example can be seen in the Toyota Corolla Maintenance Schedule, which states an engine coolant replacement should be conducted after 24,000 miles. Prior to the implementation

Chapter4.tex

@@ -1,4 +1,4 @@
-\TUchapter{SYNCHRONOUS FIRING}
+\TUchapter{SYNCHRONOUS FIRING} \label{ch:Sync-Fire}
 \TUsection{Introduction}
 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
@@ -115,7 +115,7 @@ The testing information is as follows:
 \item{Graph visualization was not timed. Only the generation and database operation time was measured.}
 \end{itemize}
 
-\TUsubsection{Results}
+\TUsubsection{Results} \label{sec:Sync-Results}
 Using the testing setup described in Section \ref{sec:Sync-Test} on the platform described at the beginning of Section \ref{sec:test-platform}, results were collected in regards to the effect of synchronous firing on both state space and runtime. These results can be seen in Figures \ref{fig:Sync-RT} and \ref{fig:Sync-State}. Both figures depict a decrease in the number of states and a decrease in the runtime when synchronous firing is utilized. Since synchronous firing prevents the generation of unattainable states, there is no meaningful information loss that occurs in the graphs generated with the synchronous firing feature. It is also noteworthy that even for the smallest graph generated (which only resulted in 394 states with synchronous firing enabled), the computation cost of additional work for group vectors was justified by the decrease in runtime. Since the resulting number of states was also reduced, there will be increased justification for the synchronous firing approach due to a reduced runtime for the analysis process. Further elaboration is seen in Section \ref{sec:FW}, but it is hypothesized that the synchronous firing approach will lead to an increased runtime reduction and state space reduction when more assets exist in the network due to the increased number of unattainable state permutations.
 
 \begin{figure} 

Chapter5.tex

@@ -1,4 +1,4 @@
-\TUchapter{Utilization OF MESSAGE PASSING INTERFACE}
+\TUchapter{Utilization OF MESSAGE PASSING INTERFACE} \label{ch:MPI}
 
 \TUsection{Introduction to MPI Utilization for Attack and Compliance Graph Generation}
 Previous works for graph generation, and specifically for attack graph generation, have seen promising results as discussed in Sections \ref{sec:gen_improv} and \ref{sec:related_works}. This work attempts to further those efforts and extend RAGE to function on distributed computing environments to take advantage of the increased computing power using message-passing. As mentioned by the author of \cite{pacheco_introduction_2011}, MPI is the most widely used message-passing API, and this work intended to utilize an API that was not only familiar and accessible, but versatile and powerful for parallelizing RAGE for distributed computing platforms. This Chapter discusses two approaches for parallelism: task parallelism in Section \ref{sec:Tasking-Approach}, and data parallelism in Section \ref{sec:Subgraphing_Approach}.
@@ -130,7 +130,7 @@ To ensure that the intended message is received by each node, the MPI message en
 \TUsubsection{Performance Expectations and Use Cases} \label{Task-perf-expec}
 Due to the amount of communication between nodes to distribute the necessary data through all stages of the tasking pipeline, this approach is not expected to outperform the serial approach in all cases. This tasking approach was specifically designed to reduce the computation time when the generation of each individual state increases in time. This approach does not offer any guarantees of processing through the frontier at an increased rate; it's main objective is to distribute the workload of individual state generation. As discussed in Section \ref{sec:Intro}, the amount of entries in the National Vulnerability database and any custom vulnerability testing to ensure adequate examination of all assets in the network sums to large number of exploits in the exploit list. Likewise for compliance graphs and compliance examinations, Section \ref{sec:CG-diff} discussed that the number of compliance checks for SOX, HIPAA, GDPR, PCI DSS, and/or any other regulatory compliance also sums to a large number of compliance checks in the exploit list. Since the generation of each state is largely dependent on the number of exploits present in the exploit list, this approach is best-suited for when the exploit list grows in size. As will be later discussed, it is also hypothesized that this approach is well-suited when many database operations occur.
 
-\TUsubsection{Results}
+\TUsubsection{Results} \label{sec:Tasking-Results}
 A series of tests were conducted on the platform described at the beginning of Section \ref{sec:test-platform}, and results were collected in regards to the effect of the MPI Tasking approach on increasing sizes of exploit lists for a varying number of nodes. The exploit list initially began with 6 items, and each test scaled the number of exploits by a factor of 2. The final test was with an exploit list with 49,512 entries. If all of the items in these exploit lists were applicable, the runtime would be too great for feasible testing due to the state space explosion. To prevent state-space explosion but still gather valid results, each exploit list in the tests contained 6 exploits that could be applicable, and all remaining exploits were not applicable. The not applicable exploits were created in a fashion similar to that seen in Figure \ref{fig:NA-exp}. By creating a multitude of not applicable exploits, testing can safely be conducted by ensuring state space explosion would not occur while still observing the effectiveness of the tasking approach.
 
 The results of the Tasking Approach can be seen in Figure \ref{fig:Spd-Eff-Task}. In terms of speedup, when the number of entries in the exploit list is small, the serial approach has better performance. This is expected due to the communication cost requiring more time than it does to generate a state, as discussed in Section \ref{sec:Task-perf-expec}. However, as the number of items in the exploit list increase, the Tasking Approach quickly begins to outperform the serial approach. It is notable that even when the tasking pipeline is not fully saturated (when there are less compute nodes assigned than tasks), the performance is still approximately equal to that of the serial approach. The other noticeable feature is that as more compute nodes are assigned, the speedup continues to increase.
@@ -212,7 +212,7 @@ Similar to Section \ref{sec:tasking-tag} that discussed the usage of MPI Tags fo
 \TUsubsection{Performance Expectations and Use Cases} \label{sec:perf_expec_subg}
 This approach is intended to reduce runtime when the frontier grows at a rate faster than it can be explored. However, since this approach is designed for distributed systems, there is no guarantee that speedup can be achieved when duplicate work is performed. Not only is there wasted time by the worker nodes when duplicate work occurs, but duplicate work also contributes to increased communication between nodes to adequately explore the graph, and also leads to an increased number of merging calls by the root node. The ideal scenario for the subgraphing approach is when the graph is sparse, and the graph aligns more with a N-Ary tree structure where each node only has one parent. When the graph is sparse, there is a lower likelihood of duplicate work occurring, since worker nodes have a lower probability of exploring a graph state that connects to a different graph state that has been (or will be) explored by another worker node. If each graph state was able to have only one parent, there is a lower likelihood that worker nodes would explore the same graph cluster.
 
-\TUsubsection{Results}
+\TUsubsection{Results} \label{sec:Subgraphing-Results}
 A series of tests were conducted on the platform described at the beginning of Section \ref{sec:test-platform}, and results were collected in regards to the effect of the MPI Subgraphing approach on the 4 example networks discussed in \ref{sec:Sync-Test}. All tests used synchronous firing. The initial results are seen in Figure \ref{fig:Subg_base}, which displays the results in terms of their runtimes. Only the serial runtime from the 2 Service test is displayed for conciseness.  The results in terms of speedup and efficiency are seen in Figure \ref{fig:Subg_SE}.
  
 \begin{figure}[htp]

Chapter6.tex

@@ -1,4 +1,13 @@
 \TUchapter{CONCLUSIONS AND FUTURE WORKS}
+\TUsection{Conclusions}
+This thesis presented various extensions to an attack graph generator, RAGE, to allow for a broader range of utilities. In order to reduce the complexity required for network model and exploit file creations, Sections \ref{sec:compops} and \ref{sec:relops} discussed the implementation of relational and compound operators. Both implementations simplify the amount of manual enumeration or manual specifications of asset qualities, and simplifies checks to singular lines. In addition, these implementations reduce the complexity required for synchronous firing exploit creations by avoiding the need for (for instance) time flags and enumeration of time all time instances. These sections also allow for more complex attack modeling, since broad sweeps and generic \gt or \lt checks can be performed. Due to the intermediate database storage feature presented in Section \ref{sec:db-stor}, very large attack or compliance graphs can be generated without fear of memory consumption, assuming very large storage solutions are in place. Section \ref{sec:PW} discusses the path walking feature, which is able to split attack and compliance graphs into subgraphs that can be used to simplify the analysis process by examining only smaller portions or focus areas of a network at a time.
+
+Chapter \ref{ch:Sync-Fire} presents the synchronous firing feature, which is successfully able to reduce the state space and runtime of the generation process when assets have inseparable features. This feature does not lose any substantive information from a graph, and the graph is able to remain exhaustive and still capture all necessary information. The results are promising, and greater reductions are expected when a greater number of assets share inseparable features, as discussed in Section \ref{sec:FW}.
+
+Chapter \ref{ch:MPI} presented two approaches for utilizing MPI for extension to the distributed computing platform space. One approach was a task parallelism approach discussed in Section \ref{sec:MPI-Tasking}, and promising results were observed as the generation of each state increased in computation requirements. The second approach was a data parallelism approach discussed in Section \ref{sec:MPI_Subgraphing}. While results were not promising for this approach, future works can be conducted to optimize and avoid the difficulties of duplicate work and communication overhead.
+
+Throughout this thesis and its works, RAGE has demonstrated its extensions to support compliance graph generation. Section \ref{sec:CG-alter} discussed the alterations required for attack graph generators to support compliance graphs, and example compliance graphs have been generated in the results seen in Sections \ref{sec:Sync-Results}, \ref{sec:Tasking-Results}, and \ref{sec:Subgraphing-Results}.
+
 
 \TUsection{Future Work} \label{sec:FW}
 %Sync Fire more assets