46 lines
4.7 KiB
TeX
46 lines
4.7 KiB
TeX
\TUchapter{SYNCHRONOUS FIRING}
|
|
\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
|
|
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 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.
|
|
However, the generation of attack graphs and compliance graphs examines the possibilities that one car ages by one time step, while the other car does not, or vice versa. This results in an attack graph
|
|
that can be seen in Figure \ref{fig:non-sync_ex}, which is a partial attack graph showing the separation of the time feature. All states shaded as a light red color are considered
|
|
infeasible, since all of these states comprise of assets that have advanced time at different rates. It is noticeable that not only are the infeasible states a wasteful generation,
|
|
but that they also lead to the generation of even more infeasible states that will then also be explored. The desired goal of a generation process similar to this is to have a single state transition that updates
|
|
assets with an inseparable feature simultaneously.
|
|
\begin{figure}[htp]
|
|
\includegraphics[width=\linewidth]{"./Chapter4_img/non-sync_ex.drawio.png"}
|
|
\vspace{.2truein} \centerline{}
|
|
\caption{A network without Synchronous Firing generating infeasible states}
|
|
\label{fig:non-sync_ex}
|
|
\end{figure}
|
|
|
|
Post-processing is one option at removing the infeasible states. This process would simplify and reduce the time taken for the analysis process, but the generation process would still suffer
|
|
from generating infeasible states, as well as exploring the infeasible states. Instead, a new approach called Synchronous Firing can be used to prevent the generation of infeasible states.
|
|
The goal of the Synchronous Firing feature is to prevent the generation of infeasible states, while also not incurring a greater computational cost. This Chapter will discuss the development
|
|
of this feature, its mentionings in literature, and examine the results when using this feature in applicable networks.
|
|
|
|
\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 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 synchronous firing feature in this new work was likewise developed in C++.
|
|
|
|
\TUsection{Necessary Components}
|
|
|
|
\TUsection{Example Networks and Results}
|
|
\TUsubsection{Example Networks}
|
|
|
|
\TUsubsection{Results}
|
|
|