Adding in modified tex files and generated PDF for IEEE TC and Computer Society

TC_Template/Bibliography.bib

@@ -0,0 +1,212 @@
+@article{schneier_modeling_1999,
+	title = {Modeling {Security} {Threats}},
+	url = {https://www.schneier.com/academic/archives/1999/12/attack_trees.html},
+	author = {Schneier, Bruce},
+	year = {1999},
+	journal = {Dr. Dobb's Journal},
+	note = {vol. 24, no.12}
+}
+
+@article{phillips_graph-based_1998,
+	title = {A graph-based system for network-vulnerability analysis},
+	volume = {Part F1292},
+	issn = {1581131682},
+	doi = {10.1145/310889.310919},
+	abstract = {This paper presents a graph-based approach to network vulnerability analysis. The method is flexible, allowing analysis of attacks from both outside and inside the network. It can analyze risks to a specific network asset, or examine the universe of possible consequences following a successful attack. The graph-based tool can identify the set of attack paths that have a high probability of success (or a low "effort" cost) for the attacker. The system could be used to test the effectiveness of making configuration changes, implementing an intrusion detection system, etc. The analysis system requires as input a database of common attacks, broken into atomic steps, specific network configuration and topology information, and an attacker profile. The attack information is "matched" with the network configuration information and an attacker profile to create a superset attack graph. Nodes identify a stage of attack, for example the class of machines the attacker has accessed and the user privilege level he or she has compromised. The arcs in the attack graph represent attacks or stages of attacks. By assigning probabilities of success on the arcs or costs representing level-of-effort for the attacker, various graph algorithms such as shortest-path algorithms can identify the attack paths with the highest probability of success.},
+	journal = {Proceedings New Security Paradigms Workshop},
+	author = {Phillips, Cynthia and Swiler, Laura Painton},
+	note = {doi: 10.1145/310889.310919},
+	year = {1998},
+	keywords = {Attack graph, Computer security, Network vulnerability},
+	pages = {71--79},
+	file = {310889.310919:/home/noah/Zotero/storage/JMW5DI72/310889.310919.pdf:application/pdf},
+}
+
+@article{ou_scalable_2006,
+	title = {A {Scalable} {Approach} to {Attack} {Graph} {Generation}},
+	issn = {1595935185},
+	author = {Ou, Xinming and Boyer, Wayne F and Mcqueen, Miles A},
+	year = {2006},
+	journal = {CCS '06: Proceedings of the 13th ACM conference on Computer and communications security},
+	keywords = {attack graphs, enterprise network security, logic-programming},
+	pages = {336--345},
+	file = {1180405.1180446:/home/noah/Zotero/storage/TJKHVC4R/1180405.1180446.pdf:application/pdf},
+}
+
+@misc{j_hale_compliance_nodate,
+	title = {Compliance {Method} for a {Cyber}-{Physical} {System}},
+	author = {{J. Hale} and Hawrylak, P. and Papa, M.},
+	note = {U.S. Patent Number 9,471,789, Oct. 18, 2016.},
+	number = {9471789},
+	file = {Complaince_Graph_US_Patent_9471789:/home/noah/Zotero/storage/55BZN4U7/Complaince_Graph_US_Patent_9471789.pdf:application/pdf},
+}
+
+@inproceedings{baloyi_guidelines_2019,
+	address = {Skukuza South Africa},
+	title = {Guidelines for {Data} {Privacy} {Compliance}: {A} {Focus} on {Cyberphysical} {Systems} and {Internet} of {Things}},
+	doi = {10.1145/3351108.3351143},
+	booktitle = {{SAICSIT} '19: {Proceedings} of the {South} {African} {Institute} of {Computer} {Scientists} and {Information} {Technologists} 2019},
+	publisher = {Association for Computing Machinery},
+	author = {Baloyi, Ntsako and Kotzé, Paula},
+	year = {2019},
+}
+
+@article{allman_complying_2006,
+	title = {Complying with {Compliance}: {Blowing} it off is not an option.},
+	volume = {4},
+	number = {7},
+	journal = {ACM Queue},
+	author = {Allman, Eric},
+	year = {2006},
+}
+
+@article{sheyner_automated_2002,
+	title = {Automated {Generation} and {Analysis} of {Attack} {Graphs}},
+	issn = {9781787284395},
+	journal = {Proceeding of 2002 IEEE Symposium on Security and Privacy},
+	author = {Sheyner, O. and Haines, J. and Jha, S. and Lippmann, R.. and Wing, J.},
+	year = {2002},
+	pages = {254--265},
+	file = {sheyner-wing02:/home/noah/Zotero/storage/BV6NHT6L/sheyner-wing02.pdf:application/pdf},
+}
+
+@article{zhang_boosting_2017,
+	title = {Boosting the performance of {FPGA}-based graph processor using hybrid memory cube: {A} case for breadth first search},
+	issn = {9781450343541},
+	doi = {10.1145/3020078.3021737},
+	abstract = {Large graph processing has gained great attention in recent years due to its broad applicability from machine learning to social science. Large real-world graphs, however, are inherently difficult to process efficiently, not only due to their large memory footprint, but also that most graph algorithms entail memory access patterns with poor locality and a low compute-to-memory access ratio. In this work, we leverage the exceptional random access performance of emerging Hybrid Memory Cube (HMC) technology that stacks multiple DRAM dies on top of a logic layer, combined with the flexibility and efficiency of FPGA to address these challenges. To our best knowledge, this is the first work that implements a graph processing system on a FPGA-HMC platform based on software/hardware co-design and co-optimization. We first present the modifications of algorithm and a platform-aware graph processing architecture to perform level-synchronized breadth first search (BFS) on FPGA-HMC platform. To gain better insights into the potential bottlenecks of proposed implementation, we develop an analytical performance model to quantitatively evaluate the HMC access latency and corresponding BFS performance. Based on the analysis, we propose a two-level bitmap scheme to further reduce memory access and perform optimization on key design parameters (e.g. memory access granularity). Finally, we evaluate the performance of our BFS implementation using the AC-510 development kit from Micron. We achieved 166 million edges traversed per second (MTEPS) using GRAPH500 benchmark on a random graph with a scale of 25 and an edge factor of 16, which significantly outperforms CPU and other FPGA-based large graph processors.},
+	journal = {FPGA 2017 - Proceedings of the 2017 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays},
+	author = {Zhang, Jialiang and Khoram, Soroosh and Li, Jing},
+	year = {2017},
+	pages = {207--216},
+	file = {Boosting the Performance of FPGA-based Graph Processor using Hybrdi Memory Cube:/home/noah/Zotero/storage/CDKPUXYF/Boosting the Performance of FPGA-based Graph Processor using Hybrdi Memory Cube.pdf:application/pdf},
+}
+
+@inproceedings{Monotonicity,
+	author = {Ammann, Paul and Wijesekera, Duminda and Kaushik, Saket},
+	title = {Scalable, Graph-Based Network Vulnerability Analysis},
+	year = {2002},
+	isbn = {1581136129},
+	publisher = {Association for Computing Machinery},
+	address = {New York, NY, USA},
+	url = {https://doi.org/10.1145/586110.586140},
+	doi = {10.1145/586110.586140},
+	abstract = {Even well administered networks are vulnerable to attack. Recent work in network security has focused on the fact that combinations of exploits are the typical means by which an attacker breaks into a network. Researchers have proposed a variety of graph-based algorithms to generate attack trees (or graphs). Either structure represents all possible sequences of exploits, where any given exploit can take advantage of the penetration achieved by prior exploits in its chain, and the final exploit in the chain achieves the attacker's goal. The most recent approach in this line of work uses a modified version of the model checker NuSMV as a powerful inference engine for chaining together network exploits, compactly representing attack graphs, and identifying minimal sets of exploits. However, it is also well known that model checkers suffer from scalability problems, and there is good reason to doubt whether a model checker can handle directly a realistic set of exploits for even a modest-sized network. In this paper, we revisit the idea of attack graphs themselves, and argue that they represent more information explicitly than is necessary for the analyst. Instead, we propose a more compact and scalable representation. Although we show that it is possible to produce attack trees from our representation, we argue that more useful information can be produced, for larger networks, while bypassing the attack tree step. Our approach relies on an explicit assumption of monotonicity, which, in essence, states that the precondition of a given exploit is never invalidated by the successful application of another exploit. In other words, the attacker never needs to backtrack. The assumption reduces the complexity of the analysis problem from exponential to polynomial, thereby bringing even very large networks within reach of analysis},
+	booktitle = {Proceedings of the 9th ACM Conference on Computer and Communications Security},
+	pages = {217–224},
+	numpages = {8},
+	keywords = {network security, scalability, model checking, monotonic analysis, exploit, vulnerability},
+	location = {Washington, DC, USA},
+	series = {CCS '02}
+}
+
+@inbook{TVA,
+	author = {Jajodia, Sushil and Noel, Steven},
+	year = {2010},
+	month = {09},
+	pages = {139-154},
+	title = {Topological Vulnerability Analysis},
+	volume = {46},
+	isbn = {978-1-4419-0139-2},
+	journal = {Cyber Situational Awareness, Advances in Information Security, Volume 46. ISBN 978-1-4419-0139-2. Springer-Verlag US, 2010, p. 139},
+	doi = {10.1007/978-1-4419-0140-8_7}
+}
+
+@phdthesis{louthan_hybrid_2011,
+	title = {Hybrid {Attack} {Graphs} for {Modeling} {Cyber}-{Physical} {Systems}},
+	author = {Louthan, G},
+	school = {The {University} of {Tulsa}},
+	year = {2011},
+	keywords = {icle},
+	file = {louthan_thesis:/home/noah/Zotero/storage/5SBCLYA3/louthan_thesis.pdf:application/pdf},
+}
+
+@phdthesis{cook_rage_2018,
+	title = {{RAGE}: {The} {Rage} {Attack} {Graph} {Engine}},
+	author = {Cook, Kyle},
+	school = {The {University} of {Tulsa}},
+	year = {2018},
+	file = {Kyle Cook Thesis:/home/noah/Zotero/storage/2SR28HM2/Kyle Cook Thesis.pdf:application/pdf},
+}
+
+@phdthesis{nichols_2018,
+	title = {{Hybrid} {Attack} {Graphs} for {Use} with a {Simulation} of a {Cyber-Physical} {System}},
+	author = {Nichols, Will M.},
+	school = {The {University} of {Tulsa}},
+	year = {2018},
+	file = {Will_Nichols_Thesis_FINAL_VER:/home/noah/Zotero/storage/8AXSZXJN/Will_Nichols_Thesis_FINAL_VER.pdf:application/pdf},
+}
+
+@article{ming_jo,
+author = {Li, Ming and Hawrylak, Peter and Hale, John},
+title = {Strategies for Practical Hybrid Attack Graph Generation and Analysis},
+year = {2021},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+issn = {2692-1626},
+url = {https://doi.org/10.1145/3491257},
+doi = {10.1145/3491257},
+abstract = {As an analytical tool in cyber-security, an attack graph (AG) is capable of discovering multi-stage attack vectors on target computer networks. Cyber-physical systems (CPSs) comprise a special type of network that not only contains computing devices but also integrates components that operate in the continuous domain, such as sensors and actuators. Using AGs on CPSs requires that the system models and exploit patterns capture both token- and real-valued information. In this paper, we describe a hybrid AG model for security analysis of CPSs and computer networks. Specifically, we focus on two issues related to applying the model in practice: efficient hybrid AG generation and techniques for information extraction from them. To address the first issue, we present an accelerated hybrid AG generator that employs parallel programming and high performance computing (HPC). We conduct performance tests on CPU and GPU platforms to characterize the efficiency of our parallel algorithms. To address the second issue, we introduce an analytical regimen based on centrality analysis and apply it to a hybrid AG generated for a target CPS system to discover effective vulnerability remediation solutions.},
+note = {Just Accepted},
+journal = {Digital Threats},
+month = {oct},
+keywords = {cyber-physical system, high performance computing, attack graph, breadth-first search}
+}
+
+@inproceedings{CPSIOT,
+author = {Al Ghazo, Alaa T. and Ibrahim, Mariam and Ren, Hao and Kumar, Ratnesh},
+title = {A2G2V: Automated Attack Graph Generator and Visualizer},
+year = {2018},
+isbn = {9781450358606},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/3215466.3215468},
+doi = {10.1145/3215466.3215468},
+abstract = {The Internet of Things (IoT) and Cyber-Physical Systems (CPS) technologies have increased the complexity of systems and also exposed them to additional vulnerabilities. Attack-graphs are graphical representations that provide a complete view of how inter-dependencies among atomic vulnerabilities may be exploited by an adversary to stitch together an attack that can compromise the system. Their manual construction is tedious, error-prone, and time consuming. This paper presents a model-based Automated Attack-Graph Generator and Visualizer (A2G2V). Given the networked system description (its components, connectivity, services it supports, their vulnerabilities and protections), the attack graph enlists set of all possible sequences in which atomic-level vulnerabilities can be exploited to compromise a certain system-level security. The proposed A2G2V tool extends an existing formal methods tool (a model-checker) by integrating with it an architecture description tool, our own code (for parsing counterexamples, encoding those for specification relaxation, iterating till all attack sequences are revealed), and also a graph visualization tool.},
+booktitle = {Proceedings of the 1st ACM MobiHoc Workshop on Mobile IoT Sensing, Security, and Privacy},
+articleno = {3},
+numpages = {6},
+keywords = {Model Checking, Security, Enumerating Counterexamples, Internet of Things, Attack Graph, Cyber-Physical Systems},
+location = {Los Angeles, CA, USA},
+series = {Mobile IoT SSP'18}
+}
+
+@article{10.1145/3105760,
+author = {Mu\~{n}oz-Gonz\'{a}lez, Luis and Sgandurra, Daniele and Paudice, Andrea and Lupu, Emil C.},
+title = {Efficient Attack Graph Analysis through Approximate Inference},
+year = {2017},
+issue_date = {August 2017},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+volume = {20},
+number = {3},
+issn = {2471-2566},
+url = {https://doi.org/10.1145/3105760},
+doi = {10.1145/3105760},
+abstract = {Attack graphs provide compact representations of the attack paths an attacker can follow to compromise network resources from the analysis of network vulnerabilities and topology. These representations are a powerful tool for security risk assessment. Bayesian inference on attack graphs enables the estimation of the risk of compromise to the system’s components given their vulnerabilities and interconnections and accounts for multi-step attacks spreading through the system. While static analysis considers the risk posture at rest, dynamic analysis also accounts for evidence of compromise, for example, from Security Information and Event Management software or forensic investigation. However, in this context, exact Bayesian inference techniques do not scale well. In this article, we show how Loopy Belief Propagation—an approximate inference technique—can be applied to attack graphs and that it scales linearly in the number of nodes for both static and dynamic analysis, making such analyses viable for larger networks. We experiment with different topologies and network clustering on synthetic Bayesian attack graphs with thousands of nodes to show that the algorithm’s accuracy is acceptable and that it converges to a stable solution. We compare sequential and parallel versions of Loopy Belief Propagation with exact inference techniques for both static and dynamic analysis, showing the advantages and gains of approximate inference techniques when scaling to larger attack graphs.},
+journal = {ACM Trans. Priv. Secur.},
+month = {jul},
+articleno = {10},
+numpages = {30},
+keywords = {probabilistic graphical models, approximate inference, Bayesian networks}
+}
+
+@ARTICLE{8290918,
+author={Wang, Huan and Chen, Zhanfang and Zhao, Jianping and Di, Xiaoqiang and Liu, Dan}, 
+journal={IEEE Access}, 
+title={A Vulnerability Assessment Method in Industrial Internet of Things Based on Attack Graph and Maximum Flow},
+year={2018},
+volume={6},
+number={}, 
+pages={8599-8609},
+doi={10.1109/ACCESS.2018.2805690}
+}
+
+@inproceedings{centrality_based,
+author = {Gonda, Tom and Pascal, Tal and Puzis, Rami and Shani, Guy and Shapira, Bracha},
+year = {2018},
+month = {09},
+pages = {},
+title = {Analysis of Attack Graph Representations for Ranking Vulnerability Fixes},
+doi = {10.29007/2c1q}
+}

TC_Template/Schrick-Noah_AG-CG-SyncFire.aux

@@ -0,0 +1,100 @@
+\relax 
+\providecommand\babel@aux[2]{}
+\@nameuse{bbl@beforestart}
+\citation{phillips_graph-based_1998}
+\citation{schneier_modeling_1999}
+\citation{ou_scalable_2006}
+\citation{CPSIOT,ming_jo}
+\citation{10.1145/3105760}
+\citation{8290918}
+\citation{centrality_based}
+\citation{j_hale_compliance_nodate,baloyi_guidelines_2019,allman_complying_2006}
+\citation{sheyner_automated_2002}
+\citation{ou_scalable_2006}
+\citation{zhang_boosting_2017}
+\babel@aux{nil}{}
+\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}{}\protected@file@percent }
+\newlabel{sec:introduction}{{1}{1}}
+\citation{Monotonicity}
+\citation{TVA}
+\citation{ou_scalable_2006}
+\citation{louthan_hybrid_2011}
+\citation{louthan_hybrid_2011}
+\citation{louthan_hybrid_2011}
+\citation{louthan_hybrid_2011}
+\citation{louthan_hybrid_2011}
+\citation{cook_rage_2018}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Related Work}{2}{}\protected@file@percent }
+\newlabel{sec:sync-lit}{{2}{2}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}Inseparable Features}{2}{}\protected@file@percent }
+\newlabel{sec:inseparable}{{3}{2}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces A network without Synchronous Firing generating infeasible states}}{2}{}\protected@file@percent }
+\newlabel{fig:non-sync_ex}{{1}{2}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Implementing Synchronous Firing}{2}{}\protected@file@percent }
+\newlabel{sec:implementing}{{4}{2}}
+\citation{cook_rage_2018}
+\citation{louthan_hybrid_2011}
+\citation{nichols_2018}
+\citation{cook_rage_2018}
+\citation{cook_rage_2018}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}GNU Bison and Flex}{3}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}PostgreSQL}{3}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Inclusion of Synchronous Firing into GNU Bison, GNU Flex, and the overall program}}{3}{}\protected@file@percent }
+\newlabel{fig:bison-flex}{{2}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}Compound Operators}{3}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.4}Graph Generation}{4}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Synchronous Firing in the Graph Generation Process}}{4}{}\protected@file@percent }
+\newlabel{fig:sync-fire}{{3}{4}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Results}{4}{}\protected@file@percent }
+\newlabel{sec:Results}{{5}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Experimental Networks and Computing Platform}{4}{}\protected@file@percent }
+\newlabel{sec:test-platform}{{5.1}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Results and Analysis}{5}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.1}Results for the Theoretical Environment}{5}{}\protected@file@percent }
+\newlabel{sec:theo_res}{{5.2.1}{5}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces Synchronous Firing on Runtime}}{5}{}\protected@file@percent }
+\newlabel{fig:Sync-RT}{{4}{5}}
+\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Results for the Non-Synchronous Firing Testing}}{5}{}\protected@file@percent }
+\newlabel{table:NS-Table}{{1}{5}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.2}Results for a Grouped Environment}{5}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Bar Graph and Line Graph Representations of Synchronous Firing on State Space}}{6}{}\protected@file@percent }
+\newlabel{fig:Sync-State}{{5}{6}}
+\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Speedup (Amdahl's) Obtained When Using Synchronous Firing}}{6}{}\protected@file@percent }
+\newlabel{fig:Sync-Spd}{{6}{6}}
+\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Results for the Synchronous Firing Testing}}{6}{}\protected@file@percent }
+\newlabel{table:S-Table}{{2}{6}}
+\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces Results for the Comprehensive Services without Synchronous Firing}}{6}{}\protected@file@percent }
+\newlabel{table:Non-Sync-Comp-Table}{{3}{6}}
+\@writefile{toc}{\contentsline {section}{\numberline {6}Future Works}{6}{}\protected@file@percent }
+\newlabel{sec:fw}{{6}{6}}
+\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces Results for the Comprehensive Services with Synchronous Firing}}{7}{}\protected@file@percent }
+\newlabel{table:Sync-Comp-Table}{{4}{7}}
+\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Synchronous Firing on Runtime}}{7}{}\protected@file@percent }
+\newlabel{fig:Comp-Sync-RT}{{7}{7}}
+\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Bar Graph and Line Graph Representations of Synchronous Firing with Comprehensive Services on State Space}}{7}{}\protected@file@percent }
+\newlabel{fig:Comp-Sync-State}{{8}{7}}
+\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces Speedup (Amdahl's) Obtained When Using Synchronous Firing with Comprehensive Services}}{7}{}\protected@file@percent }
+\newlabel{fig:Comp-Sync-Spd}{{9}{7}}
+\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusion}{7}{}\protected@file@percent }
+\bibdata{Bibliography}
+\bibcite{phillips_graph-based_1998}{1}
+\bibcite{schneier_modeling_1999}{2}
+\bibcite{ou_scalable_2006}{3}
+\bibcite{CPSIOT}{4}
+\bibcite{ming_jo}{5}
+\bibcite{10.1145/3105760}{6}
+\bibcite{8290918}{7}
+\bibcite{centrality_based}{8}
+\bibcite{j_hale_compliance_nodate}{9}
+\bibcite{baloyi_guidelines_2019}{10}
+\bibcite{allman_complying_2006}{11}
+\bibcite{sheyner_automated_2002}{12}
+\bibcite{zhang_boosting_2017}{13}
+\bibcite{Monotonicity}{14}
+\bibcite{TVA}{15}
+\bibcite{louthan_hybrid_2011}{16}
+\bibcite{cook_rage_2018}{17}
+\bibcite{nichols_2018}{18}
+\bibstyle{ieeetr}
+\@writefile{toc}{\contentsline {section}{References}{8}{}\protected@file@percent }
+\gdef \@abspage@last{8}

