97 lines
10 KiB
TeX
97 lines
10 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} \label{sec:sync-lit}
|
|
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 Alterations}
|
|
For the implementation of the Synchronous Fire Feature, there are four primary changes and/or additions necessary. The first is a change in the lexical analyzer, the second involves multiple changes
|
|
to PostgreSQL, the third is the implementation of compound operators (as discussed in Section \ref{sec:compops}), and lastly is a change in the graph generation process. This section will
|
|
compromise of subsections discussing the development of these four alterations.
|
|
|
|
\TUsubsection{GNU Bison and Flex}
|
|
The work conducted by the author of \cite{cook_rage_2018} included the introduction of GNU Bison and GNU Flex into RAGE. The introduction of Bison and Flex allows for an easily modifiable grammar to
|
|
adjust features, the ability to easily update parsers since Bison and Flex are built into the build system, and increases portability since Flex and Bison generate standard C. For the development of
|
|
the synchronous fire, a similar approach was taken to that of the work performed by the author of \cite{louthan_hybrid_2011} with the exploit keywords. However, rather than having both global and group
|
|
keywords, this work only incorporates the group keyword to prevent a few of the difficulties discussed in Section \ref{sec:sync-lit}. The new ``group" keyword is intended to be used when creating the
|
|
exploit files. The design of exploits in the exploit file is developed as: \begin{verbatim} <exploit> ::= <group name> "group" "exploit" <identifier> , (<parameter-list>)= \end{verbatim} where the
|
|
``$<$group name$>$" identifier
|
|
and ``group" keyword is optional. An example of an exploit not utilizing the group feature is: \begin{verbatim}exploit brake_pads(2015_Toyota_Corolla_LE)=\end{verbatim} and an example of an exploit utilizing the group feature is:
|
|
\begin{verbatim}time group exploit advance_month(all_applicable)=\end{verbatim}
|
|
|
|
To implement this feature, a few changes were conducted, where the intention is to detect the usage of the ``group" keyword, and have the lexical analyzer code return to the parser implementation file to
|
|
alert of the presence of the "GROUP" token. The new token is of type string with the name GROUP, and it is comprised of a leading ``IDENTIFIER" of type string or integer token, followed by the GROUP token.
|
|
This new token also required changes to the processing of the ``exploit" keyword. If the group keyword is not detected, the exploit has a group of name ``null". If the group keyword is detected, then the
|
|
leading IDENTIFIER is parsed, and the exploit is assigned to a group with the parsed name. Various auxiliary functions were also adjusted to include (for instance) support for printing the groups of each
|
|
exploit. Figure \ref{fig:bison-flex} illustrates the incorporation of this feature into Bison, Flex, and the overall program.
|
|
|
|
\begin{figure}[htp]
|
|
\includegraphics[width=\linewidth]{"./Chapter4_img/Bison-Flex.png"}
|
|
\vspace{.2truein} \centerline{}
|
|
\caption{Inclusion of Synchronous Firing into GNU Bison, GNU Flex, and the overall program}
|
|
\label{fig:bison-flex}
|
|
\end{figure}
|
|
|
|
\TUsubsection{PostgreSQL}
|
|
As seen in Figure \ref{fig:bison-flex}, Bison and Flex feed into the Model Database. With the addition of a new group identifier and the group keyword, minor alterations were needed to ensure compatibility
|
|
with the PostgreSQL database. One adjustment was to alter the exploit table in the SQL schema to include new columns of type ``TEXT". The second adjustment was to update the SQL builder functions. This
|
|
included updating the related functions such as exploit creations, exploit parsing, database fetching, and SQL string builders to add additional room for the group identifier.
|
|
|
|
\TUsubsection{Compound Operators}
|
|
While not strictly necessary, compound operators greatly simplify the exploit file creation process.For example, implementing time as a feature into the tool without compound operators would increase its difficulty substantially. For each time
|
|
interval, a separate exploit would need to be created, with time flags to indicate the current
|
|
time. If time was increased monthly for a year, 12 different exploits would need to
|
|
be created, with flags to ensure that time jumps did not occur. Updating qualities without
|
|
compound operators also relied on flags, and clever, but convoluted methods for incrementing
|
|
values. Instead, compound operators were implemented, and this addition was discussed in Section \ref{sec:compops}.
|
|
|
|
\TUsubsection{Graph Generation}
|
|
The implementation of synchronous firing in the graph generation process relies on a map to hold the fired status of groups. Previously, each iteration of the applicable exploit vector loop generated a new state. With synchronous firing, all assets should be updating the same state, rather than each independently creating a new state. To implement this, each iteration of the applicable exploit vector checks if the element is in a group and if that group has fired. If the element is in a group, the group has not been fired, and all group members are ready to fire, then all group members will loop through an update process to alter the single converged state. Otherwise, the loop will either continue to the next iteration if group conditions are not met, or will create a single state if it is not in a group. Figure \ref{fig:sync-fire} displays the synchronous fire approach.
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\includegraphics[scale=0.5]{"./Chapter4_img/Sync-Fire.png"}
|
|
\vspace{.2truein} \centerline{}
|
|
\caption{Synchronous Firing in the Graph Generation Process}
|
|
\label{fig:sync-fire}
|
|
\end{figure}
|
|
|
|
|
|
\TUsection{Example Networks and Results}
|
|
\TUsubsection{Example Networks}
|
|
|
|
\TUsubsection{Results}
|
|
|