\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 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.

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 descibred 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++.

\TUsection{Necessary Components}

\TUsection{Example Networks and Results}
\TUsubsection{Example Networks}

\TUsubsection{Results}

