568 lines
57 KiB
TeX
568 lines
57 KiB
TeX
\documentclass{IEEEoj}
|
|
%DIF LATEXDIFF DIFFERENCE FILE
|
|
%DIF DEL ../Original Submission/Schrick-Noah_AG-CG-SyncFire.tex Mon Dec 12 09:02:11 2022
|
|
%DIF ADD Schrick-Noah_AG-CG-SyncFire_Revised.tex Fri Mar 24 17:47:38 2023
|
|
\usepackage{cite}
|
|
\usepackage{spverbatim}
|
|
\usepackage{amsmath,amssymb,amsfonts}
|
|
\usepackage{algorithmic}
|
|
\usepackage{graphicx,color}
|
|
\graphicspath{ {./images/} }
|
|
\usepackage{textcomp}
|
|
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
|
|
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
|
|
\AtBeginDocument{\definecolor{ojcolor}{cmyk}{0.93,0.59,0.15,0.02}}
|
|
\def\OJlogo{\vspace{-14pt}\includegraphics[height=28pt]{OJIM.png}}
|
|
%DIF PREAMBLE EXTENSION ADDED BY LATEXDIFF
|
|
%DIF UNDERLINE PREAMBLE %DIF PREAMBLE
|
|
\RequirePackage[normalem]{ulem} %DIF PREAMBLE
|
|
\RequirePackage{color}\definecolor{RED}{rgb}{1,0,0}\definecolor{BLUE}{rgb}{0,0,1} %DIF PREAMBLE
|
|
%\providecommand{\DIFadd}[1]{{\protect\color{blue}\uwave{#1}}} %DIF PREAMBLE
|
|
%\providecommand{\DIFdel}[1]{{\protect\color{red}\sout{#1}}} %DIF PREAMBLE
|
|
\usepackage{soulutf8}
|
|
\providecommand{\DIFadd}[1]{{\protect\hl{#1}}} %highlight
|
|
\providecommand{\DIFdel}[1]{} %do not show deleted
|
|
%DIF SAFE PREAMBLE %DIF PREAMBLE
|
|
\providecommand{\DIFaddbegin}{} %DIF PREAMBLE
|
|
\providecommand{\DIFaddend}{} %DIF PREAMBLE
|
|
\providecommand{\DIFdelbegin}{} %DIF PREAMBLE
|
|
\providecommand{\DIFdelend}{} %DIF PREAMBLE
|
|
\providecommand{\DIFmodbegin}{} %DIF PREAMBLE
|
|
\providecommand{\DIFmodend}{} %DIF PREAMBLE
|
|
%DIF FLOATSAFE PREAMBLE %DIF PREAMBLE
|
|
\providecommand{\DIFaddFL}[1]{\DIFadd{#1}} %DIF PREAMBLE
|
|
\providecommand{\DIFdelFL}[1]{\DIFdel{#1}} %DIF PREAMBLE
|
|
\providecommand{\DIFaddbeginFL}{} %DIF PREAMBLE
|
|
\providecommand{\DIFaddendFL}{} %DIF PREAMBLE
|
|
\providecommand{\DIFdelbeginFL}{} %DIF PREAMBLE
|
|
\providecommand{\DIFdelendFL}{} %DIF PREAMBLE
|
|
\newcommand{\DIFscaledelfig}{0.5}
|
|
%DIF HIGHLIGHTGRAPHICS PREAMBLE %DIF PREAMBLE
|
|
\RequirePackage{settobox} %DIF PREAMBLE
|
|
\RequirePackage{letltxmacro} %DIF PREAMBLE
|
|
\newsavebox{\DIFdelgraphicsbox} %DIF PREAMBLE
|
|
\newlength{\DIFdelgraphicswidth} %DIF PREAMBLE
|
|
\newlength{\DIFdelgraphicsheight} %DIF PREAMBLE
|
|
% store original definition of \includegraphics %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOincludegraphics}{\includegraphics} %DIF PREAMBLE
|
|
\newcommand{\DIFaddincludegraphics}[2][]{{\color{blue}\fbox{\DIFOincludegraphics[#1]{#2}}}} %DIF PREAMBLE
|
|
\newcommand{\DIFdelincludegraphics}[2][]{% %DIF PREAMBLE
|
|
\sbox{\DIFdelgraphicsbox}{\DIFOincludegraphics[#1]{#2}}% %DIF PREAMBLE
|
|
\settoboxwidth{\DIFdelgraphicswidth}{\DIFdelgraphicsbox} %DIF PREAMBLE
|
|
\settoboxtotalheight{\DIFdelgraphicsheight}{\DIFdelgraphicsbox} %DIF PREAMBLE
|
|
\scalebox{\DIFscaledelfig}{% %DIF PREAMBLE
|
|
\parbox[b]{\DIFdelgraphicswidth}{\usebox{\DIFdelgraphicsbox}\\[-\baselineskip] \rule{\DIFdelgraphicswidth}{0em}}\llap{\resizebox{\DIFdelgraphicswidth}{\DIFdelgraphicsheight}{% %DIF PREAMBLE
|
|
\setlength{\unitlength}{\DIFdelgraphicswidth}% %DIF PREAMBLE
|
|
\begin{picture}(1,1)% %DIF PREAMBLE
|
|
\thicklines\linethickness{2pt} %DIF PREAMBLE
|
|
{\color[rgb]{1,0,0}\put(0,0){\framebox(1,1){}}}% %DIF PREAMBLE
|
|
{\color[rgb]{1,0,0}\put(0,0){\line( 1,1){1}}}% %DIF PREAMBLE
|
|
{\color[rgb]{1,0,0}\put(0,1){\line(1,-1){1}}}% %DIF PREAMBLE
|
|
\end{picture}% %DIF PREAMBLE
|
|
}\hspace*{3pt}}} %DIF PREAMBLE
|
|
} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOaddbegin}{\DIFaddbegin} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOaddend}{\DIFaddend} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOdelbegin}{\DIFdelbegin} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOdelend}{\DIFdelend} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFaddbegin}{\DIFOaddbegin \let\includegraphics\DIFaddincludegraphics} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFaddend}{\DIFOaddend \let\includegraphics\DIFOincludegraphics} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFdelbegin}{\DIFOdelbegin \let\includegraphics\DIFdelincludegraphics} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFdelend}{\DIFOaddend \let\includegraphics\DIFOincludegraphics} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOaddbeginFL}{\DIFaddbeginFL} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOaddendFL}{\DIFaddendFL} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOdelbeginFL}{\DIFdelbeginFL} %DIF PREAMBLE
|
|
\LetLtxMacro{\DIFOdelendFL}{\DIFdelendFL} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFaddbeginFL}{\DIFOaddbeginFL \let\includegraphics\DIFaddincludegraphics} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFaddendFL}{\DIFOaddendFL \let\includegraphics\DIFOincludegraphics} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFdelbeginFL}{\DIFOdelbeginFL \let\includegraphics\DIFdelincludegraphics} %DIF PREAMBLE
|
|
\DeclareRobustCommand{\DIFdelendFL}{\DIFOaddendFL \let\includegraphics\DIFOincludegraphics} %DIF PREAMBLE
|
|
%DIF COLORLISTINGS PREAMBLE %DIF PREAMBLE
|
|
\RequirePackage{listings} %DIF PREAMBLE
|
|
\RequirePackage{color} %DIF PREAMBLE
|
|
\lstdefinelanguage{DIFcode}{ %DIF PREAMBLE
|
|
%DIF DIFCODE_UNDERLINE %DIF PREAMBLE
|
|
moredelim=[il][\color{red}\sout]{\%DIF\ <\ }, %DIF PREAMBLE
|
|
moredelim=[il][\color{blue}\uwave]{\%DIF\ >\ } %DIF PREAMBLE
|
|
} %DIF PREAMBLE
|
|
\lstdefinestyle{DIFverbatimstyle}{ %DIF PREAMBLE
|
|
language=DIFcode, %DIF PREAMBLE
|
|
basicstyle=\ttfamily, %DIF PREAMBLE
|
|
columns=fullflexible, %DIF PREAMBLE
|
|
keepspaces=true %DIF PREAMBLE
|
|
} %DIF PREAMBLE
|
|
\lstnewenvironment{DIFverbatim}{\lstset{style=DIFverbatimstyle}}{} %DIF PREAMBLE
|
|
\lstnewenvironment{DIFverbatim*}{\lstset{style=DIFverbatimstyle,showspaces=true}}{} %DIF PREAMBLE
|
|
%DIF END PREAMBLE EXTENSION ADDED BY LATEXDIFF
|
|
|
|
\begin{document}
|
|
\receiveddate{09 November, 2022}
|
|
\reviseddate{XX Month, XXXX}
|
|
\accepteddate{XX Month, XXXX}
|
|
\publisheddate{XX Month, XXXX}
|
|
\currentdate{XX Month, XXXX}
|
|
\doiinfo{OJIM.2022.1234567}
|
|
|
|
\title{State Space Explosion Mitigation for Large-Scale Attack and Compliance Graphs Using Synchronous Exploit Firing}
|
|
|
|
\author{NOAH L. SCHRICK\authorrefmark{1}, MEMBER, IEEE, AND PETER J. HAWRYLAK\authorrefmark{2}, SENIOR MEMBER, IEEE.}
|
|
\affil{Department of Computer Science, University of Tulsa, Tulsa,
|
|
OK 74104 USA}
|
|
\corresp{CORRESPONDING AUTHOR: Noah L. Schrick (e-mail: noah-schrick@utulsa.edu).}
|
|
|
|
\begin{abstract}
|
|
Attack and compliance graphs are useful tools for cybersecurity and regulatory or compliance analysis.
|
|
These graphs represent the state of a system or a set of systems, and can be used to identify all
|
|
current or future ways the systems are compromised or at risk of violating regulatory or compliance mandates.
|
|
However, due to their exhaustiveness and thorough permutation checking,
|
|
these graphs suffer from state space explosion - the graphs rapidly increase in the total number of states, and likewise,
|
|
their generation time also rapidly increases.
|
|
This state space explosion in turn also slows the analysis process.
|
|
This work introduces a mitigation technique called synchronous firing, where graph users and designers
|
|
can prevent the generation of infeasible states by firing exploits simultaneously
|
|
through joining inseparable features like time.
|
|
This feature does not invalidate the integrity of the resulting attack or compliance graph by
|
|
altering the exhaustiveness or permutation checking of the generation process,
|
|
but rather jointly fires exploits through their defined inseparable features.
|
|
\end{abstract}
|
|
|
|
\begin{IEEEkeywords}
|
|
Attack Graph; Compliance and Regulation; Compliance Graph; Cybersecurity; High-Performance Computing; Speedup; Synchronous Firing;
|
|
\end{IEEEkeywords}
|
|
|
|
\maketitle
|
|
|
|
\section{INTRODUCTION}
|
|
|
|
\IEEEPARstart{C}{ybersecurity} 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}. \DIFaddbegin \DIFadd{These attack graphs take the form of Directed Acyclic Graphs (DAGs), where the root node is the initial state of the environment, and each subsequent node represents the new state of the environment after changes have occurred.
|
|
}\DIFaddend 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. Attack graphs have also been extended to Cyber-Physical Systems (CPS) and the Internet of Things (IoT), and their usage can be seen in works such as that presented by the authors of \cite{CPSIOT, ming_jo}. Various analysis metrics can then be performed, such as Bayesian attack graphs \cite{10.1145/3105760}, maximum flow \cite{8290918}, and centrality-based ranking measures \cite{centrality_based}.
|
|
|
|
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, baloyi_guidelines_2019, allman_complying_2006} discuss, cyber-physical systems have seen greater usage, especially in areas such as critical infrastructure and IoT. 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 \DIFaddbegin \DIFadd{and compliance }\DIFaddend 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. \DIFdelbegin \DIFdel{This work discusses the application of }\DIFdelend \DIFaddbegin \DIFadd{Since every change in the network is examined individually, and no two changes can occur simultaneously, some nodes in the graph are created despite being infeasible. A leading cause of this is when examining an environment over time. Assets must undergo a time progression in the graph generation process, and by firing the time change separately for each asset, there is a synchronization problem where assets may progress through time disjointly from other assets. This work introduces a solution to this problem with }\DIFaddend synchronous exploit firing\DIFaddbegin \DIFadd{, }\DIFaddend which mitigates state space explosion for applicable scenarios \DIFaddbegin \DIFadd{while maintaining accuracy of the resulting graph}\DIFaddend , and discusses the \DIFaddbegin \DIFadd{performance }\DIFaddend 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++.
|
|
|
|
\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.
|
|
Another 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 Fig. \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]
|
|
\centering
|
|
\includegraphics[width=0.9\linewidth]{"./images/schri1.png"}
|
|
\caption{A network without Synchronous Firing generating infeasible states}
|
|
\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 incurring no 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}
|
|
\DIFaddbegin \DIFadd{Synchronous exploit firing aims to eliminate the generation of infeasible states during the generation process, rather than needing an additional post-processing step. Using Fig. }\ref{fig:non-sync_ex} \DIFadd{as an example, the goal of synchronous firing is to only generate the 3 valid, unshaded nodes, rather than generate all 16 nodes since 13 of the nodes represent an impossibility where two cars are progressing through time at different rates. Synchronous firing is accomplished through new grouping keywords in the input exploit file, which propagate through the modified attack and compliance graph engine, and prevent the firing of exploits if they are part of a group where all members are not yet available to fire.
|
|
}\DIFaddend For the implementation of the synchronous firing feature, there were four primary changes and additions that were \DIFdelbegin \DIFdel{necessary}\DIFdelend \DIFaddbegin \DIFadd{required}\DIFaddend . The first is a change in the lexical analyzer, \DIFdelbegin \DIFdel{the }\DIFdelend \DIFaddbegin \DIFadd{which handles the model and exploit input. Users indicate features that should fire simultaneously in these input files, and the lexical analyzer is responsible for parsing and passing that information to the graph generator. The }\DIFaddend second involves multiple changes to PostgreSQL \DIFdelbegin \DIFdel{, the }\DIFdelend \DIFaddbegin \DIFadd{to support the storage of group features and information. The }\DIFaddend third is the implementation of compound operators \DIFdelbegin \DIFdel{, and lastly }\DIFdelend \DIFaddbegin \DIFadd{in RAGE, since enumeration of all exploits may not be possible, especially when modeling a system over time. The fourth }\DIFaddend is a change in the graph generation process\DIFaddbegin \DIFadd{, which checks to see if all exploits in a group are able to fire simultaneously before firing}\DIFaddend . The subsections in this Section describe these four alterations \DIFaddbegin \DIFadd{in greater detail}\DIFaddend .
|
|
|
|
\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. This work implements the ``group" keyword.
|
|
The new 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}
|
|
\\
|
|
\\
|
|
where the ``$<$group name$>$" identifier and ``group" keyword is optional. An example of an exploit not utilizing the group feature is:
|
|
\begin{spverbatim}exploit
|
|
brake_pads(2015_Toyota_Corolla_LE)=\end{spverbatim}
|
|
\\
|
|
\\
|
|
and an example of an exploit utilizing the group feature is:
|
|
\begin{spverbatim}time group exploit
|
|
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. Fig. \ref{fig:bison-flex} illustrates the incorporation of this feature into Bison, Flex, and the overall program.
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\includegraphics[width=2.5in]{"./images/schri2.png"}
|
|
\caption{Inclusion of Synchronous Firing into GNU Bison, GNU Flex, and the overall program}
|
|
\label{fig:bison-flex}
|
|
\end{figure}
|
|
|
|
|
|
\subsection{PostgreSQL}
|
|
As seen in Fig. \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. Additional care was taken to ensure that the normalization form of the database was not altered. Before adding the group identifier to its appropriate table, additional checking was performed to ensure there would be no partial functional dependencies or transitive dependencies.
|
|
|
|
\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 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 they discuss, 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.
|
|
|
|
Other changes involved updating classes (namely the Quality, EncodedQuality, ParameterizedQuality, NetworkState, and Keyvalue classes) to include a new member for the operator in question. In addition, preconditions were altered to include operator overloads to check the asset identifier, quality name, and quality values for the update process.
|
|
|
|
\subsection{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 current loop 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. Fig. \ref{fig:sync-fire} displays the synchronous fire approach.
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\includegraphics[scale=0.5,width=2.5in]{"./images/schri3.png"}
|
|
\caption{Synchronous Firing in the Graph Generation Process}
|
|
\label{fig:sync-fire}
|
|
\end{figure}
|
|
|
|
|
|
|
|
\section{Results} \label{sec:Results}
|
|
\subsection{Experimental Networks and Computing Platform} \label{sec:test-platform}
|
|
All data was collected on a 13 node cluster, with 12 nodes serving as dedicated compute nodes, and 1 node serving as the login node. Each compute node has a configuration as follows:
|
|
\begin{itemize}
|
|
\item{OS: CentOS release 6.9}
|
|
\item{CPU: Two 8-core Intel Xeon E5-2620 v3}
|
|
\begin{itemize}
|
|
\item{With hyperthreading: 2 threads/process per core}
|
|
\end{itemize}
|
|
\item{Two Intel Xeon Phi Co-Processors}
|
|
\item{One FPGA (Nallatech PCIE-385n A7 Altera Stratix V)}
|
|
\item{Memory: 64318MiB}
|
|
\end{itemize}
|
|
All nodes are connected with a 10Gbps Infiniband interconnect.
|
|
|
|
\DIFaddbegin \subsubsection{\DIFadd{Automobile Maintenance}}
|
|
\DIFaddend The example networks for testing the effectiveness of synchronous firing follow the compliance graph generation approach. These networks analyze two assets, both of which are identical 2006 Toyota Corolla cars with identical qualities. The generation examines both cars at their current states, and proceeds to advance in time by a pre-determined amount, up to a pre-determined limit. Each time increment updates each car by an identical amount of mileage. During the generation process, it is determined if a car is out of compliance either through mileage or time since its last maintenance in accordance with the Toyota Corolla Maintenance Schedule manual.
|
|
|
|
In addition, the tests employ the use of ``services", where if a car is out of compliance, it will go through a correction process and reset the mileage and time since last service. Each test varies in the number of services used. The 1 Service case only employs one service, and it is dedicated to brake pads. The 2-Service case employs two services, where the first service is dedicated to the brake pads, and the second is for exhaust pipes. This process extends to the 3-, 4-, 5-, and 6-Service cases.
|
|
The experimental setup is as follows:
|
|
\begin{itemize}
|
|
\item{All cases ran for 12 months, with time steps of 1 month.}
|
|
\item{All cases had the same number of compliance checks: brake pads, exhaust pipes, vacuum pumps, AC filters, oil changes, and driveshaft boots.}
|
|
\item{There were 12 base exploits, and an additional 6 exploits were individually added in the form of services for each test.}
|
|
\item{All cases used the same network model.}
|
|
\item{All cases used the same exploit file, with the exception of the ``group" keyword being present in the synchronous firing testing.}
|
|
\item{All services must be performed prior to advancing time, if services are applicable.}
|
|
\item{Graph visualization was not timed. Only the generation and database operation time was measured.}
|
|
\end{itemize}
|
|
|
|
The compliance checks are as follows:
|
|
\begin{itemize}
|
|
\item{Brake pads: to be checked every 6 months}
|
|
\item{Exhaust pipes: to be checked every 12 months}
|
|
\item{AC filter: to be checked every 12,000 miles}
|
|
\item{Vacuum pump: to be checked every 120,000 miles}
|
|
\item{Engine oil: to be checked every 6,000 miles}
|
|
\item{Driveshaft boots: to be checked every 12,000 miles}
|
|
\end{itemize}
|
|
|
|
\DIFaddbegin \subsubsection{\DIFadd{DMCA Takedown}}
|
|
\DIFadd{A second example of synchronous firing is illustrated through a DMCA Takedown for a fictitious organization [19]%\mbox{%DIFAUXCMD
|
|
%\cite{DMCA}}\hskip0pt%DIFAUXCMD
|
|
. In this example, a DMCA Takedown is issued to an organization after a group of employees were found to be engaging in online piracy with torrenting software on company devices and while using company resources. Detection and removal of illicit data, such as through means presented by the authors of %\mbox{%DIFAUXCMD
|
|
%\cite{Piracy} }\hskip0pt%DIFAUXCMD
|
|
[20] for Windows or %\mbox{%DIFAUXCMD
|
|
%\cite{AndroidPiracy} }\hskip0pt%DIFAUXCMD
|
|
[21] for company-supplied Android mobile devices, can be incorporated into and represented by a compliance graph.
|
|
}
|
|
|
|
\DIFadd{For this example, various graphs are generated based on the permutations of employees present. In one graph, only Employee A is present in the network. In another graph, Employees B and C are present in the network. All permutations are tested and are show in }\ref{sec:dmca_res}\DIFadd{. The graph generation process walks through as a system administrator removes the torrenting software and the illicit data from the company devices. Typically when removing torrenting software, the data associated with the torrenting program can be removed at the same time as the uninstall automatically; an administrator does not need to remove the torrenting program and then separately remove the data. Without the use of synchronous firing, attack and compliance graphs must individually remove all data and all programs individually. This example highlights the capability of synchronous firing by grouping the removal of software and data together through ``uninstall" groups, as opposed to traditional attack and compliance graphs requiring multiple steps to remove the software and data.
|
|
}
|
|
|
|
\DIFadd{This experimental setup is as follows:
|
|
}\begin{itemize}
|
|
\item{Employee A has torrenting software, and is actively uploading and downloading 3 programs.}
|
|
\item{Employee B has torrenting software, and is actively uploading and downloading 4 programs.}
|
|
\item{Employee C has torrenting software, and is actively uploading and downloading 5 programs.}
|
|
\item{If synchronous firing is not enabled, the administrator removes each illicit program one-by-one after the removal of the torrenting software.}
|
|
\item{If synchronous firing is enabled, the administrator removes the torrenting software and all programs off a single device simultaneously.}
|
|
\item{Graph visualization was not timed. Only the generation and database operation time was measured.}
|
|
\end{itemize}
|
|
|
|
\DIFadd{The compliance checks are as follows:
|
|
}\begin{itemize}
|
|
\item{Does an employee have torrenting software}
|
|
\item{Does an employee have illicit data}
|
|
\end{itemize}
|
|
|
|
\DIFaddend \subsection{Results and Analysis}
|
|
\subsubsection{Results for the Theoretical \DIFaddbegin \DIFadd{Automobile }\DIFaddend Environment} \label{sec:theo_res}
|
|
Using the experimental setup described in Section \ref{sec:test-platform} on the platform described at the beginning of Section \ref{sec:test-platform}, results were collected in regards to the effect of synchronous firing on both state space and runtime. The graphs' edge to state ratio (E/S Ratio) was computed as well. The inclusion of this ratio allows for a comparison to be drawn regarding the usage of the synchronous firing feature. Examining this ratio can provide additional insight on how the graph's underlying topological structures change when using or not using synchronous firing. The results can be seen in Figures \ref{fig:Sync-RT} and \ref{fig:Sync-State}. The respective tables are seen in Tables \ref{table:NS-Table} and \ref{table:S-Table}. Both figures show a decrease in the number of states and a decrease in the runtime when synchronous firing is utilized. Since synchronous firing prevents the generation of unattainable states, there is no meaningful information loss that occurs in the graphs generated with the synchronous firing feature. Since the resulting number of states was also reduced, there will be increased justification for the synchronous firing approach due to a reduced runtime for the analysis process. Fig. \ref{fig:Sync-Spd} displays the speedup (according to Amdahl's Law) obtained when using synchronous firing instead of non-synchronous firing for identical setups\DIFaddbegin \DIFadd{, as well as the state space reduction factor}\DIFaddend .
|
|
|
|
When examining the E/S Ratio for the non-synchronous graphs, it is both expected and observed that the ratio slightly increases as the number of services increases. When more applicable exploits are used during the generation process, the number of permutations increases, which corresponds with the growing number of states and edges. However, the increase in the number of services also increases the relation between states and the new permutations.
|
|
|
|
When comparing the E/S Ratio for the non-synchronous graphs to the E/S Ratio for the synchronous graphs, it is observed that the ratio does not remain constant. For example, for the 5-Service case, the non-synchronous graph has an E/S Ratio of 6.398, and the synchronous graph has an E/S Ratio of 7.209. While the number of states and the number of edges is reduced when using synchronous firing, the ratio of edges to states is not necessarily constant or reduced.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=3.3in]{"./images/schri4.png"}
|
|
\includegraphics[width=3.3in]{"./images/schri5.png"}
|
|
\caption[Synchronous Firing on Runtime]{Bar Graph and Line Graph Representations of Synchronous Firing on Runtime}
|
|
\label{fig:Sync-RT}
|
|
\end{figure}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=3.3in]{"./images/schri6.png"}
|
|
\includegraphics[width=3.3in]{"./images/schri7.png"}
|
|
\caption{Bar Graph and Line Graph Representations of Synchronous Firing on State Space}
|
|
\label{fig:Sync-State}
|
|
\end{figure}
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\includegraphics[width=3.3in]{"./images/schri8.png"}
|
|
\DIFaddbeginFL \includegraphics[width=3.3in]{"./images/schri9.png"}
|
|
\DIFaddendFL \caption{Speedup (Amdahl's) \DIFaddbeginFL \DIFaddFL{and State Space Reduction Factor }\DIFaddendFL Obtained When Using Synchronous Firing}
|
|
\label{fig:Sync-Spd}
|
|
\end{figure}
|
|
|
|
\begin{table}[htp]
|
|
\caption{Results for the Non-Synchronous Firing Testing}
|
|
\label{table:NS-Table}
|
|
\centering
|
|
\setlength\tabcolsep{4pt}
|
|
\begin{tabular}{|c|c|c|c|c|}
|
|
\hline
|
|
\multicolumn{5}{|c|}{Non-Synchronous Firing} \\ \hline
|
|
\textbf{\begin{tabular}[c]{@{}c@{}}Number of \\ Services\end{tabular}}
|
|
& \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
|
|
1 & 37001 & 202920 & 87366.65 & 5.484 \\ \hline
|
|
2 & 46361 & 259400 & 115929.97 & 5.595 \\ \hline
|
|
3 & 72489 & 405236 & 184634.34 & 5.590 \\ \hline
|
|
4 & 93525 & 546280 & 252959.511 & 5.841 \\ \hline
|
|
5 & 209944 & 1254784 & 588336.01 & 5.977 \\ \hline
|
|
6 & 423940 & 2712165 & 1581697.61 & 6.398 \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\begin{table}[htp]
|
|
\caption{Results for the Synchronous Firing Testing}
|
|
\label{table:S-Table}
|
|
\centering
|
|
\setlength\DIFdelbeginFL %DIFDELCMD < \tabcolsep{4pt}
|
|
%DIFDELCMD < \begin{tabular}{|c|c|c|c|c|c|}
|
|
%DIFDELCMD < %%%
|
|
\DIFdelendFL \DIFaddbeginFL \tabcolsep{3pt}
|
|
\begin{tabular}{|c|c|c|c|c|c|c|}
|
|
\DIFaddendFL \hline
|
|
\DIFdelbeginFL %DIFDELCMD < \multicolumn{6}{|c|}{Synchronous Firing} %%%
|
|
\DIFdelendFL \DIFaddbeginFL \multicolumn{7}{|c|}{Synchronous Firing} \DIFaddendFL \\ \hline
|
|
\textbf{\begin{tabular}[c]{@{}c@{}}Services\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}States\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Edges\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Runtime\\(ms)\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}E/S\\Ratio\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Speedup\end{tabular}}
|
|
\DIFaddbeginFL & \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{State Space}\\\DIFaddFL{Reduction}\end{tabular}}
|
|
\DIFaddendFL \\ \hline
|
|
1 & 6277 & 3.46E04 & 1.48E04 & 5.507 & 5.87 \DIFaddbeginFL & \DIFaddFL{5.89 }\DIFaddendFL \\ \hline
|
|
2 & 11653 & 6.94E04 & 2.92E04 & 5.954 & 3.96 \DIFaddbeginFL & \DIFaddFL{3.98 }\DIFaddendFL \\ \hline
|
|
3 & 25317 & 1.60E05 & 6.68E04 & 6.321 & 2.76 \DIFaddbeginFL & \DIFaddFL{2.86 }\DIFaddendFL \\ \hline
|
|
4 & 36949 & 2.42E05 & 1.02E05 & 6.538 & 2.47 \DIFaddbeginFL & \DIFaddFL{2.53 }\DIFaddendFL \\ \hline
|
|
5 & 83134 & 5.71E05 & 2.44E05 & 6.868 & 2.42 \DIFaddbeginFL & \DIFaddFL{2.53 }\DIFaddendFL \\ \hline
|
|
6 & 186679 & 1.35E06 & 5.82E05 & 7.209 & 2.72 \DIFaddbeginFL & \DIFaddFL{2.27 }\DIFaddendFL \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsubsection{Results for a Grouped \DIFaddbegin \DIFadd{Automobile }\DIFaddend Environment}
|
|
The environment and resulting graphs presented in Section \ref{sec:theo_res} 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 `comprehensive services", where a car would undergo multiple services simultaneously. With three services used, there are a total of three permutations: all three services are done individually, two services are performed simultaneously while the other is performed later, and all three services are performed simultaneously.
|
|
|
|
For this set of examples, all compliance checks have the same time requirements. This work does not introduce any heuristics or methodologies for intentionally performing services early or late. If Service A was required no later than every 6 months, but Service B was required no later than every 8 months, then joining Service A and Service B together would either mean: 1. Service B was completed 2 months earlier than it needed to be, or 2. Service A was completed 2 months later than it needed to be. This was considered out of scope for this approach, but this is noted in the Future Works Section (Section \ref{sec:fw}).
|
|
|
|
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. The corresponding figures for the runtime can be seen in Fig. \ref{fig:Comp-Sync-RT}, and the corresponding figures for state space can be seen in Fig. \ref{fig:Comp-Sync-State}. It is noticeable that there is a state space reduction achieved through synchronous firing in this set of examples, along with a runtime improvement. When all three services were conjoined, synchronous firing provided a 5.09x speedup over non-synchronous firing. Using comprehensive services on their own also provided a reduction in state space and an improvement in runtime. When synchronous firing was enabled and comprehensive services were used, the total number of states could be reduced from 25,317 to 3,774, providing a a 6.7x reduction in state space solely from combining services.
|
|
|
|
Leveraging comprehensive services with synchronous firing enables users to significantly reduce the size of the resulting attack or compliance graphs. Comprehensive services also enable users to introduce heuristics to analyze and identify optimal service plans for compliance, or attack mitigation strategies for attack graphs. Coupled with synchronous firing, analysis of these optimal plans can be performed quicker due to the inexistence of superfluous, unattainable states.
|
|
|
|
\begin{table}[htp]
|
|
\caption{Results for the Comprehensive Services without Synchronous Firing}
|
|
\label{table:Non-Sync-Comp-Table}
|
|
\centering
|
|
\setlength\tabcolsep{4pt}
|
|
\begin{tabular}{|c|c|c|c|c|}
|
|
\hline
|
|
\multicolumn{5}{|c|}{Comprehensive Services with Non-Synchronous Firing} \\ \hline
|
|
\textbf{Permutation}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}States\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Edges\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Runtime\\(ms)\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}E/S\\Ratio\end{tabular}}
|
|
\\ \hline
|
|
\begin{tabular}[c]{@{}c@{}}All \\ Disjoint\end{tabular}
|
|
& 72489 & 405236 & 184634.34 & 5.590 \\ \hline
|
|
\begin{tabular}[c]{@{}c@{}}Any Two\\Services,\\One Disjoint\end{tabular}
|
|
& 50052 & 241176 & 125176.22 & 4.819 \\ \hline
|
|
\begin{tabular}[c]{@{}c@{}}All \\ Conjoined\end{tabular}
|
|
& 19764 & 87024 & 47126.42 & 4.403 \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\begin{table}[htp]
|
|
\caption{Results for the Comprehensive Services with Synchronous Firing}
|
|
\label{table:Sync-Comp-Table}
|
|
\centering
|
|
\setlength\tabcolsep{4pt}
|
|
\begin{tabular}{|c|c|c|c|c|c|}
|
|
\hline
|
|
\multicolumn{6}{|c|}{Comprehensive Services with Synchronous Firing} \\ \hline
|
|
\textbf{Permutation}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}States\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Edges\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Runtime\\ (ms)\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}E/S\\ Ratio\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}Speedup\end{tabular}}
|
|
\\ \hline
|
|
\begin{tabular}[c]{@{}c@{}}All \\ Disjoint\end{tabular}
|
|
& 25317 & 160041 & 66799.18 & 6.321 & 2.76 \\ \hline
|
|
\begin{tabular}[c]{@{}c@{}}Any Two\\Services,\\One Disjoint\end{tabular}
|
|
& 10398 & 55354 & 26042.85 & 5.324 & 4.81 \\ \hline
|
|
\begin{tabular}[c]{@{}c@{}}All \\ Conjoined\end{tabular}
|
|
& 3774 & 18370 & 9261.03 & 4.868 & 5.09 \\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\DIFdelbeginFL %DIFDELCMD < \includegraphics[width=3.3in]{"./images/schri9.png"}
|
|
%DIFDELCMD < %%%
|
|
\DIFdelendFL \includegraphics[width=3.3in]{"./images/schri10.png"}
|
|
\DIFaddbeginFL \includegraphics[width=3.3in]{"./images/schri11.png"}
|
|
\DIFaddendFL \caption[Synchronous Firing on Runtime]{Bar Graph and Line Graph Representations of Synchronous Firing with Comprehensive Services on Runtime}
|
|
\label{fig:Comp-Sync-RT}
|
|
\end{figure}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\DIFdelbeginFL %DIFDELCMD < \includegraphics[width=3.3in]{"./images/schri11.png"}
|
|
%DIFDELCMD < %%%
|
|
\DIFdelendFL \includegraphics[width=3.3in]{"./images/schri12.png"}
|
|
\DIFaddbeginFL \includegraphics[width=3.3in]{"./images/schri13.png"}
|
|
\DIFaddendFL \caption{Bar Graph and Line Graph Representations of Synchronous Firing with Comprehensive Services on State Space}
|
|
\label{fig:Comp-Sync-State}
|
|
\end{figure}
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\DIFdelbeginFL %DIFDELCMD < \includegraphics[width=3.3in]{"./images/schri13.png"}
|
|
%DIFDELCMD < %%%
|
|
\DIFdelendFL \DIFaddbeginFL \includegraphics[width=3.3in]{"./images/schri14.png"}
|
|
\DIFaddendFL \caption{Speedup (Amdahl's) Obtained When Using Synchronous Firing with Comprehensive Services}
|
|
\label{fig:Comp-Sync-Spd}
|
|
\DIFaddbeginFL \end{figure}
|
|
|
|
\subsubsection{\DIFadd{Results for the DMCA Takedown Environment}} \label{sec:dmca_res}
|
|
\DIFadd{Using the experimental setup described in Section }\ref{sec:test-platform} \DIFadd{on the platform described at the beginning of Section }\ref{sec:test-platform}\DIFadd{, results were collected in regards to the effect of synchronous firing on both state space and runtime. The graphs' edge to state ratio (E/S Ratio) was computed as well. The respective tables are seen in Tables }\ref{table:DMCA-NS-Table} \DIFadd{and }\ref{table:DMCA-S-Table}\DIFadd{. The associated figure (Fig. }\ref{fig:DMCA-States-Runtime}\DIFadd{) shows a decrease in the number of states and a decrease in the runtime when synchronous firing is utilized. Since synchronous firing prevents the generation of unattainable states, there is no meaningful information loss that occurs in the graphs generated with the synchronous firing feature. Fig. }\ref{fig:DMCA-Sync-Spd} \DIFadd{displays the speedup (according to Amdahl's Law) obtained when using synchronous firing instead of non-synchronous firing for identical setups, as well as the state space reduction factor.
|
|
}
|
|
|
|
\DIFadd{In this example, the synchronous firing approach mitigates the state space explosion by an increasing factor. With traditional attack and compliance graph generation, the uninstall process is required to be broken into individual steps, causing an unnecessarily large growth in the resulting graph. This is exacerbated due to the presence of multiple employees transmitting multiple pieces of illicit data, all of which must be captured individually. Using synchronous firing allows for better modeling of real systems, where features, processes, or tasks are often combined into single steps.
|
|
}
|
|
|
|
\begin{table}[htp]
|
|
\caption{\DIFaddFL{Results for the Non-Synchronous Firing Testing}}
|
|
\label{table:DMCA-NS-Table}
|
|
\centering
|
|
\setlength\tabcolsep{4pt}
|
|
\begin{tabular}{|c|c|c|c|c|}
|
|
\hline
|
|
\multicolumn{5}{|c|}{Non-Synchronous Firing} \\ \hline
|
|
\textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Employees }\\ \DIFaddFL{Present}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Number of }\\ \DIFaddFL{States}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Number of }\\ \DIFaddFL{Edges}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Runtime}\\ \DIFaddFL{(ms)}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{E/S}\\ \DIFaddFL{Ratio}\end{tabular}}
|
|
\\ \hline
|
|
\DIFaddFL{A }& \DIFaddFL{16 }& \DIFaddFL{32 }& \DIFaddFL{11.109 }& \DIFaddFL{2.000 }\\ \hline
|
|
\DIFaddFL{B }& \DIFaddFL{32 }& \DIFaddFL{80 }& \DIFaddFL{26.202 }& \DIFaddFL{2.500 }\\ \hline
|
|
\DIFaddFL{C }& \DIFaddFL{64 }& \DIFaddFL{192 }& \DIFaddFL{64.012 }& \DIFaddFL{3.000 }\\ \hline
|
|
\DIFaddFL{AB }& \DIFaddFL{512 }& \DIFaddFL{1984 }& \DIFaddFL{906.578 }& \DIFaddFL{3.875 }\\ \hline
|
|
\DIFaddFL{AC }& \DIFaddFL{1024 }& \DIFaddFL{4032 }& \DIFaddFL{2154.862 }& \DIFaddFL{3.938 }\\ \hline
|
|
\DIFaddFL{BC }& \DIFaddFL{2048 }& \DIFaddFL{8128 }& \DIFaddFL{5154.858 }& \DIFaddFL{3.969 }\\ \hline
|
|
\DIFaddFL{ABC }& \DIFaddFL{32768 }& \DIFaddFL{131008 }& \DIFaddFL{105675.709 }& \DIFaddFL{3.998 }\\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\begin{table}[htp]
|
|
\caption{\DIFaddFL{Results for the Synchronous Firing Testing}}
|
|
\label{table:DMCA-S-Table}
|
|
\centering
|
|
\setlength\tabcolsep{3pt}
|
|
\begin{tabular}{|c|c|c|c|c|c|c|}
|
|
\hline
|
|
\multicolumn{7}{|c|}{Synchronous Firing} \\ \hline
|
|
\textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Employees }\\ \DIFaddFL{Present}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{States}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Edges}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Runtime}\\\DIFaddFL{(ms)}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{E/S}\\\DIFaddFL{Ratio}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{Speedup}\end{tabular}}
|
|
& \textbf{\begin{tabular}[c]{@{}c@{}}\DIFaddFL{State Space}\\\DIFaddFL{Reduction}\end{tabular}}
|
|
\\ \hline
|
|
\DIFaddFL{A }& \DIFaddFL{2 }& \DIFaddFL{1 }& \DIFaddFL{3.810 }& \DIFaddFL{0.500 }& \DIFaddFL{2.92 }& \DIFaddFL{8.00 }\\ \hline
|
|
\DIFaddFL{B }& \DIFaddFL{2 }& \DIFaddFL{1 }& \DIFaddFL{5.214 }& \DIFaddFL{0.500 }& \DIFaddFL{5.03 }& \DIFaddFL{16.00 }\\ \hline
|
|
\DIFaddFL{C }& \DIFaddFL{2 }& \DIFaddFL{1 }& \DIFaddFL{9.063 }& \DIFaddFL{0.500 }& \DIFaddFL{7.06 }& \DIFaddFL{32.00 }\\ \hline
|
|
\DIFaddFL{AB }& \DIFaddFL{4 }& \DIFaddFL{4 }& \DIFaddFL{67.560 }& \DIFaddFL{1.000 }& \DIFaddFL{13.42 }& \DIFaddFL{128.00 }\\ \hline
|
|
\DIFaddFL{AC }& \DIFaddFL{4 }& \DIFaddFL{4 }& \DIFaddFL{117.833 }& \DIFaddFL{1.000 }& \DIFaddFL{18.29 }& \DIFaddFL{256.00 }\\ \hline
|
|
\DIFaddFL{BC }& \DIFaddFL{4 }& \DIFaddFL{4 }& \DIFaddFL{108.544 }& \DIFaddFL{1.000 }& \DIFaddFL{47.49 }& \DIFaddFL{512.00 }\\ \hline
|
|
\DIFaddFL{ABC }& \DIFaddFL{8 }& \DIFaddFL{12 }& \DIFaddFL{705.016 }& \DIFaddFL{1.500 }& \DIFaddFL{149.89 }& \DIFaddFL{4096.00 }\\ \hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=3.3in]{"./images/schri15.png"}
|
|
\includegraphics[width=3.3in]{"./images/schri16.png"}
|
|
\caption{\DIFaddFL{Synchronous Firing on State Space and Runtime for the DMCA Takedown Environment}}
|
|
\label{fig:DMCA-States-Runtime}
|
|
\end{figure}
|
|
|
|
\begin{figure}[htp]
|
|
\centering
|
|
\includegraphics[width=3.3in]{"./images/schri17.png"}
|
|
\includegraphics[width=3.3in]{"./images/schri18.png"}
|
|
\caption{\DIFaddFL{Speedup (Amdahl's) and State Space Reduction Factor Obtained When Using Synchronous Firing}}
|
|
\label{fig:DMCA-Sync-Spd}
|
|
\DIFaddendFL \end{figure}
|
|
|
|
\section{Future Works} \label{sec:fw}
|
|
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 scenario to have a greater number of assets, and a standard set of exploits more akin to an attack graph rather than a compliance 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.
|
|
|
|
Another avenue for future work would be to take a network science approach. There may be features of interest from examining the topology of the resulting graphs with and without synchronous firing. Various centrality metrics could be examined, as well as examining transformations such as dominant trees or transitive closures derived from the original graphs. Each approach could compare each graph when using or not using synchronous firing to determine if there are possible points of interest. Taking a network science approach could also examine and analyze the E/S Ratio of the graphs when using or not using synchronous firing, and attempt to provide further insight on what those differences mean in terms of usability of the graphs.
|
|
|
|
Introducing service heuristics could improve the characteristics of synchronous firing. If services are performed too early, then additional states would be generated in the resulting graph. If synchronous firing was not used, these additional states could compound into more states due to the separation of features. Likewise, if services are performed too late, then additional states could be generated to represent the compliance violation, and these states may also compound into more statues without synchronous firing. Examining the impact of synchronous firing when various heuristics are implemented could reveal interesting results.
|
|
|
|
\section{Conclusion}
|
|
This work implemented a state space explosion mitigation technique called synchronous firing. This feature is able to fire exploits simultaneously among a group of assets through a single state transition. By firing exploits across multiple assets, it is able to prevent the separation of features that should normally be inseparable (such as time), and successfully reduces the number of total states in the resulting attack or compliance graph. This feature does not alter the procedure of the generation process in a way that undermines the integrity of the resulting attack or compliance graph, and only groups assets through defined inseparable features. This feature is also toggleable, and the generation process seen in Fig. \ref{fig:sync-fire} does not change if the feature is disabled. This feature successfully reduced the total number of states, reduced the runtime of the generation process, and can lead to a reduced analysis process due to a smaller resulting graph.
|
|
|
|
\bibliography{Bibliography}
|
|
\bibliographystyle{ieeetr}
|
|
|
|
\end{document} |