noah/Synchronous_Firing
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Formatting, new table columns (skele), super to comprehensive

Browse Source
This commit is contained in:
Noah L. Schrick 2022-10-06 22:16:10 -05:00
parent 762bef9e05
commit 7208563895
4 changed files with 93 additions and 121 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Schrick-Noah_AG-CG-SyncFire.aux
View File

@ -94,10 +94,10 @@
\bibstyle{ieeetr}
\@writefile{lot}{\contentsline {table}{\numberline {II}{\ignorespaces Tabled Results for the Synchronous Firing Testing}}{7}{table.2}\protected@file@percent }
\newlabel{table:S-Table}{{II}{7}{Tabled Results for the Synchronous Firing Testing}{table.2}{}}
\@writefile{lot}{\contentsline {table}{\numberline {III}{\ignorespaces Tabled Results for the Super Services with Synchronous Firing}}{7}{table.3}\protected@file@percent }
\newlabel{table:Sync-Super-Table}{{III}{7}{Tabled Results for the Super Services with Synchronous Firing}{table.3}{}}
\@writefile{lot}{\contentsline {table}{\numberline {III}{\ignorespaces Tabled Results for the Comprehensive Services with Synchronous Firing}}{7}{table.3}\protected@file@percent }
\newlabel{table:Sync-Comp-Table}{{III}{7}{Tabled Results for the Comprehensive Services with Synchronous Firing}{table.3}{}}
\@writefile{toc}{\contentsline {section}{\numberline {VII}Conclusion}{7}{section.7}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{References}{7}{section*.1}\protected@file@percent }
\@writefile{lot}{\contentsline {table}{\numberline {IV}{\ignorespaces Tabled Results for the Super Services without Synchronous Firing}}{7}{table.4}\protected@file@percent }
\newlabel{table:Non-Sync-Super-Table}{{IV}{7}{Tabled Results for the Super Services without Synchronous Firing}{table.4}{}}
\@writefile{lot}{\contentsline {table}{\numberline {IV}{\ignorespaces Tabled Results for the Comprehensive Services without Synchronous Firing}}{7}{table.4}\protected@file@percent }
\newlabel{table:Non-Sync-Comp-Table}{{IV}{7}{Tabled Results for the Comprehensive Services without Synchronous Firing}{table.4}{}}
\gdef \@abspage@last{7}

8
Schrick-Noah_AG-CG-SyncFire.log
View File

@ -1,4 +1,4 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Arch Linux) (preloaded format=pdflatex 2022.4.29) 5 OCT 2022 10:04
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Arch Linux) (preloaded format=pdflatex 2022.4.29) 6 OCT 2022 21:41
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@ -685,8 +685,8 @@ nged.
)
Here is how much of TeX's memory you used:
12135 strings out of 478238
192699 string characters out of 5850456
521523 words of memory out of 5000000
192697 string characters out of 5850456
521539 words of memory out of 5000000
30147 multiletter control sequences out of 15000+600000
509014 words of font info for 103 fonts, out of 8000000 for 9000
1141 hyphenation exceptions out of 8191
@ -700,7 +700,7 @@ t/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-dist/fonts/type1/urw/tim
es/utmb8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb></usr/sh
are/texmf-dist/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-dist/fonts/ty
pe1/urw/times/utmri8a.pfb>
Output written on Schrick-Noah_AG-CG-SyncFire.pdf (7 pages, 576705 bytes).
Output written on Schrick-Noah_AG-CG-SyncFire.pdf (7 pages, 576743 bytes).
PDF statistics:
253 PDF objects out of 1000 (max. 8388607)
205 compressed objects within 3 object streams

BIN
Schrick-Noah_AG-CG-SyncFire.pdf
View File

Binary file not shown.

198
Schrick-Noah_AG-CG-SyncFire.tex
View File