TC_Template/Schrick-Noah_AG-CG-SyncFire.bbl

@@ -0,0 +1,95 @@
+\begin{thebibliography}{10}
+
+\bibitem{phillips_graph-based_1998}
+C.~Phillips and L.~P. Swiler, ``A graph-based system for network-vulnerability
+  analysis,'' {\em Proceedings New Security Paradigms Workshop}, vol.~Part
+  F1292, pp.~71--79, 1998.
+\newblock doi: 10.1145/310889.310919.
+
+\bibitem{schneier_modeling_1999}
+B.~Schneier, ``Modeling {Security} {Threats},'' {\em Dr. Dobb's Journal}, 1999.
+\newblock vol. 24, no.12.
+
+\bibitem{ou_scalable_2006}
+X.~Ou, W.~F. Boyer, and M.~A. Mcqueen, ``A {Scalable} {Approach} to {Attack}
+  {Graph} {Generation},'' {\em CCS '06: Proceedings of the 13th ACM conference
+  on Computer and communications security}, pp.~336--345, 2006.
+
+\bibitem{CPSIOT}
+A.~T. Al~Ghazo, M.~Ibrahim, H.~Ren, and R.~Kumar, ``A2g2v: Automated attack
+  graph generator and visualizer,'' in {\em Proceedings of the 1st ACM MobiHoc
+  Workshop on Mobile IoT Sensing, Security, and Privacy}, Mobile IoT SSP'18,
+  (New York, NY, USA), Association for Computing Machinery, 2018.
+
+\bibitem{ming_jo}
+M.~Li, P.~Hawrylak, and J.~Hale, ``Strategies for practical hybrid attack graph
+  generation and analysis,'' {\em Digital Threats}, oct 2021.
+\newblock Just Accepted.
+
+\bibitem{10.1145/3105760}
+L.~Mu\~{n}oz Gonz\'{a}lez, D.~Sgandurra, A.~Paudice, and E.~C. Lupu,
+  ``Efficient attack graph analysis through approximate inference,'' {\em ACM
+  Trans. Priv. Secur.}, vol.~20, jul 2017.
+
+\bibitem{8290918}
+H.~Wang, Z.~Chen, J.~Zhao, X.~Di, and D.~Liu, ``A vulnerability assessment
+  method in industrial internet of things based on attack graph and maximum
+  flow,'' {\em IEEE Access}, vol.~6, pp.~8599--8609, 2018.
+
+\bibitem{centrality_based}
+T.~Gonda, T.~Pascal, R.~Puzis, G.~Shani, and B.~Shapira, ``Analysis of attack
+  graph representations for ranking vulnerability fixes,'' 09 2018.
+
+\bibitem{j_hale_compliance_nodate}
+{J. Hale}, P.~Hawrylak, and M.~Papa, ``Compliance {Method} for a
+  {Cyber}-{Physical} {System}.''
+\newblock U.S. Patent Number 9,471,789, Oct. 18, 2016.
+
+\bibitem{baloyi_guidelines_2019}
+N.~Baloyi and P.~Kotzé, ``Guidelines for {Data} {Privacy} {Compliance}: {A}
+  {Focus} on {Cyberphysical} {Systems} and {Internet} of {Things},'' in {\em
+  {SAICSIT} '19: {Proceedings} of the {South} {African} {Institute} of
+  {Computer} {Scientists} and {Information} {Technologists} 2019}, (Skukuza
+  South Africa), Association for Computing Machinery, 2019.
+
+\bibitem{allman_complying_2006}
+E.~Allman, ``Complying with {Compliance}: {Blowing} it off is not an option.,''
+  {\em ACM Queue}, vol.~4, no.~7, 2006.
+
+\bibitem{sheyner_automated_2002}
+O.~Sheyner, J.~Haines, S.~Jha, R.~Lippmann, and J.~Wing, ``Automated
+  {Generation} and {Analysis} of {Attack} {Graphs},'' {\em Proceeding of 2002
+  IEEE Symposium on Security and Privacy}, pp.~254--265, 2002.
+
+\bibitem{zhang_boosting_2017}
+J.~Zhang, S.~Khoram, and J.~Li, ``Boosting the performance of {FPGA}-based
+  graph processor using hybrid memory cube: {A} case for breadth first
+  search,'' {\em FPGA 2017 - Proceedings of the 2017 ACM/SIGDA International
+  Symposium on Field-Programmable Gate Arrays}, pp.~207--216, 2017.
+
+\bibitem{Monotonicity}
+P.~Ammann, D.~Wijesekera, and S.~Kaushik, ``Scalable, graph-based network
+  vulnerability analysis,'' in {\em Proceedings of the 9th ACM Conference on
+  Computer and Communications Security}, CCS '02, (New York, NY, USA),
+  p.~217–224, Association for Computing Machinery, 2002.
+
+\bibitem{TVA}
+S.~Jajodia and S.~Noel, {\em Topological Vulnerability Analysis}, vol.~46,
+  pp.~139--154.
+\newblock 09 2010.
+
+\bibitem{louthan_hybrid_2011}
+G.~Louthan, {\em Hybrid {Attack} {Graphs} for {Modeling} {Cyber}-{Physical}
+  {Systems}}.
+\newblock PhD thesis, The {University} of {Tulsa}, 2011.
+
+\bibitem{cook_rage_2018}
+K.~Cook, {\em {RAGE}: {The} {Rage} {Attack} {Graph} {Engine}}.
+\newblock PhD thesis, The {University} of {Tulsa}, 2018.
+
+\bibitem{nichols_2018}
+W.~M. Nichols, {\em {Hybrid} {Attack} {Graphs} for {Use} with a {Simulation} of
+  a {Cyber-Physical} {System}}.
+\newblock PhD thesis, The {University} of {Tulsa}, 2018.
+
+\end{thebibliography}

TC_Template/Schrick-Noah_AG-CG-SyncFire.blg

@@ -0,0 +1,49 @@
+This is BibTeX, Version 0.99d (TeX Live 2022/Arch Linux)
+Capacity: max_strings=200000, hash_size=200000, hash_prime=170003
+The top-level auxiliary file: Schrick-Noah_AG-CG-SyncFire.aux
+The style file: ieeetr.bst
+Database file #1: Bibliography.bib
+Warning--empty booktitle in centrality_based
+Warning--empty publisher in TVA
+You've used 18 entries,
+            1876 wiz_defined-function locations,
+            581 strings with 6930 characters,
+and the built_in function-call counts, 4246 in all, are:
+= -- 415
+> -- 178
+< -- 0
++ -- 67
+- -- 49
+* -- 286
+:= -- 624
+add.period$ -- 25
+call.type$ -- 18
+change.case$ -- 14
+chr.to.int$ -- 0
+cite$ -- 20
+duplicate$ -- 230
+empty$ -- 405
+format.name$ -- 49
+if$ -- 1028
+int.to.chr$ -- 0
+int.to.str$ -- 18
+missing$ -- 15
+newline$ -- 65
+num.names$ -- 18
+pop$ -- 64
+preamble$ -- 1
+purify$ -- 0
+quote$ -- 0
+skip$ -- 138
+stack$ -- 0
+substring$ -- 202
+swap$ -- 82
+text.length$ -- 0
+text.prefix$ -- 0
+top$ -- 0
+type$ -- 0
+warning$ -- 2
+while$ -- 35
+width$ -- 20
+write$ -- 178
+(There were 2 warnings)

TC_Template/Schrick-Noah_AG-CG-SyncFire.log

@@ -0,0 +1,562 @@
+This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Arch Linux) (preloaded format=pdflatex 2022.10.25)  1 NOV 2022 12:22
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**Schrick-Noah_AG-CG-SyncFire.tex
+(./Schrick-Noah_AG-CG-SyncFire.tex
+LaTeX2e <2021-11-15> patch level 1
+L3 programming layer <2022-04-10>
+(/usr/share/texmf-dist/tex/latex/ieeetran/IEEEtran.cls
+Document Class: IEEEtran 2015/08/26 V1.8b by Michael Shell
+-- See the "IEEEtran_HOWTO" manual for usage information.
+-- http://www.michaelshell.org/tex/ieeetran/
+\@IEEEtrantmpdimenA=\dimen138
+\@IEEEtrantmpdimenB=\dimen139
+\@IEEEtrantmpdimenC=\dimen140
+\@IEEEtrantmpcountA=\count185
+\@IEEEtrantmpcountB=\count186
+\@IEEEtrantmpcountC=\count187
+\@IEEEtrantmptoksA=\toks16
+LaTeX Font Info:    Trying to load font information for OT1+ppl on input line 5
+03.
+(/usr/share/texmf-dist/tex/latex/psnfss/ot1ppl.fd
+File: ot1ppl.fd 2001/06/04 font definitions for OT1/ppl.
+)
+-- Using IEEE Computer Society mode.
+-- Using 8.5in x 11in (letter) paper.
+-- Using PDF output.
+\@IEEEnormalsizeunitybaselineskip=\dimen141
+-- This is a 10 point document.
+\CLASSINFOnormalsizebaselineskip=\dimen142
+\CLASSINFOnormalsizeunitybaselineskip=\dimen143
+\IEEEnormaljot=\dimen144
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <5.01874> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <5.01874> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <7.02625> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <7.02625> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <8.03> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <8.03> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <9.03374> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <9.03374> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <9.53561> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <9.53561> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <11.04124> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <11.04124> not available
+
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <12.045> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <12.045> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <17.06374> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <17.06374> not available
+
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <20.075> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <20.075> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+LaTeX Font Info:    Font shape `OT1/ppl/bx/n' in size <24.09> not available
+(Font)              Font shape `OT1/ppl/b/n' tried instead on input line 1090.
+LaTeX Font Info:    Font shape `OT1/ppl/bx/it' in size <24.09> not available
+(Font)              Font shape `OT1/ppl/b/it' tried instead on input line 1090.
+
+\IEEEquantizedlength=\dimen145
+\IEEEquantizedlengthdiff=\dimen146
+\IEEEquantizedtextheightdiff=\dimen147
+\IEEEilabelindentA=\dimen148
+\IEEEilabelindentB=\dimen149
+\IEEEilabelindent=\dimen150
+\IEEEelabelindent=\dimen151
+\IEEEdlabelindent=\dimen152
+\IEEElabelindent=\dimen153
+\IEEEiednormlabelsep=\dimen154
+\IEEEiedmathlabelsep=\dimen155
+\IEEEiedtopsep=\skip47
+\c@section=\count188
+\c@subsection=\count189
+\c@subsubsection=\count190
+\c@paragraph=\count191
+\c@IEEEsubequation=\count192
+\abovecaptionskip=\skip48
+\belowcaptionskip=\skip49
+\c@figure=\count193
+\c@table=\count194
+\@IEEEeqnnumcols=\count195
+\@IEEEeqncolcnt=\count196
+\@IEEEsubeqnnumrollback=\count197
+\@IEEEquantizeheightA=\dimen156
+\@IEEEquantizeheightB=\dimen157
+\@IEEEquantizeheightC=\dimen158
+\@IEEEquantizeprevdepth=\dimen159
+\@IEEEquantizemultiple=\count198
+\@IEEEquantizeboxA=\box50
+\@IEEEtmpitemindent=\dimen160
+\IEEEPARstartletwidth=\dimen161
+\c@IEEEbiography=\count199
+\@IEEEtranrubishbin=\box51
+) (/usr/share/texmf-dist/tex/latex/cite/cite.sty
+LaTeX Info: Redefining \cite on input line 302.
+LaTeX Info: Redefining \nocite on input line 332.
+Package: cite 2015/02/27  v 5.5
+)
+(/usr/share/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2021/09/16 v1.2d Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks17
+)
+(/usr/share/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2021/03/04 v1.4d Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2021/08/11 v1.11 sin cos tan (DPC)
+)
+(/usr/share/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
+)
+Package graphics Info: Driver file: pdftex.def on input line 107.
+
+(/usr/share/texmf-dist/tex/latex/graphics-def/pdftex.def
+File: pdftex.def 2020/10/05 v1.2a Graphics/color driver for pdftex
+))
+\Gin@req@height=\dimen162
+\Gin@req@width=\dimen163
+)
+(/usr/share/texmf-dist/tex/latex/spverbatim/spverbatim.sty
+Package: spverbatim 2009/08/10 v1.0 Verbatim with breakable spaces
+)
+(/usr/share/texmf-dist/tex/generic/babel/babel.sty
+Package: babel 2022/02/26 3.73 The Babel package
+\babel@savecnt=\count266
+\U@D=\dimen164
+\l@unhyphenated=\language87
+
+(/usr/share/texmf-dist/tex/generic/babel/txtbabel.def)
+\bbl@readstream=\read2
+\bbl@dirlevel=\count267
+Package babel Info: You haven't specified a language. I'll use 'nil'
+(babel)             as the main language. Reported on input line 4305.
+
+(/usr/share/texmf-dist/tex/generic/babel/nil.ldf
+Language: nil 2022/02/26 3.73 Nil language
+\l@nil=\language88
+))
+(/usr/share/texmf-dist/tex/latex/base/textcomp.sty
+Package: textcomp 2020/02/02 v2.0n Standard LaTeX package
+)
+(/usr/share/texmf-dist/tex/latex/base/inputenc.sty
+Package: inputenc 2021/02/14 v1.3d Input encoding file
+\inpenc@prehook=\toks18
+\inpenc@posthook=\toks19
+)
+(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+File: l3backend-pdftex.def 2022-04-14 L3 backend support: PDF output (pdfTeX)
+\l__color_backend_stack_int=\count268
+\l__pdf_internal_box=\box52
+)
+(./Schrick-Noah_AG-CG-SyncFire.aux)
+\openout1 = `Schrick-Noah_AG-CG-SyncFire.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 34.
+LaTeX Font Info:    ... okay on input line 34.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 34.
+LaTeX Font Info:    ... okay on input line 34.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 34.
+LaTeX Font Info:    ... okay on input line 34.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 34.
+LaTeX Font Info:    ... okay on input line 34.
+LaTeX Font Info:    Checking defaults for TS1/cmr/m/n on input line 34.
+LaTeX Font Info:    ... okay on input line 34.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 34.
+LaTeX Font Info:    ... okay on input line 34.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 34.
+LaTeX Font Info:    ... okay on input line 34.
+
+-- Lines per column: 61 (exact).
+(/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count269
+\scratchdimen=\dimen165
+\scratchbox=\box53
+\nofMPsegments=\count270
+\nofMParguments=\count271
+\everyMPshowfont=\toks20
+\MPscratchCnt=\count272
+\MPscratchDim=\dimen166
+\MPnumerator=\count273
+\makeMPintoPDFobject=\count274
+\everyMPtoPDFconversion=\toks21
+) (/usr/share/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+Package: epstopdf-base 2020-01-24 v2.11 Base part for package epstopdf
+
+(/usr/share/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+Package: infwarerr 2019/12/03 v1.5 Providing info/warning/error messages (HO)
+)
+(/usr/share/texmf-dist/tex/latex/grfext/grfext.sty
+Package: grfext 2019/12/03 v1.3 Manage graphics extensions (HO)
+
+(/usr/share/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+Package: kvdefinekeys 2019-12-19 v1.6 Define keys (HO)
+))
+(/usr/share/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+Package: kvoptions 2020-10-07 v3.14 Key value format for package options (HO)
+
+(/usr/share/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+Package: ltxcmds 2020-05-10 v1.25 LaTeX kernel commands for general use (HO)
+)
+(/usr/share/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty
+Package: kvsetkeys 2019/12/15 v1.18 Key value parser (HO)
+))
+(/usr/share/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+Package: pdftexcmds 2020-06-27 v0.33 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texmf-dist/tex/generic/iftex/iftex.sty
+Package: iftex 2022/02/03 v1.0f TeX engine tests
+)
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
+85.
+Package grfext Info: Graphics extension search list:
+(grfext)             [.pdf,.png,.jpg,.mps,.jpeg,.jbig2,.jb2,.PDF,.PNG,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 504.
+
+(/usr/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+LaTeX Font Info:    Trying to load font information for OT1+phv on input line 5
+3.
+
+(/usr/share/texmf-dist/tex/latex/psnfss/ot1phv.fd
+File: ot1phv.fd 2020/03/25 scalable font definitions for OT1/phv.
+)
+LaTeX Font Info:    Font shape `OT1/phv/m/it' in size <11.04124> not available
+(Font)              Font shape `OT1/phv/m/sl' tried instead on input line 53.
+LaTeX Font Info:    Calculating math sizes for size <11.04124> on input line 53
+.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <11.04124> on input line 53.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <7.72884> on input line 53.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5.52061> on input line 53.
+LaTeX Font Info:    Trying to load font information for U+pzd on input line 53.
+
+
+(/usr/share/texmf-dist/tex/latex/psnfss/upzd.fd
+File: upzd.fd 2001/06/04 font definitions for U/pzd.
+)
+Underfull \hbox (badness 1838) in paragraph at lines 61--65
+[]\OT1/ppl/m/n/9.53561 As an alternative to attack graphs for examining
+ []
+
+[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}
+
+
+]
+LaTeX Font Info:    Calculating math sizes for size <9.53561> on input line 72.
+
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <9.53561> on input line 72.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6.6749> on input line 72.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <4.7678> on input line 72.
+
+Underfull \hbox (badness 2680) in paragraph at lines 81--87
+\OT1/ppl/m/n/9.53561 are their exhaustiveness. The ability to generate all
+ []
+
+
+Underfull \hbox (badness 1917) in paragraph at lines 81--87
+\OT1/ppl/m/n/9.53561 realistic, as briefly mentioned in Section 2[]. When a
+ []
+
+
+Underfull \hbox (badness 1496) in paragraph at lines 81--87
+\OT1/ppl/m/n/9.53561 system has assets that have inseparable features, the
+ []
+
+<./images/non-sync_ex.drawio.png, id=11, 1014.79124pt x 400.49625pt>
+File: ./images/non-sync_ex.drawio.png Graphic file (type png)
+<use ./images/non-sync_ex.drawio.png>
+Package pdftex.def Info: ./images/non-sync_ex.drawio.png  used on input line 90
+.
+(pdftex.def)             Requested size: 227.64894pt x 89.83887pt.
+
+Underfull \hbox (badness 6927) in paragraph at lines 95--97
+[]\OT1/ppl/m/n/9.53561 Post-processing is one option at removing the
+ []
+
+
+Underfull \hbox (badness 1688) in paragraph at lines 95--97
+\OT1/ppl/m/n/9.53561 a post-processing step. Instead, a new feature called
+ []
+
+[2 <./images/non-sync_ex.drawio.png>]
+LaTeX Font Info:    Trying to load font information for OT1+pcr on input line 1
+05.
+
+(/usr/share/texmf-dist/tex/latex/psnfss/ot1pcr.fd
+File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
+)
+Underfull \hbox (badness 10000) in paragraph at lines 107--111
+
+ []
+
+
+Underfull \hbox (badness 2922) in paragraph at lines 107--111
+[]\OT1/ppl/m/n/9.53561 where the ``$\OML/cmm/m/it/10 <$\OT1/ppl/m/n/9.53561 gro
+up name$\OML/cmm/m/it/10 >$\OT1/ppl/m/n/9.53561 " identifier and ``group"
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 112--116
+
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 117--123
+
+ []
+
+<./images/vert_Bison-Flex.drawio.png, id=21, 551.05875pt x 710.655pt>
+File: ./images/vert_Bison-Flex.drawio.png Graphic file (type png)
+<use ./images/vert_Bison-Flex.drawio.png>
+Package pdftex.def Info: ./images/vert_Bison-Flex.drawio.png  used on input lin
+e 126.
+(pdftex.def)             Requested size: 180.67499pt x 232.99875pt.
+
+Underfull \hbox (badness 1960) in paragraph at lines 137--140
+\OT1/ppl/m/n/9.53561 Many of the graphs previously generated by RAGE
+ []
+
+
+Underfull \hbox (badness 3439) in paragraph at lines 137--140
+\OT1/ppl/m/n/9.53561 comprise of states with features that can be fully
+ []
+
+
+Underfull \hbox (badness 1400) in paragraph at lines 141--142
+[]\OT1/ppl/m/n/9.53561 The work conducted by the author of [17] when
+ []
+
+[3 <./images/vert_Bison-Flex.drawio.png>]
+Underfull \hbox (badness 2781) in paragraph at lines 147--148
+[]\OT1/ppl/m/n/9.53561 Other changes involved updating classes (namely
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 147--148
+\OT1/ppl/m/n/9.53561 the Quality, EncodedQuality, ParameterizedQuality,
+ []
+
+
+Underfull \hbox (badness 6510) in paragraph at lines 147--148
+\OT1/ppl/m/n/9.53561 NetworkState, and Keyvalue classes) to include a
+ []
+
+<./images/Sync-Fire.png, id=28, 489.83pt x 1053.9375pt>
+File: ./images/Sync-Fire.png Graphic file (type png)
+<use ./images/Sync-Fire.png>
+Package pdftex.def Info: ./images/Sync-Fire.png  used on input line 154.
+(pdftex.def)             Requested size: 244.9144pt x 526.96747pt.
+
+Underfull \hbox (badness 3138) in paragraph at lines 174--175
+\OT1/ppl/m/n/9.53561 All nodes are connected with a 10Gbps Infiniband
+ []
+
+[4 <./images/Sync-Fire.png>]
+Underfull \hbox (badness 1371) in paragraph at lines 185--186
+[]\OT1/ppl/m/n/9.53561 All cases used the same exploit file, with the
+ []
+
+
+Underfull \hbox (badness 2913) in paragraph at lines 187--188
+[]\OT1/ppl/m/n/9.53561 Graph visualization was not timed. Only the
+ []
+
+
+Underfull \hbox (badness 5756) in paragraph at lines 187--188
+\OT1/ppl/m/n/9.53561 generation and database operation time was
+ []
+
+LaTeX Font Info:    Font shape `OT1/phv/m/it' in size <9.53561> not available
+(Font)              Font shape `OT1/phv/m/sl' tried instead on input line 201.
+
+Underfull \hbox (badness 1708) in paragraph at lines 204--205
+\OT1/ppl/m/n/9.53561 corresponds with the growing number of states and
+ []
+
+<./images/Sync-Runtime-Bar.png, id=35, 602.25pt x 238.491pt>
+File: ./images/Sync-Runtime-Bar.png Graphic file (type png)
+<use ./images/Sync-Runtime-Bar.png>
+Package pdftex.def Info: ./images/Sync-Runtime-Bar.png  used on input line 210.
+
+(pdftex.def)             Requested size: 252.94499pt x 100.16553pt.
+<./images/Sync-Runtime-Exp.png, id=36, 549.69pt x 236.301pt>
+File: ./images/Sync-Runtime-Exp.png Graphic file (type png)
+<use ./images/Sync-Runtime-Exp.png>
+Package pdftex.def Info: ./images/Sync-Runtime-Exp.png  used on input line 211.
+
+(pdftex.def)             Requested size: 252.94499pt x 108.73582pt.
+<./images/Sync-StateSpace-Bar.png, id=37, 608.163pt x 223.38pt>
+File: ./images/Sync-StateSpace-Bar.png Graphic file (type png)
+<use ./images/Sync-StateSpace-Bar.png>
+Package pdftex.def Info: ./images/Sync-StateSpace-Bar.png  used on input line 2
+18.
+(pdftex.def)             Requested size: 252.94499pt x 92.90547pt.
+<./images/Sync-StateSpace-Exp.png, id=38, 532.827pt x 236.739pt>
+File: ./images/Sync-StateSpace-Exp.png Graphic file (type png)
+<use ./images/Sync-StateSpace-Exp.png>
+Package pdftex.def Info: ./images/Sync-StateSpace-Exp.png  used on input line 2
+19.
+(pdftex.def)             Requested size: 252.94499pt x 112.38716pt.
+<./images/Sync_Speedup.png, id=39, 533.265pt x 236.301pt>
+File: ./images/Sync_Speedup.png Graphic file (type png)
+<use ./images/Sync_Speedup.png>
+Package pdftex.def Info: ./images/Sync_Speedup.png  used on input line 226.
+(pdftex.def)             Requested size: 252.94499pt x 112.08548pt.
+LaTeX Font Info:    Calculating math sizes for size <8.03> on input line 236.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8.03> on input line 236.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5.62097> on input line 236.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <4.015> on input line 236.
+[5 <./images/Sync-Runtime-Bar.png> <./images/Sync-Runtime-Exp.png>]
+Underfull \hbox (badness 2012) in paragraph at lines 285--286
+\OT1/ppl/m/n/9.53561 firing enabled generation, and Table 3[] for the non-
+ []
+
+<./images/Comp-Sync-Runtime-Bar.png, id=45, 602.25pt x 238.491pt>
+File: ./images/Comp-Sync-Runtime-Bar.png Graphic file (type png)
+<use ./images/Comp-Sync-Runtime-Bar.png>
+Package pdftex.def Info: ./images/Comp-Sync-Runtime-Bar.png  used on input line
+ 338.
+(pdftex.def)             Requested size: 252.94499pt x 100.16553pt.
+<./images/Comp-Sync-Runtime-Exp.png, id=46, 549.69pt x 236.301pt>
+File: ./images/Comp-Sync-Runtime-Exp.png Graphic file (type png)
+<use ./images/Comp-Sync-Runtime-Exp.png>
+Package pdftex.def Info: ./images/Comp-Sync-Runtime-Exp.png  used on input line
+ 339.
+(pdftex.def)             Requested size: 252.94499pt x 108.73582pt.
+<./images/Comp-Sync-StateSpace-Bar.png, id=47, 600.717pt x 230.607pt>
+File: ./images/Comp-Sync-StateSpace-Bar.png Graphic file (type png)
+<use ./images/Comp-Sync-StateSpace-Bar.png>
+Package pdftex.def Info: ./images/Comp-Sync-StateSpace-Bar.png  used on input l
+ine 346.
+(pdftex.def)             Requested size: 252.94499pt x 97.10059pt.
+<./images/Comp-Sync-StateSpace-Exp.png, id=48, 532.389pt x 236.739pt>
+File: ./images/Comp-Sync-StateSpace-Exp.png Graphic file (type png)
+<use ./images/Comp-Sync-StateSpace-Exp.png>
+Package pdftex.def Info: ./images/Comp-Sync-StateSpace-Exp.png  used on input l
+ine 347.
+(pdftex.def)             Requested size: 252.94499pt x 112.47746pt.
+<./images/Comp-Sync_Speedup.png, id=49, 533.265pt x 236.301pt>
+File: ./images/Comp-Sync_Speedup.png Graphic file (type png)
+<use ./images/Comp-Sync_Speedup.png>
+Package pdftex.def Info: ./images/Comp-Sync_Speedup.png  used on input line 354
+.
+(pdftex.def)             Requested size: 252.94499pt x 112.08548pt.
+
+Underfull \hbox (badness 4242) in paragraph at lines 361--362
+\OT1/ppl/m/n/9.53561 additional unattainable states. Future works include
+ []
+
+[6 <./images/Sync-StateSpace-Bar.png> <./images/Sync-StateSpace-Exp.png> <./ima
+ges/Sync_Speedup.png>]
+Underfull \hbox (badness 4621) in paragraph at lines 365--366
+[]\OT1/ppl/m/n/9.53561 Introducing service heuristics could improve the
+ []
+
+
+Underfull \hbox (badness 3780) in paragraph at lines 365--366
+\OT1/ppl/m/n/9.53561 characteristics of synchronous firing. If services are
+ []
+
+[7 <./images/Comp-Sync-Runtime-Bar.png> <./images/Comp-Sync-Runtime-Exp.png> <.
+/images/Comp-Sync-StateSpace-Bar.png> <./images/Comp-Sync-StateSpace-Exp.png> <
+./images/Comp-Sync_Speedup.png>] (./Schrick-Noah_AG-CG-SyncFire.bbl
+Underfull \hbox (badness 7777) in paragraph at lines 4--8
+[]\OT1/ppl/m/n/8.03 C. Phillips and L. P. Swiler, ``A graph-based system
+ []
+
+
+Underfull \hbox (badness 1496) in paragraph at lines 4--8
+\OT1/ppl/m/n/8.03 for network-vulnerability analysis,'' \OT1/ppl/m/it/8.03 Proc
+eedings New Security
+ []
+
+
+Underfull \hbox (badness 1354) in paragraph at lines 49--54
+\OT1/ppl/m/n/8.03 in \OT1/ppl/m/it/8.03 SAICSIT '19: Proceedings of the South A
+frican Institute of
+ []
+
+
+Underfull \hbox (badness 1354) in paragraph at lines 60--63
+[]\OT1/ppl/m/n/8.03 O. Sheyner, J. Haines, S. Jha, R. Lippmann, and J. Wing,
+ []
+
+
+Underfull \hbox (badness 3417) in paragraph at lines 60--63
+\OT1/ppl/m/n/8.03 ``Automated Generation and Analysis of Attack Graphs,''
+ []
+
+) [8] (./Schrick-Noah_AG-CG-SyncFire.aux) ) 
+Here is how much of TeX's memory you used:
+ 4164 strings out of 478238
+ 77060 string characters out of 5850455
+ 398926 words of memory out of 5000000
+ 22328 multiletter control sequences out of 15000+600000
+ 514786 words of font info for 114 fonts, out of 8000000 for 9000
+ 1141 hyphenation exceptions out of 8191
+ 60i,14n,67p,1197b,373s stack positions out of 5000i,500n,10000p,200000b,80000s
+{/usr/share/texmf-dist/fonts/enc/dvi
+ps/base/8r.enc}</usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb
+></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/share/te
+xmf-dist/fonts/type1/public/amsfonts/cm/cmr7.pfb></usr/share/texmf-dist/fonts/t
+ype1/public/amsfonts/cm/cmsy10.pfb></usr/share/texmf-dist/fonts/type1/public/am
+sfonts/cm/cmsy7.pfb></usr/share/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb><
+/usr/share/texmf-dist/fonts/type1/urw/helvetic/uhvb8a.pfb></usr/share/texmf-dis
+t/fonts/type1/urw/helvetic/uhvr8a.pfb></usr/share/texmf-dist/fonts/type1/urw/he
+lvetic/uhvro8a.pfb></usr/share/texmf-dist/fonts/type1/urw/palatino/uplb8a.pfb><
+/usr/share/texmf-dist/fonts/type1/urw/palatino/uplr8a.pfb></usr/share/texmf-dis
+t/fonts/type1/urw/palatino/uplri8a.pfb></usr/share/texmf-dist/fonts/type1/urw/z
+apfding/uzdr.pfb>
+Output written on Schrick-Noah_AG-CG-SyncFire.pdf (8 pages, 919914 bytes).
+PDF statistics:
+ 124 PDF objects out of 1000 (max. 8388607)
+ 61 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 66 words of extra memory for PDF output out of 10000 (max. 10000000)
+

TC_Template/Schrick-Noah_AG-CG-SyncFire.out

@@ -0,0 +1,16 @@
+\BOOKMARK [1][-]{section.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}% 1
+\BOOKMARK [1][-]{section.2}{\376\377\000R\000e\000l\000a\000t\000e\000d\000\040\000W\000o\000r\000k}{}% 2
+\BOOKMARK [1][-]{section.3}{\376\377\000I\000n\000s\000e\000p\000a\000r\000a\000b\000l\000e\000\040\000F\000e\000a\000t\000u\000r\000e\000s}{}% 3
+\BOOKMARK [1][-]{section.4}{\376\377\000I\000m\000p\000l\000e\000m\000e\000n\000t\000i\000n\000g\000\040\000S\000y\000n\000c\000h\000r\000o\000n\000o\000u\000s\000\040\000F\000i\000r\000i\000n\000g}{}% 4
+\BOOKMARK [2][-]{subsection.4.1}{\376\377\000G\000N\000U\000\040\000B\000i\000s\000o\000n\000\040\000a\000n\000d\000\040\000F\000l\000e\000x}{section.4}% 5
+\BOOKMARK [2][-]{subsection.4.2}{\376\377\000P\000o\000s\000t\000g\000r\000e\000S\000Q\000L}{section.4}% 6
+\BOOKMARK [2][-]{subsection.4.3}{\376\377\000C\000o\000m\000p\000o\000u\000n\000d\000\040\000O\000p\000e\000r\000a\000t\000o\000r\000s}{section.4}% 7
+\BOOKMARK [2][-]{subsection.4.4}{\376\377\000G\000r\000a\000p\000h\000\040\000G\000e\000n\000e\000r\000a\000t\000i\000o\000n}{section.4}% 8
+\BOOKMARK [1][-]{section.5}{\376\377\000R\000e\000s\000u\000l\000t\000s}{}% 9
+\BOOKMARK [2][-]{subsection.5.1}{\376\377\000E\000x\000p\000e\000r\000i\000m\000e\000n\000t\000a\000l\000\040\000N\000e\000t\000w\000o\000r\000k\000s\000\040\000a\000n\000d\000\040\000C\000o\000m\000p\000u\000t\000i\000n\000g\000\040\000P\000l\000a\000t\000f\000o\000r\000m}{section.5}% 10
+\BOOKMARK [2][-]{subsection.5.2}{\376\377\000R\000e\000s\000u\000l\000t\000s\000\040\000a\000n\000d\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{section.5}% 11
+\BOOKMARK [3][-]{subsubsection.5.2.1}{\376\377\000R\000e\000s\000u\000l\000t\000s\000\040\000f\000o\000r\000\040\000t\000h\000e\000\040\000T\000h\000e\000o\000r\000e\000t\000i\000c\000a\000l\000\040\000E\000n\000v\000i\000r\000o\000n\000m\000e\000n\000t}{subsection.5.2}% 12
+\BOOKMARK [3][-]{subsubsection.5.2.2}{\376\377\000R\000e\000s\000u\000l\000t\000s\000\040\000f\000o\000r\000\040\000a\000\040\000G\000r\000o\000u\000p\000e\000d\000\040\000E\000n\000v\000i\000r\000o\000n\000m\000e\000n\000t}{subsection.5.2}% 13
+\BOOKMARK [1][-]{section.6}{\376\377\000F\000u\000t\000u\000r\000e\000\040\000W\000o\000r\000k\000s}{}% 14
+\BOOKMARK [1][-]{section.7}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n}{}% 15
+\BOOKMARK [1][-]{section*.1}{\376\377\000R\000e\000f\000e\000r\000e\000n\000c\000e\000s}{}% 16

TC_Template/Schrick-Noah_AG-CG-SyncFire.tex

@@ -0,0 +1,374 @@
+\documentclass[10pt,journal,compsoc]{IEEEtran}
+%\IEEEoverridecommandlockouts
+% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
+
+% IEEE Computer Society needs nocompress option
+\usepackage[nocompress]{cite}
+%\usepackage{cite}
+%\usepackage{amsmath,amssymb,amsfonts}
+%\usepackage{algorithmic}
+\usepackage[pdftex]{graphicx}
+\usepackage{spverbatim} % Break long verbatim lines
+\graphicspath{ {./images/} }
+\usepackage{babel} % Bibliography
+\usepackage{textcomp}
+\usepackage[utf8]{inputenc}
+
+%\usepackage{float}
+%\floatstyle{plaintop}
+%\restylefloat{table}
+
+%\usepackage{xcolor}
+%\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
+%    T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
+
+%\usepackage[hidelinks]{hyperref} % Clickable TOC Links
+%\hypersetup{
+%    colorlinks,
+%    citecolor=black,
+%    filecolor=black,
+%    linkcolor=black,
+%    urlcolor=black
+%}
+    
+\begin{document}
+
+\title{State Space Explosion Mitigation for Large-Scale Attack and Compliance Graphs Using Synchronous Exploit Firing
+}
+
+\author{Noah~L.~Schrick,~\IEEEmembership{Member,~IEEE,}
+        and~Peter~J.~Hawrylak,~\IEEEmembership{Member,~IEEE,}
+}
+
+\IEEEtitleabstractindextext{
+    \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 Graph; Synchronous Firing; High-Performance Computing; Cybersecurity; Compliance and Regulation; Speedup;
+    \end{IEEEkeywords}
+}
+
+\maketitle
+
+\IEEEraisesectionheading{\section{Introduction}\label{sec:introduction}}
+%\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}. 
+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 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++.
+
+\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/non-sync_ex.drawio.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}
+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. The subsections in this Section describe 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. 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/vert_Bison-Flex.drawio.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/Sync-Fire.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.
+
+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}
+
+\subsection{Results and Analysis}
+\subsubsection{Results for the Theoretical 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. These 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. 
+
+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.5in]{"./images/Sync-Runtime-Bar.png"}
+    \includegraphics[width=3.5in]{"./images/Sync-Runtime-Exp.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.5in]{"./images/Sync-StateSpace-Bar.png"}
+    \includegraphics[width=3.5in]{"./images/Sync-StateSpace-Exp.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.5in]{"./images/Sync_Speedup.png"}
+        \caption{Speedup (Amdahl's) 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\tabcolsep{4pt}
+    \begin{tabular}{|c|c|c|c|c|c|}
+        \hline
+        \multicolumn{6}{|c|}{Synchronous Firing} \\ \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}} 
+        \\ \hline
+            1    & 6277      & 3.46E04    & 1.48E04    & 5.507    & 5.87 \\ \hline
+            2    & 11653     & 6.94E04    & 2.92E04    & 5.954    & 3.96 \\ \hline
+            3    & 25317     & 1.60E05    & 6.68E04    & 6.321    & 2.76 \\ \hline
+            4    & 36949     & 2.42E05    & 1.02E05    & 6.538    & 2.47 \\ \hline
+            5    & 83134     & 5.71E05    & 2.44E05    & 6.868    & 2.42 \\ \hline
+            6    & 186679    & 1.35E06    & 5.82E05    & 7.209    & 2.72 \\ \hline
+    \end{tabular}
+\end{table} 
+
+\subsubsection{Results for a Grouped 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
+    \includegraphics[width=3.5in]{"./images/Comp-Sync-Runtime-Bar.png"}
+    \includegraphics[width=3.5in]{"./images/Comp-Sync-Runtime-Exp.png"}
+    \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
+    \includegraphics[width=3.5in]{"./images/Comp-Sync-StateSpace-Bar.png"}
+    \includegraphics[width=3.5in]{"./images/Comp-Sync-StateSpace-Exp.png"}
+    \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
+    \includegraphics[width=3.5in]{"./images/Comp-Sync_Speedup.png"}
+        \caption{Speedup (Amdahl's) Obtained When Using Synchronous Firing with Comprehensive Services}
+        \label{fig:Comp-Sync-Spd}
+\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.
+
+%\bibliographyp
+\bibliography{Bibliography}
+\bibliographystyle{ieeetr}
+
+\end{document}

TC_Template/bare_jrnl_compsoc.tex

@@ -0,0 +1,787 @@
+
+%% bare_jrnl_compsoc.tex
+%% V1.4b
+%% 2015/08/26
+%% by Michael Shell
+%% See:
+%% http://www.michaelshell.org/
+%% for current contact information.
+%%
+%% This is a skeleton file demonstrating the use of IEEEtran.cls
+%% (requires IEEEtran.cls version 1.8b or later) with an IEEE
+%% Computer Society journal paper.
+%%
+%% Support sites:
+%% http://www.michaelshell.org/tex/ieeetran/
+%% http://www.ctan.org/pkg/ieeetran
+%% and
+%% http://www.ieee.org/
+
+%%*************************************************************************
+%% Legal Notice:
+%% This code is offered as-is without any warranty either expressed or
+%% implied; without even the implied warranty of MERCHANTABILITY or
+%% FITNESS FOR A PARTICULAR PURPOSE! 
+%% User assumes all risk.
+%% In no event shall the IEEE or any contributor to this code be liable for
+%% any damages or losses, including, but not limited to, incidental,
+%% consequential, or any other damages, resulting from the use or misuse
+%% of any information contained here.
+%%
+%% All comments are the opinions of their respective authors and are not
+%% necessarily endorsed by the IEEE.
+%%
+%% This work is distributed under the LaTeX Project Public License (LPPL)
+%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
+%% distributed and modified. A copy of the LPPL, version 1.3, is included
+%% in the base LaTeX documentation of all distributions of LaTeX released
+%% 2003/12/01 or later.
+%% Retain all contribution notices and credits.
+%% ** Modified files should be clearly indicated as such, including  **
+%% ** renaming them and changing author support contact information. **
+%%*************************************************************************
+
+
+% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
+% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
+% *** with production work. The IEEE's font choices and paper sizes can   ***
+% *** trigger bugs that do not appear when using other class files.       ***                          ***
+% The testflow support page is at:
+% http://www.michaelshell.org/tex/testflow/
+
+
+\documentclass[10pt,journal,compsoc]{IEEEtran}
+%
+% If IEEEtran.cls has not been installed into the LaTeX system files,
+% manually specify the path to it like:
+% \documentclass[10pt,journal,compsoc]{../sty/IEEEtran}
+
+
+
+
+
+% Some very useful LaTeX packages include:
+% (uncomment the ones you want to load)
+
+
+% *** MISC UTILITY PACKAGES ***
+%
+%\usepackage{ifpdf}
+% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
+% compilation based on whether the output is pdf or dvi.
+% usage:
+% \ifpdf
+%   % pdf code
+% \else
+%   % dvi code
+% \fi
+% The latest version of ifpdf.sty can be obtained from:
+% http://www.ctan.org/pkg/ifpdf
+% Also, note that IEEEtran.cls V1.7 and later provides a builtin
+% \ifCLASSINFOpdf conditional that works the same way.
+% When switching from latex to pdflatex and vice-versa, the compiler may
+% have to be run twice to clear warning/error messages.
+
+
+
+
+
+
+% *** CITATION PACKAGES ***
+%
+\ifCLASSOPTIONcompsoc
+  % IEEE Computer Society needs nocompress option
+  % requires cite.sty v4.0 or later (November 2003)
+  \usepackage[nocompress]{cite}
+\else
+  % normal IEEE
+  \usepackage{cite}
+\fi
+% cite.sty was written by Donald Arseneau
+% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
+% \cite{} output to follow that of the IEEE. Loading the cite package will
+% result in citation numbers being automatically sorted and properly
+% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
+% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
+% \cite will automatically add leading space, if needed. Use cite.sty's
+% noadjust option (cite.sty V3.8 and later) if you want to turn this off
+% such as if a citation ever needs to be enclosed in parenthesis.
+% cite.sty is already installed on most LaTeX systems. Be sure and use
+% version 5.0 (2009-03-20) and later if using hyperref.sty.
+% The latest version can be obtained at:
+% http://www.ctan.org/pkg/cite
+% The documentation is contained in the cite.sty file itself.
+%
+% Note that some packages require special options to format as the Computer
+% Society requires. In particular, Computer Society  papers do not use
+% compressed citation ranges as is done in typical IEEE papers
+% (e.g., [1]-[4]). Instead, they list every citation separately in order
+% (e.g., [1], [2], [3], [4]). To get the latter we need to load the cite
+% package with the nocompress option which is supported by cite.sty v4.0
+% and later. Note also the use of a CLASSOPTION conditional provided by
+% IEEEtran.cls V1.7 and later.
+
+
+
+
+
+% *** GRAPHICS RELATED PACKAGES ***
+%
+\ifCLASSINFOpdf
+  % \usepackage[pdftex]{graphicx}
+  % declare the path(s) where your graphic files are
+  % \graphicspath{{../pdf/}{../jpeg/}}
+  % and their extensions so you won't have to specify these with
+  % every instance of \includegraphics
+  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
+\else
+  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
+  % will default to the driver specified in the system graphics.cfg if no
+  % driver is specified.
+  % \usepackage[dvips]{graphicx}
+  % declare the path(s) where your graphic files are
+  % \graphicspath{{../eps/}}
+  % and their extensions so you won't have to specify these with
+  % every instance of \includegraphics
+  % \DeclareGraphicsExtensions{.eps}
+\fi
+% graphicx was written by David Carlisle and Sebastian Rahtz. It is
+% required if you want graphics, photos, etc. graphicx.sty is already
+% installed on most LaTeX systems. The latest version and documentation
+% can be obtained at: 
+% http://www.ctan.org/pkg/graphicx
+% Another good source of documentation is "Using Imported Graphics in
+% LaTeX2e" by Keith Reckdahl which can be found at:
+% http://www.ctan.org/pkg/epslatex
+%
+% latex, and pdflatex in dvi mode, support graphics in encapsulated
+% postscript (.eps) format. pdflatex in pdf mode supports graphics
+% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
+% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
+% not a bitmapped formats (.jpeg, .png). The IEEE frowns on bitmapped formats
+% which can result in "jaggedy"/blurry rendering of lines and letters as
+% well as large increases in file sizes.
+%
+% You can find documentation about the pdfTeX application at:
+% http://www.tug.org/applications/pdftex
+
+
+
+
+
+
+% *** MATH PACKAGES ***
+%
+%\usepackage{amsmath}
+% A popular package from the American Mathematical Society that provides
+% many useful and powerful commands for dealing with mathematics.
+%
+% Note that the amsmath package sets \interdisplaylinepenalty to 10000
+% thus preventing page breaks from occurring within multiline equations. Use:
+%\interdisplaylinepenalty=2500
+% after loading amsmath to restore such page breaks as IEEEtran.cls normally
+% does. amsmath.sty is already installed on most LaTeX systems. The latest
+% version and documentation can be obtained at:
+% http://www.ctan.org/pkg/amsmath
+
+
+
+
+
+% *** SPECIALIZED LIST PACKAGES ***
+%
+%\usepackage{algorithmic}
+% algorithmic.sty was written by Peter Williams and Rogerio Brito.
+% This package provides an algorithmic environment fo describing algorithms.
+% You can use the algorithmic environment in-text or within a figure
+% environment to provide for a floating algorithm. Do NOT use the algorithm
+% floating environment provided by algorithm.sty (by the same authors) or
+% algorithm2e.sty (by Christophe Fiorio) as the IEEE does not use dedicated
+% algorithm float types and packages that provide these will not provide
+% correct IEEE style captions. The latest version and documentation of
+% algorithmic.sty can be obtained at:
+% http://www.ctan.org/pkg/algorithms
+% Also of interest may be the (relatively newer and more customizable)
+% algorithmicx.sty package by Szasz Janos:
+% http://www.ctan.org/pkg/algorithmicx
+
+
+
+
+% *** ALIGNMENT PACKAGES ***
+%
+%\usepackage{array}
+% Frank Mittelbach's and David Carlisle's array.sty patches and improves
+% the standard LaTeX2e array and tabular environments to provide better
+% appearance and additional user controls. As the default LaTeX2e table
+% generation code is lacking to the point of almost being broken with
+% respect to the quality of the end results, all users are strongly
+% advised to use an enhanced (at the very least that provided by array.sty)
+% set of table tools. array.sty is already installed on most systems. The
+% latest version and documentation can be obtained at:
+% http://www.ctan.org/pkg/array
+
+
+% IEEEtran contains the IEEEeqnarray family of commands that can be used to
+% generate multiline equations as well as matrices, tables, etc., of high
+% quality.
+
+
+
+
+% *** SUBFIGURE PACKAGES ***
+%\ifCLASSOPTIONcompsoc
+%  \usepackage[caption=false,font=footnotesize,labelfont=sf,textfont=sf]{subfig}
+%\else
+%  \usepackage[caption=false,font=footnotesize]{subfig}
+%\fi
+% subfig.sty, written by Steven Douglas Cochran, is the modern replacement
+% for subfigure.sty, the latter of which is no longer maintained and is
+% incompatible with some LaTeX packages including fixltx2e. However,
+% subfig.sty requires and automatically loads Axel Sommerfeldt's caption.sty
+% which will override IEEEtran.cls' handling of captions and this will result
+% in non-IEEE style figure/table captions. To prevent this problem, be sure
+% and invoke subfig.sty's "caption=false" package option (available since
+% subfig.sty version 1.3, 2005/06/28) as this is will preserve IEEEtran.cls
+% handling of captions.
+% Note that the Computer Society format requires a sans serif font rather
+% than the serif font used in traditional IEEE formatting and thus the need
+% to invoke different subfig.sty package options depending on whether
+% compsoc mode has been enabled.
+%
+% The latest version and documentation of subfig.sty can be obtained at:
+% http://www.ctan.org/pkg/subfig
+
+
+
+
+% *** FLOAT PACKAGES ***
+%
+%\usepackage{fixltx2e}
+% fixltx2e, the successor to the earlier fix2col.sty, was written by
+% Frank Mittelbach and David Carlisle. This package corrects a few problems
+% in the LaTeX2e kernel, the most notable of which is that in current
+% LaTeX2e releases, the ordering of single and double column floats is not
+% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
+% single column figure to be placed prior to an earlier double column
+% figure.
+% Be aware that LaTeX2e kernels dated 2015 and later have fixltx2e.sty's
+% corrections already built into the system in which case a warning will
+% be issued if an attempt is made to load fixltx2e.sty as it is no longer
+% needed.
+% The latest version and documentation can be found at:
+% http://www.ctan.org/pkg/fixltx2e
+
+
+%\usepackage{stfloats}
+% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
+% the ability to do double column floats at the bottom of the page as well
+% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
+% LaTeX2e). It also provides a command:
+%\fnbelowfloat
+% to enable the placement of footnotes below bottom floats (the standard
+% LaTeX2e kernel puts them above bottom floats). This is an invasive package
+% which rewrites many portions of the LaTeX2e float routines. It may not work
+% with other packages that modify the LaTeX2e float routines. The latest
+% version and documentation can be obtained at:
+% http://www.ctan.org/pkg/stfloats
+% Do not use the stfloats baselinefloat ability as the IEEE does not allow
+% \baselineskip to stretch. Authors submitting work to the IEEE should note
+% that the IEEE rarely uses double column equations and that authors should try
+% to avoid such use. Do not be tempted to use the cuted.sty or midfloat.sty
+% packages (also by Sigitas Tolusis) as the IEEE does not format its papers in
+% such ways.
+% Do not attempt to use stfloats with fixltx2e as they are incompatible.
+% Instead, use Morten Hogholm'a dblfloatfix which combines the features
+% of both fixltx2e and stfloats:
+%
+% \usepackage{dblfloatfix}
+% The latest version can be found at:
+% http://www.ctan.org/pkg/dblfloatfix
+
+
+
+
+%\ifCLASSOPTIONcaptionsoff
+%  \usepackage[nomarkers]{endfloat}
+% \let\MYoriglatexcaption\caption
+% \renewcommand{\caption}[2][\relax]{\MYoriglatexcaption[#2]{#2}}
+%\fi
+% endfloat.sty was written by James Darrell McCauley, Jeff Goldberg and 
+% Axel Sommerfeldt. This package may be useful when used in conjunction with 
+% IEEEtran.cls'  captionsoff option. Some IEEE journals/societies require that
+% submissions have lists of figures/tables at the end of the paper and that
+% figures/tables without any captions are placed on a page by themselves at
+% the end of the document. If needed, the draftcls IEEEtran class option or
+% \CLASSINPUTbaselinestretch interface can be used to increase the line
+% spacing as well. Be sure and use the nomarkers option of endfloat to
+% prevent endfloat from "marking" where the figures would have been placed
+% in the text. The two hack lines of code above are a slight modification of
+% that suggested by in the endfloat docs (section 8.4.1) to ensure that
+% the full captions always appear in the list of figures/tables - even if
+% the user used the short optional argument of \caption[]{}.
+% IEEE papers do not typically make use of \caption[]'s optional argument,
+% so this should not be an issue. A similar trick can be used to disable
+% captions of packages such as subfig.sty that lack options to turn off
+% the subcaptions:
+% For subfig.sty:
+% \let\MYorigsubfloat\subfloat
+% \renewcommand{\subfloat}[2][\relax]{\MYorigsubfloat[]{#2}}
+% However, the above trick will not work if both optional arguments of
+% the \subfloat command are used. Furthermore, there needs to be a
+% description of each subfigure *somewhere* and endfloat does not add
+% subfigure captions to its list of figures. Thus, the best approach is to
+% avoid the use of subfigure captions (many IEEE journals avoid them anyway)
+% and instead reference/explain all the subfigures within the main caption.
+% The latest version of endfloat.sty and its documentation can obtained at:
+% http://www.ctan.org/pkg/endfloat
+%
+% The IEEEtran \ifCLASSOPTIONcaptionsoff conditional can also be used
+% later in the document, say, to conditionally put the References on a 
+% page by themselves.
+
+
+
+
+% *** PDF, URL AND HYPERLINK PACKAGES ***
+%
+%\usepackage{url}
+% url.sty was written by Donald Arseneau. It provides better support for
+% handling and breaking URLs. url.sty is already installed on most LaTeX
+% systems. The latest version and documentation can be obtained at:
+% http://www.ctan.org/pkg/url
+% Basically, \url{my_url_here}.
+
+
+
+
+
+% *** Do not adjust lengths that control margins, column widths, etc. ***
+% *** Do not use packages that alter fonts (such as pslatex).         ***
+% There should be no need to do such things with IEEEtran.cls V1.6 and later.
+% (Unless specifically asked to do so by the journal or conference you plan
+% to submit to, of course. )
+
+
+% correct bad hyphenation here
+\hyphenation{op-tical net-works semi-conduc-tor}
+
+
+\begin{document}
+%
+% paper title
+% Titles are generally capitalized except for words such as a, an, and, as,
+% at, but, by, for, in, nor, of, on, or, the, to and up, which are usually
+% not capitalized unless they are the first or last word of the title.
+% Linebreaks \\ can be used within to get better formatting as desired.
+% Do not put math or special symbols in the title.
+\title{Bare Demo of IEEEtran.cls for\\ IEEE Computer Society Journals}
+%
+%
+% author names and IEEE memberships
+% note positions of commas and nonbreaking spaces ( ~ ) LaTeX will not break
+% a structure at a ~ so this keeps an author's name from being broken across
+% two lines.
+% use \thanks{} to gain access to the first footnote area
+% a separate \thanks must be used for each paragraph as LaTeX2e's \thanks
+% was not built to handle multiple paragraphs
+%
+%
+%\IEEEcompsocitemizethanks is a special \thanks that produces the bulleted
+% lists the Computer Society journals use for "first footnote" author
+% affiliations. Use \IEEEcompsocthanksitem which works much like \item
+% for each affiliation group. When not in compsoc mode,
+% \IEEEcompsocitemizethanks becomes like \thanks and
+% \IEEEcompsocthanksitem becomes a line break with idention. This
+% facilitates dual compilation, although admittedly the differences in the
+% desired content of \author between the different types of papers makes a
+% one-size-fits-all approach a daunting prospect. For instance, compsoc 
+% journal papers have the author affiliations above the "Manuscript
+% received ..."  text while in non-compsoc journals this is reversed. Sigh.
+
+\author{Michael~Shell,~\IEEEmembership{Member,~IEEE,}
+        John~Doe,~\IEEEmembership{Fellow,~OSA,}
+        and~Jane~Doe,~\IEEEmembership{Life~Fellow,~IEEE}% <-this % stops a space
+\IEEEcompsocitemizethanks{\IEEEcompsocthanksitem M. Shell was with the Department
+of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta,
+GA, 30332.\protect\\
+% note need leading \protect in front of \\ to get a newline within \thanks as
+% \\ is fragile and will error, could use \hfil\break instead.
+E-mail: see http://www.michaelshell.org/contact.html
+\IEEEcompsocthanksitem J. Doe and J. Doe are with Anonymous University.}% <-this % stops an unwanted space
+\thanks{Manuscript received April 19, 2005; revised August 26, 2015.}}
+
+% note the % following the last \IEEEmembership and also \thanks - 
+% these prevent an unwanted space from occurring between the last author name
+% and the end of the author line. i.e., if you had this:
+% 
+% \author{....lastname \thanks{...} \thanks{...} }
+%                     ^------------^------------^----Do not want these spaces!
+%
+% a space would be appended to the last name and could cause every name on that
+% line to be shifted left slightly. This is one of those "LaTeX things". For
+% instance, "\textbf{A} \textbf{B}" will typeset as "A B" not "AB". To get
+% "AB" then you have to do: "\textbf{A}\textbf{B}"
+% \thanks is no different in this regard, so shield the last } of each \thanks
+% that ends a line with a % and do not let a space in before the next \thanks.
+% Spaces after \IEEEmembership other than the last one are OK (and needed) as
+% you are supposed to have spaces between the names. For what it is worth,
+% this is a minor point as most people would not even notice if the said evil
+% space somehow managed to creep in.
+
+
+
+% The paper headers
+\markboth{Journal of \LaTeX\ Class Files,~Vol.~14, No.~8, August~2015}%
+{Shell \MakeLowercase{\textit{et al.}}: Bare Demo of IEEEtran.cls for Computer Society Journals}
+% The only time the second header will appear is for the odd numbered pages
+% after the title page when using the twoside option.
+% 
+% *** Note that you probably will NOT want to include the author's ***
+% *** name in the headers of peer review papers.                   ***
+% You can use \ifCLASSOPTIONpeerreview for conditional compilation here if
+% you desire.
+
+
+
+% The publisher's ID mark at the bottom of the page is less important with
+% Computer Society journal papers as those publications place the marks
+% outside of the main text columns and, therefore, unlike regular IEEE
+% journals, the available text space is not reduced by their presence.
+% If you want to put a publisher's ID mark on the page you can do it like
+% this:
+%\IEEEpubid{0000--0000/00\$00.00~\copyright~2015 IEEE}
+% or like this to get the Computer Society new two part style.
+%\IEEEpubid{\makebox[\columnwidth]{\hfill 0000--0000/00/\$00.00~\copyright~2015 IEEE}%
+%\hspace{\columnsep}\makebox[\columnwidth]{Published by the IEEE Computer Society\hfill}}
+% Remember, if you use this you must call \IEEEpubidadjcol in the second
+% column for its text to clear the IEEEpubid mark (Computer Society jorunal
+% papers don't need this extra clearance.)
+
+
+
+% use for special paper notices
+%\IEEEspecialpapernotice{(Invited Paper)}
+
+
+
+% for Computer Society papers, we must declare the abstract and index terms
+% PRIOR to the title within the \IEEEtitleabstractindextext IEEEtran
+% command as these need to go into the title area created by \maketitle.
+% As a general rule, do not put math, special symbols or citations
+% in the abstract or keywords.
+\IEEEtitleabstractindextext{%
+\begin{abstract}
+The abstract goes here.
+\end{abstract}
+
+% Note that keywords are not normally used for peerreview papers.
+\begin{IEEEkeywords}
+Computer Society, IEEE, IEEEtran, journal, \LaTeX, paper, template.
+\end{IEEEkeywords}}
+
+
+% make the title area
+\maketitle
+
+
+% To allow for easy dual compilation without having to reenter the
+% abstract/keywords data, the \IEEEtitleabstractindextext text will
+% not be used in maketitle, but will appear (i.e., to be "transported")
+% here as \IEEEdisplaynontitleabstractindextext when the compsoc 
+% or transmag modes are not selected <OR> if conference mode is selected 
+% - because all conference papers position the abstract like regular
+% papers do.
+\IEEEdisplaynontitleabstractindextext
+% \IEEEdisplaynontitleabstractindextext has no effect when using
+% compsoc or transmag under a non-conference mode.
+
+
+
+% For peer review papers, you can put extra information on the cover
+% page as needed:
+% \ifCLASSOPTIONpeerreview
+% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
+% \fi
+%
+% For peerreview papers, this IEEEtran command inserts a page break and
+% creates the second title. It will be ignored for other modes.
+\IEEEpeerreviewmaketitle
+
+
+
+\IEEEraisesectionheading{\section{Introduction}\label{sec:introduction}}
+% Computer Society journal (but not conference!) papers do something unusual
+% with the very first section heading (almost always called "Introduction").
+% They place it ABOVE the main text! IEEEtran.cls does not automatically do
+% this for you, but you can achieve this effect with the provided
+% \IEEEraisesectionheading{} command. Note the need to keep any \label that
+% is to refer to the section immediately after \section in the above as
+% \IEEEraisesectionheading puts \section within a raised box.
+
+
+
+
+% The very first letter is a 2 line initial drop letter followed
+% by the rest of the first word in caps (small caps for compsoc).
+% 
+% form to use if the first word consists of a single letter:
+% \IEEEPARstart{A}{demo} file is ....
+% 
+% form to use if you need the single drop letter followed by
+% normal text (unknown if ever used by the IEEE):
+% \IEEEPARstart{A}{}demo file is ....
+% 
+% Some journals put the first two words in caps:
+% \IEEEPARstart{T}{his demo} file is ....
+% 
+% Here we have the typical use of a "T" for an initial drop letter
+% and "HIS" in caps to complete the first word.
+\IEEEPARstart{T}{his} demo file is intended to serve as a ``starter file''
+for IEEE Computer Society journal papers produced under \LaTeX\ using
+IEEEtran.cls version 1.8b and later.
+% You must have at least 2 lines in the paragraph with the drop letter
+% (should never be an issue)
+I wish you the best of success.
+
+\hfill mds
+ 
+\hfill August 26, 2015
+
+\subsection{Subsection Heading Here}
+Subsection text here.
+
+% needed in second column of first page if using \IEEEpubid
+%\IEEEpubidadjcol
+
+\subsubsection{Subsubsection Heading Here}
+Subsubsection text here.
+
+
+% An example of a floating figure using the graphicx package.
+% Note that \label must occur AFTER (or within) \caption.
+% For figures, \caption should occur after the \includegraphics.
+% Note that IEEEtran v1.7 and later has special internal code that
+% is designed to preserve the operation of \label within \caption
+% even when the captionsoff option is in effect. However, because
+% of issues like this, it may be the safest practice to put all your
+% \label just after \caption rather than within \caption{}.
+%
+% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
+% option should be used if it is desired that the figures are to be
+% displayed while in draft mode.
+%
+%\begin{figure}[!t]
+%\centering
+%\includegraphics[width=2.5in]{myfigure}
+% where an .eps filename suffix will be assumed under latex, 
+% and a .pdf suffix will be assumed for pdflatex; or what has been declared
+% via \DeclareGraphicsExtensions.
+%\caption{Simulation results for the network.}
+%\label{fig_sim}
+%\end{figure}
+
+% Note that the IEEE typically puts floats only at the top, even when this
+% results in a large percentage of a column being occupied by floats.
+% However, the Computer Society has been known to put floats at the bottom.
+
+
+% An example of a double column floating figure using two subfigures.
+% (The subfig.sty package must be loaded for this to work.)
+% The subfigure \label commands are set within each subfloat command,
+% and the \label for the overall figure must come after \caption.
+% \hfil is used as a separator to get equal spacing.
+% Watch out that the combined width of all the subfigures on a 
+% line do not exceed the text width or a line break will occur.
+%
+%\begin{figure*}[!t]
+%\centering
+%\subfloat[Case I]{\includegraphics[width=2.5in]{box}%
+%\label{fig_first_case}}
+%\hfil
+%\subfloat[Case II]{\includegraphics[width=2.5in]{box}%
+%\label{fig_second_case}}
+%\caption{Simulation results for the network.}
+%\label{fig_sim}
+%\end{figure*}
+%
+% Note that often IEEE papers with subfigures do not employ subfigure
+% captions (using the optional argument to \subfloat[]), but instead will
+% reference/describe all of them (a), (b), etc., within the main caption.
+% Be aware that for subfig.sty to generate the (a), (b), etc., subfigure
+% labels, the optional argument to \subfloat must be present. If a
+% subcaption is not desired, just leave its contents blank,
+% e.g., \subfloat[].
+
+
+% An example of a floating table. Note that, for IEEE style tables, the
+% \caption command should come BEFORE the table and, given that table
+% captions serve much like titles, are usually capitalized except for words
+% such as a, an, and, as, at, but, by, for, in, nor, of, on, or, the, to
+% and up, which are usually not capitalized unless they are the first or
+% last word of the caption. Table text will default to \footnotesize as
+% the IEEE normally uses this smaller font for tables.
+% The \label must come after \caption as always.
+%
+%\begin{table}[!t]
+%% increase table row spacing, adjust to taste
+%\renewcommand{\arraystretch}{1.3}
+% if using array.sty, it might be a good idea to tweak the value of
+% \extrarowheight as needed to properly center the text within the cells
+%\caption{An Example of a Table}
+%\label{table_example}
+%\centering
+%% Some packages, such as MDW tools, offer better commands for making tables
+%% than the plain LaTeX2e tabular which is used here.
+%\begin{tabular}{|c||c|}
+%\hline
+%One & Two\\
+%\hline
+%Three & Four\\
+%\hline
+%\end{tabular}
+%\end{table}
+
+
+% Note that the IEEE does not put floats in the very first column
+% - or typically anywhere on the first page for that matter. Also,
+% in-text middle ("here") positioning is typically not used, but it
+% is allowed and encouraged for Computer Society conferences (but
+% not Computer Society journals). Most IEEE journals/conferences use
+% top floats exclusively. 
+% Note that, LaTeX2e, unlike IEEE journals/conferences, places
+% footnotes above bottom floats. This can be corrected via the
+% \fnbelowfloat command of the stfloats package.
+
+
+
+
+\section{Conclusion}
+The conclusion goes here.
+
+
+
+
+
+% if have a single appendix:
+%\appendix[Proof of the Zonklar Equations]
+% or
+%\appendix  % for no appendix heading
+% do not use \section anymore after \appendix, only \section*
+% is possibly needed
+
+% use appendices with more than one appendix
+% then use \section to start each appendix
+% you must declare a \section before using any
+% \subsection or using \label (\appendices by itself
+% starts a section numbered zero.)
+%
+
+
+\appendices
+\section{Proof of the First Zonklar Equation}
+Appendix one text goes here.
+
+% you can choose not to have a title for an appendix
+% if you want by leaving the argument blank
+\section{}
+Appendix two text goes here.
+
+
+% use section* for acknowledgment
+\ifCLASSOPTIONcompsoc
+  % The Computer Society usually uses the plural form
+  \section*{Acknowledgments}
+\else
+  % regular IEEE prefers the singular form
+  \section*{Acknowledgment}
+\fi
+
+
+The authors would like to thank...
+
+
+% Can use something like this to put references on a page
+% by themselves when using endfloat and the captionsoff option.
+\ifCLASSOPTIONcaptionsoff
+  \newpage
+\fi
+
+
+
+% trigger a \newpage just before the given reference
+% number - used to balance the columns on the last page
+% adjust value as needed - may need to be readjusted if
+% the document is modified later
+%\IEEEtriggeratref{8}
+% The "triggered" command can be changed if desired:
+%\IEEEtriggercmd{\enlargethispage{-5in}}
+
+% references section
+
+% can use a bibliography generated by BibTeX as a .bbl file
+% BibTeX documentation can be easily obtained at:
+% http://mirror.ctan.org/biblio/bibtex/contrib/doc/
+% The IEEEtran BibTeX style support page is at:
+% http://www.michaelshell.org/tex/ieeetran/bibtex/
+%\bibliographystyle{IEEEtran}
+% argument is your BibTeX string definitions and bibliography database(s)
+%\bibliography{IEEEabrv,../bib/paper}
+%
+% <OR> manually copy in the resultant .bbl file
+% set second argument of \begin to the number of references
+% (used to reserve space for the reference number labels box)
+\begin{thebibliography}{1}
+
+\bibitem{IEEEhowto:kopka}
+H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
+  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
+
+\end{thebibliography}
+
+% biography section
+% 
+% If you have an EPS/PDF photo (graphicx package needed) extra braces are
+% needed around the contents of the optional argument to biography to prevent
+% the LaTeX parser from getting confused when it sees the complicated
+% \includegraphics command within an optional argument. (You could create
+% your own custom macro containing the \includegraphics command to make things
+% simpler here.)
+%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{mshell}}]{Michael Shell}
+% or if you just want to reserve a space for a photo:
+
+\begin{IEEEbiography}{Michael Shell}
+Biography text here.
+\end{IEEEbiography}
+
+% if you will not have a photo at all:
+\begin{IEEEbiographynophoto}{John Doe}
+Biography text here.
+\end{IEEEbiographynophoto}
+
+% insert where needed to balance the two columns on the last page with
+% biographies
+%\newpage
+
+\begin{IEEEbiographynophoto}{Jane Doe}
+Biography text here.
+\end{IEEEbiographynophoto}
+
+% You can push biographies down or up by placing
+% a \vfill before or after them. The appropriate
+% use of \vfill depends on what kind of text is
+% on the last page and whether or not the columns
+% are being equalized.
+
+%\vfill
+
+% Can be used to pull up biographies so that the bottom of the last one
+% is flush with the other column.
+%\enlargethispage{-5in}
+
+
+
+% that's all folks
+\end{document}
+
+

TC_Template/images/Sync-Fire

@@ -0,0 +1 @@
+<mxfile host="app.diagrams.net" modified="2022-03-17T04:29:48.701Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36" etag="ry8GXHVOdN1Jc8pM7tsV" version="17.1.2" type="device"><diagram id="K7JRYQhel2MMmrMd0Y0x" name="Page-1">5Vtbc9o4FP41PJKR5SuPSchltmmTWabt0jeBBbgxltcWAfbXr2TLYFnCQGIwmb606EiypHPOd25SOubtfPWQoHj2lfg47EDgrzpmvwOh53jsX05Y5wTLMHPCNAn8nGRsCYPgPyyIQFAXgY9TaSAlJKRBLBPHJIrwmEo0lCRkKQ+bkFBeNUZTrBAGYxSq1J+BT2fiWDbY0h9xMJ0VKxtA9MxRMVgQ0hnyybJEMu865m1CCM1/zVe3OOS8K/iSz7vf0bvZWIIjesiE4RQswfDmx6/o91/DawP2Hp2gK4TxhsKFOLDYLF0XHMA+Y4hokoTOyJREKLzbUm8Ssoh8zJcBrLUd80RIzIgGI/7GlK6FdNGCEkaa0XkoetWjiNOlZJGMcc3+C5VAyRTTmnHiWPwspQUEox4wmWOarNmABIeIBm+y8JHQoelm3JbN7Ifg9BFcNxSuvyyyWRFeUb5gHIfBGI0Yd9meV3FIAqrIReb6chZQPIhRxq0lg+KBHH7DCcWrWp6IXtMViiyQ7IjmcgsLo9D1WQkSxbjGuWh/ct2FB+qu1ZbuDgAcmb8Gj3MXx8/r57/tyWRccP0TM1l7rMtisqNRbSdk+7+ZkIhK7Hf+XZCio5tmDLxmAwwzXm072a8p//8bKb7DtpV/Ku/QCvUJjZgzlwSBwmAasd9jJgicMAK3H8xUhdeiYx74fi5zzDaTmbBc6jEJIprxyb7p2H2tUOsUTjFUG58vFpHcqs6AdcGV6Zq9fO7BchSfe+HbLw0hk0mKqSLozarvN2tQdQ4o4UuTCV8/i5TIguHmXnUJMzIfLdLzuANPdgeGzh8AjT/oncofOG1YJsbAZP2PmJ81hrxx5dpFu78q9/bXovV+k2Yd6DeMpk1aNvU6SdC6NEDgWkVKoSdQ1hPTssuS3jveAHZFM/IdNIo5V8Ecs1/otQ2ryK2y0DaWKun0pE75G7GSwPEsWQaXbjO9E/nL+yBhxuGSXebJlcHrWW6TyiC+0jUceUojyhGk98Pxz7fv3RUcDp+/zJ6+TH50YSuOQWt8GzP4+oPaZ4pZ63ZZwuBDFqdwxiPKo5LLClhM0HbA0lM4NsSpwiPKawInsyhccVPhblgzpQl5xbckJOy7/YhE/CuTIAyrpL1e6mj5WNCW5KMrMFga8cAGxKOFU8vx5JUJPDmmBI65J6jMWi84CRgHuGaUIs1jLZE2F9OU27SsO5chqttkCVYZ97kujilTYqYwnArmzMjYN3kyZfcVYaczFPOfPqJowOZlheJ9dmoSrHBRxW7KbgFwVYGGbetqb/DKVtHhngodXsvocKF9aeg41E9/FB3vysMcS9Yhx65cF1TGW7ZVN/7DeVgdB/dCV18gd9CcwzEapXEmWKCSLhTjdiU22cC2DHBT4/yagLfeiIJ94ZzC2zxLGiWbBCkTlUihLpTxlum2bFz13FeB8I3Qndz8U0JE06mE8J4qKvecIWJxmd2aF5R94EElx2Ndnf7gB7o641zXKHW73HnPGlacS4NXrZrai8LnGj1XrJKny1ZPdd2qZyZQ+HKxZZTdYdchOtumyqqX2l/RK85Udil8L1blEIZBnB7gQU+jm47GDGt10zuZbrqt2OFVQEtmmLWGpZ6tEeYNKQdp2XY3cg+kJgxQUYxetXSWY09MbL7Sa6gG/3vsZ4gBg0tEjtc+clrO4+UcHu67NS0gZ1wBWAYdv7Wy64HHGs3k/vraO1S9y+5b2ebBZ8qRca+amuQHUJB3bBXBgp60zua9464yAqxs7OgJbrPXv3oQqO9tPk0lvgnDpCbBBjBUy3TW6nsBKCkF/nNE0tOIROMsdDWh04nEuiRfcdgDm2aMu6ka95OkDu98YaPRFXPfKxs1FjGbLfDWcrKc35CEx2cs+po3cUf8Mdi5u2PYc1wT63nWTnLTfqICNRn77hu/tjJ22PZN2OWLZ8cjo/PIx2ylbnUJXksjn9OlJMd6LVip5VvunrygMr53Bm9lqvWEo98Vwk/yDv/gx4KyMtZAbqeX5a8KXUu+Xi6ufj/6rPB8rwrVSu11NgulbMU0Owry15pr0crFKbMcEEwCFgS1HvzIkY8FNZGPoYl8NuFQ8771Ez+Ra0Ai1aqOrZFIQ0k5a27/FDXHyPbvec27/wE=</diagram></mxfile>

TC_Template/images/non-sync_ex

@@ -0,0 +1 @@
+<mxfile host="app.diagrams.net" modified="2022-03-05T20:37:46.832Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36" etag="M_WsQ7zI5yW5TNglHCuS" version="16.6.6" type="device"><diagram id="ZJqofbyrsTVr7fP3P7zB" name="Page-1">7Vxdk9smFP01ftyMBALJj8nuJu20nWRmJ9PmKYNl1lIrGwXj2M6vD7LRtz9YyxZo0ydLVxcLcy7nXLjsjuD9fPOBkzT6i01pMgLOdDOCDyMAwNgF8iOzbPcW1wHKMuPxVNlKw1P8g+aOyrqKp3RZcxSMJSJO68aQLRY0FDUb4Zyt627PLKm/NSUz2jI8hSRpW/+OpyLaWwPklPbfaDyL8je7jnoyJ7mzMiwjMmXrigk+juA9Z0zsr+abe5pko5ePy77d+yNPi45xuhA6DUjy8fcJ/nz3/ht+IiH6g+D0xx2AqnNim/9iOpUDoG4ZFxGbsQVJHkvrO85WiynNvtaRd6XPn4yl0uhK479UiK1Ck6wEk6ZIzBP1lG5i8Y9qnl1/qdgfNpUHD1t1s+9l1rWjv16ZlmzFQ3riJ7t5GBE+o+KUIyhQkvFN2ZwKvpUNOU2IiL/Xe0JUnM0KvxIKeaHQeAkynklkXG1k5Pjz7Q7MNyi//VJ9Vjbb3RlFFJpENO/md5Ks1KtCwr+6Wc/jOZUfO2NGIDiRP+PdhMurWXaV+QENPyYiyr9+W5Gk8Nq0wyhJJHtm4bKOYkGfUrIb3bVk8HowqO5SLujmNEjtIVUNYE6UOf/nbLguybSgzKhCpNi51bxCtjCemjBWzyygO7M8kzMLGuVKfRUbFKJ+R0R3Td9yTrYVh5TFC7GsfPOnzFDyBfDrfAF8txEd+28sY6XoWofwMUMJRTBYHwrIRChAWA8F6KB6ftv0x+iU/21CJx/Dc5ouDZjMM31dTJbpDkc7NP45TpJ7ljC+awefg5CGobQvBWf/0cqTSYA8VEZgp6wANLICYD4rCGzJts9lBdckAKhLAGOj6m50jTqslZA2ooEJSkfQhLrjwSWHflCLnzdOAM/E0O7uE+VSOwTlJgOra67QbYkN9eTYuVCO3Vcpx551cuz5tszZISzSPc25Cbsu6bphajTFGtYiXRtRo4kZBrYkZvqztC6syEJMO2+8dFNQr6WgueYtU7KoqqP+Ilf2pNq4LaLHXqGzHj7ykgO6TA69RvsLBybq48buCTSt6WggpcaCK4pNur7ZH2kyhXckAvphCmR2071g/JcouvWIAqN6bk1prL/DALrIdM60LtsD9xosHtQ2TM76e65z0t91T/rfZkPGH9x+nrmkUTc8sZH9PA/WSy6eczrcEHC6+eMewjMf81uVdG6+h3SF5LF5bMOC7NFtD4jl2Yax/NHXzTacw0HQb4n/HAmA0yRzI41yTIbbRTUnB9dlCso4MFw00A1EM+qVHxDQDcSXql3Lv3lA90x17MX+3rgHdfRvq456Bx4ml6ujmQMPwDY9xeOhEZwpNQ36IrFOePqDyY9MYOMZPZ6ad9NsVXponOkFtnEmsoYzh1CVHuvOTWxybmJrqhLamNbXlb1uR+li2vl4WTctBEPRwmPz1LUQU7NnDfJumtVQMjANxa5tGgrb60ft8wXg//MF9oTWXat2ZD62NDnitjv3HTjiCrA0KybGQckrkudAOTq5f8kNIxdZh6PmXy9fiuPrPFoNAutwBJcLcA8H/IC2Xh6Ojl9HgD3r9Ndrnx29ao5+IDZeAdXjZj3UPI7YBhyHttYKHNtwxJr7zgek18w+8xVQQM0TcDdEQd6W/75pX2At/wsWfPwJ</diagram></mxfile>

TC_Template/texput.log

@@ -0,0 +1,21 @@
+This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Arch Linux) (preloaded format=pdflatex 2022.4.29)  11 OCT 2022 16:04
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**
+
+! Emergency stop.
+<*> 
+    
+End of file on the terminal!
+
+ 
+Here is how much of TeX's memory you used:
+ 4 strings out of 478238
+ 135 string characters out of 5850456
+ 289994 words of memory out of 5000000
+ 18344 multiletter control sequences out of 15000+600000
+ 469259 words of font info for 28 fonts, out of 8000000 for 9000
+ 1141 hyphenation exceptions out of 8191
+ 0i,0n,0p,1b,6s stack positions out of 5000i,500n,10000p,200000b,80000s
+!  ==> Fatal error occurred, no output PDF file produced!