Incorporating Dr. Hawrylaks feedback. Partial work for new Accuracy subsection

OJ_Template/First Revise and Resubmit/.~lock.Notes_to_Reviewers.odt#

@@ -0,0 +1 @@
+,noah,NovaArchSys,28.03.2023 15:00,file:///home/noah/.config/libreoffice/4;

OJ_Template/First Revise and Resubmit/Schrick-Noah_AG-CG-SyncFire_Revised.tex

@@ -91,8 +91,8 @@ Post-processing is one option at removing the unattainable states. This process
 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}
-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} 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.
-For the implementation of the synchronous firing feature, there were four primary changes and additions that were required. The first is a change in the lexical analyzer, 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 second involves multiple changes to PostgreSQL to support the storage of group features and information. The third is the implementation of compound operators in RAGE, since enumeration of all exploits may not be possible, especially when modeling a system over time. The fourth is a change in the graph generation process, which checks to see if all exploits in a group are able to fire simultaneously before firing. The subsections in this Section describe these four alterations in greater detail. 
+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} as an example, the goal of synchronous firing is to only generate the 3 valid, unshaded non-root 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.
+For the implementation of the synchronous firing feature, there were four primary changes and additions that were required. The first is a change in the lexical analyzer, 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 second involves multiple changes to the PostgreSQL database implementation and schema in RAGE to support the storage of group features and information. The third is the implementation of compound operators in RAGE, since enumeration of all exploits may not be possible, especially when modeling a system over time. The fourth is a change in the graph generation process, which checks to see if all exploits in a group are able to fire simultaneously before firing. The subsections in this Section describe these four alterations in greater detail. 
 
 \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. 
@@ -152,7 +152,8 @@ The implementation of synchronous firing in the graph generation process relies
         \label{fig:sync-fire}
 \end{figure}
 
-
+\subsection{Accuracy of Generated Graphs}
+since two cars cant progress through times at different rates, the graph generated by synchronous firing represents greater real-world applicability and accuracy compared to its non-synchronous equivalent. However the accuracy of the resulting graph relies more on the input models than the synchronous firing feature itself. If a user decides to groupr features such as time and weather, questions of accuracy may be raised
 
 \section{Results} \label{sec:Results}
 \subsection{Experimental Networks and Computing Platform} \label{sec:test-platform}
@@ -197,7 +198,7 @@ The compliance checks are as follows:
 \subsubsection{DMCA Takedown}
 A second example of synchronous firing is illustrated through a DMCA Takedown for a fictitious organization \cite{DMCA}. 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 \cite{Piracy} for Windows or \cite{AndroidPiracy} for company-supplied Android mobile devices, can be incorporated into and represented by a compliance graph.
 
-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}. 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.
+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 examined and results are shown in Subsection \ref{sec:dmca_res}. 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.
 
 This experimental setup is as follows: 
 \begin{itemize}
@@ -211,8 +212,8 @@ This experimental setup is as follows:
 
 The compliance checks are as follows:
 \begin{itemize}
-    \item{Does an employee have torrenting software}
-    \item{Does an employee have illicit data}
+    \item{Does an employee have torrenting software?}
+    \item{Does an employee have illicit data?}
 \end{itemize}
 
 \subsection{Results and Analysis}