65 lines
6.3 KiB
TeX
65 lines
6.3 KiB
TeX
\TUchapter{UTILITY EXTENSIONS TO THE RAGE ATTACK GRAPH GENERATOR}
|
|
|
|
\TUsection{Path Walking}
|
|
\par Due to the large-scale nature of Attack Graphs, analysis can prove difficult and time-consuming. With some networks reaching millions of states and edges,
|
|
analyzing the entire network can be overwhelming complex. As a means of simplifying analysis, a potential strategy could be to consider only small subsets of
|
|
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
|
|
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
|
|
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]
|
|
\includegraphics[width=\linewidth]{"./Chapter3_img/PW.png"}
|
|
\vspace{.2truein} \centerline{}
|
|
\caption{Path Walking to State 14}
|
|
\label{fig:PW}
|
|
\end{figure}
|
|
|
|
\TUsection{Compound Operators}
|
|
Many of the networks previously generated by RAGE compromise of states with features that can be fully enumerated. In many of the generated networks, there is an
|
|
established set of qualities that will be used, with an established set of values. These typically have included $``compliance$\_$vio=true/false"$,
|
|
$``root=true/false"$, or other general $``true/false"$ values or $``version=X"$ qualities. To expand on the types and complexities of networks that can be
|
|
generated, compound operators have been added to RAGE. When updating a state, rather than setting a quality to a specific value, the previous value can now
|
|
be modified by an amount specified through standard compound operators such as $\mathrel{+}=$, $\mathrel{-}=$, $\mathrel{*}=$, or $\mathrel{/}=$.
|
|
|
|
The work conducted by the author of \cite{cookrage2018} when designing the software architecture included specifications for a quality encoding scheme. As the
|
|
author discusses, qualities have four fields, which include the asset ID, attributes, operator, and value. The operator field is 4 bits, which allows for a total
|
|
of 16 operators. Since the only operator in use at the time was the $``\mathrel{=}"$ operator, the addition of four compound operators does not surpass the 16 operator limit,
|
|
and no encoding scheme changes were necessary. This also allows for additional compound operators to be incorporated in the future.
|
|
|
|
A few changes were necessary to allow for the addition of compound operators. Before the generation of an Attack Graph begins, all values are stored in a hash
|
|
table. For previous networks generated by RAGE, this was not a difficulty, since all values could be fully enumerated and all possible values were known. When
|
|
using compound operators however, not all values can be fully known. The concept of approximating which exploits will be applicable and what absolute minimum
|
|
or maximum values will be prior to generation is a difficult task, so not all values can be enumerated and stored into the hash table. As a result, on-the-fly
|
|
updates to the hash table needed to be added to the generator. The original key-value scheme for hash tables relied on utilizing the size of the hash table for
|
|
values. Since the order in which updates happen may not always remain consistent (and is especially true in distributed computing environments), it is possible
|
|
for states to receive different hash values with the original hashing scheme. To prevent this, the hashing scheme was adjusted so that the new value of the
|
|
compound operator is inserted into the hash table values if it was not found, rather than the size of the hash table. Previously, there was no safety check
|
|
for the hash table, so if the value was not found, the program would end execution. The assumption that this value can be inserted into the hash table is safe
|
|
to make, since compound operators are conducted on numeric values, and matches the numeric type of the hash table.
|
|
|
|
\TUsection{Color Coding}
|
|
As a visual aid for analysis purposes, color coding was another feature implemented as a postprocessing tool for RAGE. When viewing the output graph of RAGE, all states are
|
|
originally identical in appearance, apart from number of edges, edge IDs, and state IDs. To allow for visual differentiation, color coding can be enabled in the run script.
|
|
Color coding currently functions by working through the graph output text file, but it can be extended to read directly from Postgres instead. The feature scans through the
|
|
output file, and locates states that have $``compliance$\_$vios = X"$ (where \textit{X} is a number greater than 0), or $``compliance$\_$vio = true"$. For states that meet these
|
|
properties, the color coding feature will add a color to the graphviz DOT file through the $[color=COL]$ attribute for the given node, where \textit{COL} is assigned based on severity.
|
|
For this version of color coding, severity is determined by the total number of compliance violations, but future versions can alter the severity measure through alternative means.
|
|
Figure \ref{fig:CC} displays an example graph that leverages color coding to easily identify problem states.
|
|
\begin{figure}[htp]
|
|
\includegraphics[width=\linewidth]{"./Chapter3_img/CC.png"}
|
|
\vspace{.2truein} \centerline{}
|
|
\caption{Color Coding a Small Network Based on Violations}
|
|
\label{fig:CC}
|
|
\end{figure}
|
|
|
|
\TUsection{Intermediate Database Storage} Fourth section of the third chapter.
|
|
|
|
\TUsection{Relational Operators} Fifth section of the third chapter.
|
|
|