@ -1,6 +1,7 @@
\documentclass[conference]{IEEEtran}
\IEEEoverridecommandlockouts
% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
\usepackage{cite}
\usepackage{amsmath,amssymb,amsfonts}
\usepackage{algorithmic}
@ -29,17 +30,24 @@
\title{State Space Explosion Mitigation for Large-Scale Attack and Compliance Graphs Using Synchronous Exploit Firing
}
\author{\IEEEauthorblockN{Noah L. Schrick}
\IEEEauthorblockA{\textit{Tandy School of Computer Science} \\
\textit{The University of Tulsa}\\
Tulsa, USA \\
noah-schrick@utulsa.edu}
\and
\IEEEauthorblockN{Peter J. Hawrylak}
\IEEEauthorblockA{\textit{Tandy School of Computer Science} \\
\textit{The University of Tulsa}\\
Tulsa, USA \\
peter-hawrylak@utulsa.edu}
\author{
\IEEEauthorblockN{Noah L. Schrick}
\IEEEauthorblockA{
\textit{Tandy School of Computer Science} \\
\textit{The University of Tulsa}\\
Tulsa, USA \\
noah-schrick@utulsa.edu
}
\and
\IEEEauthorblockN{Peter J. Hawrylak}
\IEEEauthorblockA{
\textit{Tandy School of Computer Science} \\
\textit{The University of Tulsa}\\
Tulsa, USA \\
peter-hawrylak@utulsa.edu
}
}
\maketitle
@ -53,55 +61,37 @@ Attack Graph; Compliance Graph; Synchronous Firing; High-Performance Computing;
\end{IEEEkeywords}
\section{Introduction}
Cybersecurity has been at the forefront of computing for decades, and vulnerability analysis modeling has been utilized to mitigate threats to aid in this effort. One such modeling approach
is to represent a system or a set of systems through graphical means, and encode information into the nodes and edges of the graph. Even as early as the late 1990s,
experts have composed various graphical models to map devices and vulnerabilities through attack trees, and this work can be seen through the works published by the authors of \cite{phillips_graph-based_1998}.
This work, and other attack tree discussions of this time such as that conducted by the author of \cite{schneier_modeling_1999}, would later be referred to as early versions of modern-day attack graphs
\cite{ou_scalable_2006}. By utilizing this graphical approach, cybersecurity postures can be measured at a system's current status, as well as hypothesize and examine other postures based on system changes
over time.
Cybersecurity has been at the forefront of computing for decades, and vulnerability analysis modeling has been utilized to mitigate threats to aid in this effort. One such modeling approach is to represent a system or a set of systems through graphical means, and encode information into the nodes and edges of the graph. Even as early as the late 1990s, experts have composed various graphical models to map devices and vulnerabilities through attack trees, and this work can be seen through the works published by the authors of \cite{phillips_graph-based_1998}.
This work, and other attack tree discussions of this time such as that conducted by the author of \cite{schneier_modeling_1999}, would later be referred to as early versions of modern-day attack graphs \cite{ou_scalable_2006}.
By utilizing this graphical approach, cybersecurity postures can be measured at a system's current status, as well as hypothesize and examine other postures based on system changes over time.
As an alternative to attack graphs for examining vulnerable states and measuring cybersecurity postures, the focus can be narrowed to generate graphs with the purpose of examining compliance or regulation statuses.
These graphs are known as compliance graphs. Compliance graphs can be especially useful for cyber-physical systems, where a greater need for compliance exists. As the authors of \cite{j_hale_compliance_nodate},
\cite{baloyi_guidelines_2019}, and \cite{allman_complying_2006} discuss, cyber-physical systems have seen greater usage, especially in areas such as critical infrastructure and Internet of Things. The challenge of
cyber-physical systems lies not only in the demand for cybersecurity of these systems, but also the concern for safe, stable, and undamaged equipment. The industry in which these devices are used can lead to
additional compliance guidelines that must be followed, increasing the complexity required for examining compliance statuses. Compliance graphs are promising tools that can aid in minimizing the overhead caused by these systems and the regulations they must follow.
As an alternative to attack graphs for examining vulnerable states and measuring cybersecurity postures, the focus can be narrowed to generate graphs with the purpose of examining compliance or regulation statuses. These graphs are known as compliance graphs.
Compliance graphs can be especially useful for cyber-physical systems, where a greater need for compliance exists. As the authors of \cite{j_hale_compliance_nodate}, \cite{baloyi_guidelines_2019}, and \cite{allman_complying_2006} discuss, cyber-physical systems have seen greater usage, especially in areas such as critical infrastructure and Internet of Things. The challenge of
cyber-physical systems lies not only in the demand for cybersecurity of these systems, but also the concern for safe, stable, and undamaged equipment.
The industry in which these devices are used can lead to additional compliance guidelines that must be followed, increasing the complexity required for examining compliance statuses. Compliance graphs are promising tools that can aid in minimizing the overhead caused by these systems and the regulations they must follow.
Attack graphs are an appealing approach since they are often designed to be exhaustive: all system properties are represented at its initial state, all attack options are fully enumerated, all permutations are
examined, and all changes to a system are encoded into their own independent states, where these states are then individually analyzed through the process. The authors of \cite{sheyner_automated_2002} also
discuss the advantage of conciseness of attack graphs, where the final graph only incorporates states that an attacker can leverage; no superfluous states are generated that can clutter analysis. Despite their
advantages, attack graphs do suffer from their exhaustiveness as well. As the authors of \cite{ou_scalable_2006} examine, even very small networks with only 10 hosts and 5 vulnerabilities yield graphs with 10 million
edges.
When scaling attack graphs to analyze the modern, interconnected state of large networks comprising of a multitude of hosts, and utilizing the entries located in the National Vulnerability Database and any
custom vulnerability testing, attack graph generation quickly becomes infeasible. Similar difficulties arise in related fields, where social networks, bioinformatics, and neural network representations result in graphs with millions of
states \cite{zhang_boosting_2017}. This state space explosion is a natural by-product of the graph generation process, and removing or avoiding it entirely undermines the overall goal of attack and compliance graphs. However, there are some scenarios in which the state space explosion can be mitigated when certain features are inseparable. This work discusses the application of synchronous exploit firing which mitigates state space explosion for applicable scenarios, and discusses the results of its use.
Attack graphs are an appealing approach since they are often designed to be exhaustive: all system properties are represented at its initial state, all attack options are fully enumerated, all permutations are examined, and all changes to a system are encoded into their own independent states, where these states are then individually analyzed through the process. The authors of \cite{sheyner_automated_2002} also discuss the advantage of conciseness of attack graphs, where the final graph only incorporates states that an attacker can leverage; no superfluous states are generated that can clutter analysis.
Despite their advantages, attack graphs do suffer from their exhaustiveness as well. As the authors of \cite{ou_scalable_2006} examine, even very small networks with only 10 hosts and 5 vulnerabilities yield graphs with 10 million edges. When scaling attack graphs to analyze the modern, interconnected state of large networks comprising of a multitude of hosts, and utilizing the entries located in the National Vulnerability Database and any custom vulnerability testing, attack graph generation quickly becomes infeasible.
Similar difficulties arise in related fields, where social networks, bioinformatics, and neural network representations result in graphs with millions of states \cite{zhang_boosting_2017}.
This state space explosion is a natural by-product of the graph generation process, and removing or avoiding it entirely undermines the overall goal of attack and compliance graphs. However, there are some scenarios in which the state space explosion can be mitigated when certain features are inseparable. This work discusses the application of synchronous exploit firing which mitigates state space explosion for applicable scenarios, and discusses the results of its use.
\section{Related Work} \label{sec:sync-lit}
Multiple works have introduced various approaches for mitigating state space explosion. The authors of \cite{Monotonicity} propose that attack graphs encapsulate excessive information that lead to difficulties in scalability. They discuss the concept of monotonicity, where attackers do not need to backtrack. If a previous exploit was achieved, its preconditions and postconditions should not be revoked through another, future exploit firing. The authors of \cite{TVA} use monotonicity in their tool, TVA, along with various node and edge representations based on sets and dependency graphs that can likewise mitigate the state space explosion challenge. The authors of \cite{ou_scalable_2006} also take the approach of using alternate representations of the underlying graph structure through logical attack graphs. In this representation, each node only encompasses a portion of the network in a logical statement format, as opposed to encoding the entire system information at each node. This approach is able to limit the total number of nodes to O$(N^2$), with \textit{N} representing the total number of nodes in the system.
A form of 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: firing
an exploit should be performed on all possible assets simultaneously. This was 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 grouped exploits 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
grouped exploit feature would attempt to fire all exploits on all applicable assets simultaneously, but if some assets were not ready or capable to fire, these assets would not proceed with the exploit firing but
the applicable 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.
This work relies on RAGE (The RAGE Attack Graph Engine) for the feature development and result collection \cite{cook_rage_2018}. RAGE is developed in C++ for performance enhancements, so the synchronous firing feature in this new work was likewise developed in C++.
A form of 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: firing an exploit should be performed on all possible assets simultaneously. This was 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 grouped exploits 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 grouped exploit feature would attempt to fire all exploits on all applicable assets simultaneously, but if some assets were not ready or capable to fire, these assets would not proceed with the exploit firing but the applicable 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. This work relies on RAGE (The RAGE Attack Graph Engine) for the feature development and result collection \cite{cook_rage_2018}. RAGE is developed in C++ for performance enhancements, so the synchronous firing feature in this new work was likewise developed in C++.
\section{Inseparable Features} \label{sec:inseparable}
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 attainable or realistic, as briefly mentioned in Section \ref{sec:sync-lit}. 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 should not, and realistically cannot, proceed through time at different rates.
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 attainable or realistic, as briefly mentioned in Section \ref{sec:sync-lit}. 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 should not, and realistically cannot, proceed through time 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 shaded states are considered unattainable, since all of these states comprise of assets that have advanced time at different rates. It is noticeable that not only are the unattainable states themselves a wasteful generation, but they also lead to the generation of even more unattainable states that will then also be explored.
A better procedure for a generation process similar to this example is to have a single state transition that updates assets with an inseparable feature simultaneously.
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 shaded states are considered
unattainable, since all of these states comprise of assets that have advanced time at different rates. It is noticeable that not only are the unattainable states themselves a wasteful generation,
but they also lead to the generation of even more unattainable states that will then also be explored. A better procedure for a generation process similar to this example is to have a single state transition that updates
assets with an inseparable feature simultaneously.
\begin{figure}[htp]
\includegraphics[width=\linewidth]{"./images/non-sync_ex.drawio.png"}
\vspace{.2truein} \centerline{}
@ -109,25 +99,17 @@ assets with an inseparable feature simultaneously.
\label{fig:non-sync_ex}
\end{figure}
Post-processing is one option at removing the unattainable states. This process would simplify and reduce the time taken for the analysis process, but the generation process would still suffer
from generating and exploring the unattainable states, and would still need to go through a post-processing step. Instead, a new feature called synchronous firing can be used to prevent the generation of these states.
The goal of the synchronous firing feature is to prevent the generation of unattainable states, while also not incurring a greater computational cost. Section \ref{sec:implementing} will discuss the development
of this feature, and Section \ref{sec:Results} will examine the results when using this feature in applicable networks.
Post-processing is one option at removing the unattainable states. This process would simplify and reduce the time taken for the analysis process, but the generation process would still suffer from generating and exploring the unattainable states, and would still need to go through a post-processing step.
Instead, a new feature called synchronous firing can be used to prevent the generation of these states. The goal of the synchronous firing feature is to prevent the generation of unattainable states, while also not incurring a greater computational cost. Section \ref{sec:implementing} will discuss the development of this feature, and Section \ref{sec:Results} will examine the results when using this feature in applicable networks.
\section{Implementing Synchronous Firing} \label{sec:implementing}
\subsection{Base Generator Description}
For the implementation of the synchronous firing feature, there were four primary changes and additions that were 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, and lastly is a change in the graph generation process. This Section will
consist of subsections discussing the development of these four alterations.
For the implementation of the synchronous firing feature, there were four primary changes and additions that were 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, and lastly is a change in the graph generation process. This Section will consist of subsections discussing the development of these four alterations.
\subsection{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 firing feature, 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:
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 firing feature, 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{spverbatim} <exploit> ::= <group name> "group"
"exploit" <identifier> ,
(<parameter-list>)= \end{spverbatim}
@ -143,11 +125,9 @@ and an example of an exploit utilizing the group feature is:
advance_month(all_applicable)=\end{spverbatim}
\\
\\
To implement the keyword recognition and group name parsing, a few changes were made, where the intention was 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.
To implement the keyword recognition and group name parsing, a few changes were made, where the intention was 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]{"./images/vert_Bison-Flex.drawio.png"}
@ -158,32 +138,19 @@ exploit. Figure \ref{fig:bison-flex} illustrates the incorporation of this featu
\subsection{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.
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.
\subsection{Compound Operators}
Many of the graphs previously generated by RAGE comprise of states with features that can be fully enumerated. In many of these generated graphs, there was an
established set of qualities that was 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 graphs that can be
generated and to allow for synchronous firing, 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{/}=$. Previous work on an attack graph generator included the implementation of compound operators, as seen by the author of \cite{nichols_2018}. However, this work was conducted on the previous iteration of an attack graph generator written in Python. This attack graph generator has since been rewritten in C++ by the author of \cite{cook_rage_2018}, and compound operators have not been included in the latest version of RAGE.
Many of the graphs previously generated by RAGE comprise of states with features that can be fully enumerated. In many of these generated graphs, there was an established set of qualities that was 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 graphs that can be generated and to allow for synchronous firing, 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{/}=$.
Previous work on an attack graph generator included the implementation of compound operators, as seen by the author of \cite{nichols_2018}. However, this work was conducted on the previous iteration of an attack graph generator written in Python. This attack graph generator has since been rewritten in C++ by the author of \cite{cook_rage_2018}, and compound operators were not included in the latest version of RAGE.
The work conducted by the author of \cite{cook_rage_2018} when designing the software architecture of RAGE 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.
The work conducted by the author of \cite{cook_rage_2018} when designing the software architecture of RAGE 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 concern 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 task of approximating which exploits will be applicable and what absolute minimum
or maximum value bounds will be prior to generation is difficult, and not all values can be enumerated and stored into the hash table. As a result, real-time
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 assertion that the new 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.
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 concern 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 task of approximating which exploits will be applicable and what absolute minimum or maximum value bounds will be prior to generation is difficult, and not all values can be enumerated and stored into the hash table. As a result, real-time 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 assertion that the new 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.
Other changes involved updating classes (namely the Quality, EncodedQuality, ParameterizedQuality, NetworkState, and Keyvalue classes) to include a new member for the operator in question. Auxiliary functions related to this new member, such as prints and getters, were also added. In addition, preconditions were altered to include operator overloads to check the asset identifier, quality name, and quality values for the update process.
@ -313,47 +280,52 @@ When comparing the E/S Ratio for the non-synchronous graphs to the E/S Ratio for
\subsubsection{Results for a Grouped Environment}
The environment and resulting graphs presented in Section \ref{sec:theo_results} depict the possible states of the two cars in compliance graph formats. While these graphs demonstrated accurate, exhaustive depictions of the cars and their compliance standings, they may not be realistic representations of the most likely outcomes. If a car was due for two compliance checks at the same time, it is unlikely that the car would be taken for one maintenance, returned to its original destination, then driven immediately back for maintenance, and finally to its original destination once more. The more realistic scenario is that the car is taken for maintenance, both services are performed at the same visit, and then the car is returned to its original destination.
Another set of graphs were generated using only the 3 service case. These services were for a driveshaft boot check, an AC filter change, and an oil change. This set of graphs used `super services", where a car would undergo multiple services simultaneously. These results are seen in Table \ref{table:Sync-Super-Table} for the synchronous firing enabled generation, and Table \ref{table:Non-Sync-Super-Table} for the non-synchronous firing generation.
Another set of graphs were generated using only the 3 service case. These services were for a driveshaft boot check, an AC filter change, and an oil change. This set of graphs used `comprehensive services", where a car would undergo multiple services simultaneously. These results are seen in Table \ref{table:Sync-Comp-Table} for the synchronous firing enabled generation, and Table \ref{table:Non-Sync-Comp-Table} for the non-synchronous firing generation.
\begin{table}[htp]
\centering
\begin{tabular}{|c|c|c|c|}
\hline
\multicolumn{4}{|c|}{Super Services with Synchronous Firing} \\ \hline
\multicolumn{4}{|c|}{Comprehensive Services with Synchronous Firing} \\ \hline
\textbf{Permutation}
& \textbf{Number of States}
& \textbf{Runtime (ms)}
& \textbf{E/S Ratio}
& \textbf{\begin{tabular}[c]{@{}c@{}}Number of \\ States\end{tabular}}
& \textbf{\begin{tabular}[c]{@{}c@{}}Number of \\ Edges\end{tabular}}
& \textbf{\begin{tabular}[c]{@{}c@{}}Runtime\\ (ms)\end{tabular}}
& \textbf{\begin{tabular}[c]{@{}c@{}}E/S\\ Ratio\end{tabular}}
\\ \hline
All Disjoint & 25317 & 66799.18 & 6.321 \\ \hline
\begin{tabular}[c]{@{}c@{}}All \\ Disjoint\end{tabular}
& 25317 & 0 & 66799.18 & 6.321 \\ \hline
\begin{tabular}[c]{@{}c@{}}Any Two Services, \\ One Disjoint\end{tabular}
& 10398 & 26042.852 & 5.324 \\ \hline
All Three Services & 3774 & 9261.028 & 4.868 \\ \hline
& 10398 & 0 & 26042.852 & 5.324 \\ \hline
\begin{tabular}[c]{@{}c@{}}All \\ Conjoined\end{tabular}
& 3774 & 0 & 9261.028 & 4.868 \\ \hline
\end{tabular}
\caption{Tabled Results for the Super Services with Synchronous Firing}
\label{table:Sync-Super-Table}
\caption{Tabled Results for the Comprehensive Services with Synchronous Firing}
\label{table:Sync-Comp-Table}
\end{table}
\begin{table}[htp]
\centering
\begin{tabular}{|c|c|c|c|}
\hline
\multicolumn{4}{|c|}{Super Services with Non-Synchronous Firing} \\ \hline
\textbf{Permutation}
& \textbf{Number of States}
& \textbf{Runtime (ms)}
& \textbf{E/S Ratio}
\multicolumn{4}{|c|}{Comprehensive Services with Non-Synchronous Firing} \\ \hline
\textbf{Permutation}
& \textbf{\begin{tabular}[c]{@{}c@{}}Number of \\ States\end{tabular}}
& \textbf{\begin{tabular}[c]{@{}c@{}}Number of \\ Edges\end{tabular}}
& \textbf{\begin{tabular}[c]{@{}c@{}}Runtime\\ (ms)\end{tabular}}
& \textbf{\begin{tabular}[c]{@{}c@{}}E/S\\ Ratio\end{tabular}}
\\ \hline
All Disjoint & 72489 & 184634.34 & 5.590 \\ \hline
\begin{tabular}[c]{@{}c@{}}All \\ Disjoint\end{tabular}
& 72489 & 0 & 184634.34 & 5.590 \\ \hline
\begin{tabular}[c]{@{}c@{}}Any Two Services, \\ One Disjoint\end{tabular}
& 50052 & 125176.22 & 4.819 \\ \hline
All Three Services & 19764 & 47126.42 & 4.403 \\ \hline
& 50052 & 0 & 125176.22 & 4.819 \\ \hline
\begin{tabular}[c]{@{}c@{}}All \\ Conjoined\end{tabular}
& 19764 & 0 & 47126.42 & 4.403 \\ \hline
\end{tabular}
\caption{Tabled Results for the Super Services without Synchronous Firing}
\label{table:Non-Sync-Super-Table}
\caption{Tabled Results for the Comprehensive Services without Synchronous Firing}
\label{table:Non-Sync-Comp-Table}
\end{table}
\section{Future Works}
As seen and discussed in Section \ref{sec:inseparable}, when unattainable states are generated, there is a compounding effect. Each unattainable state is explored, and is likely to generate additional unattainable states. Future works include examining the effect of synchronous firing when more assets are utilized. It is hypothesized that the synchronous firing approach will lead to an increased runtime reduction and state space reduction due to the increased number of unattainable state permutations. This work had a limited number of assets, but generated upwards of 400,000 states due to repeated applications of the exploit set due to the services corresponding with the compliance graph. Future work could alter the test scenario to have a greater number of assets, and a standard set of exploits more akin to an attack graph. Other future works could include measuring the performance of synchronous firing when multiple groups of inseparable features are used. This work used a single group, but multiple groups be added to examine the performance of the feature.