Incorporating Dr. Hawrylak's changes
This commit is contained in:
parent
3e3e0f56a4
commit
fd7e9daf97
@ -21,14 +21,11 @@
|
||||
\citation{phillips_graph-based_1998}
|
||||
\citation{schneier_modeling_1999}
|
||||
\citation{ou_scalable_2006}
|
||||
\citation{CPSIOT}
|
||||
\citation{ming_jo}
|
||||
\citation{CPSIOT,ming_jo}
|
||||
\citation{10.1145/3105760}
|
||||
\citation{8290918}
|
||||
\citation{centrality_based}
|
||||
\citation{j_hale_compliance_nodate}
|
||||
\citation{baloyi_guidelines_2019}
|
||||
\citation{allman_complying_2006}
|
||||
\citation{j_hale_compliance_nodate,baloyi_guidelines_2019,allman_complying_2006}
|
||||
\citation{sheyner_automated_2002}
|
||||
\citation{ou_scalable_2006}
|
||||
\citation{zhang_boosting_2017}
|
||||
@ -51,14 +48,14 @@
|
||||
\newlabel{fig:non-sync_ex}{{1}{2}{A network without Synchronous Firing generating infeasible states}{figure.1}{}}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{louthan_hybrid_2011}
|
||||
\citation{nichols_2018}
|
||||
\citation{cook_rage_2018}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {IV}Implementing Synchronous Firing}{3}{section.4}\protected@file@percent }
|
||||
\newlabel{sec:implementing}{{IV}{3}{Implementing Synchronous Firing}{section.4}{}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-A}}GNU Bison and Flex}{3}{subsection.4.1}\protected@file@percent }
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Inclusion of Synchronous Firing into GNU Bison, GNU Flex, and the overall program}}{3}{figure.2}\protected@file@percent }
|
||||
\newlabel{fig:bison-flex}{{2}{3}{Inclusion of Synchronous Firing into GNU Bison, GNU Flex, and the overall program}{figure.2}{}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-B}}PostgreSQL}{3}{subsection.4.2}\protected@file@percent }
|
||||
\citation{nichols_2018}
|
||||
\citation{cook_rage_2018}
|
||||
\citation{cook_rage_2018}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-C}}Compound Operators}{4}{subsection.4.3}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {\mbox {IV-D}}Graph Generation}{4}{subsection.4.4}\protected@file@percent }
|
||||
@ -78,16 +75,16 @@
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {\mbox {V-B}2}Results for a Grouped Environment}{6}{subsubsection.5.2.2}\protected@file@percent }
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Speedup (Amdahl's) Obtained When Using Synchronous Firing}}{6}{figure.6}\protected@file@percent }
|
||||
\newlabel{fig:Sync-Spd}{{6}{6}{Speedup (Amdahl's) Obtained When Using Synchronous Firing}{figure.6}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {I}{\ignorespaces Tabled Results for the Non-Synchronous Firing Testing}}{6}{table.1}\protected@file@percent }
|
||||
\newlabel{table:NS-Table}{{I}{6}{Tabled Results for the Non-Synchronous Firing Testing}{table.1}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {II}{\ignorespaces Tabled Results for the Synchronous Firing Testing}}{7}{table.2}\protected@file@percent }
|
||||
\newlabel{table:S-Table}{{II}{7}{Tabled Results for the Synchronous Firing Testing}{table.2}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {III}{\ignorespaces Tabled Results for the Comprehensive Services without Synchronous Firing}}{7}{table.3}\protected@file@percent }
|
||||
\newlabel{table:Non-Sync-Comp-Table}{{III}{7}{Tabled Results for the Comprehensive Services without Synchronous Firing}{table.3}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {I}{\ignorespaces Results for the Non-Synchronous Firing Testing}}{6}{table.1}\protected@file@percent }
|
||||
\newlabel{table:NS-Table}{{I}{6}{Results for the Theoretical Environment}{table.1}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {II}{\ignorespaces Results for the Synchronous Firing Testing}}{7}{table.2}\protected@file@percent }
|
||||
\newlabel{table:S-Table}{{II}{7}{Results for the Theoretical Environment}{table.2}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {III}{\ignorespaces Results for the Comprehensive Services without Synchronous Firing}}{7}{table.3}\protected@file@percent }
|
||||
\newlabel{table:Non-Sync-Comp-Table}{{III}{7}{Results for a Grouped Environment}{table.3}{}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {VI}Future Works}{7}{section.6}\protected@file@percent }
|
||||
\newlabel{sec:fw}{{VI}{7}{Future Works}{section.6}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {IV}{\ignorespaces Tabled Results for the Comprehensive Services with Synchronous Firing}}{7}{table.4}\protected@file@percent }
|
||||
\newlabel{table:Sync-Comp-Table}{{IV}{7}{Tabled Results for the Comprehensive Services with Synchronous Firing}{table.4}{}}
|
||||
\@writefile{lot}{\contentsline {table}{\numberline {IV}{\ignorespaces Results for the Comprehensive Services with Synchronous Firing}}{7}{table.4}\protected@file@percent }
|
||||
\newlabel{table:Sync-Comp-Table}{{IV}{7}{Results for a Grouped Environment}{table.4}{}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Synchronous Firing on Runtime}}{7}{figure.7}\protected@file@percent }
|
||||
\newlabel{fig:Comp-Sync-RT}{{7}{7}{Synchronous Firing on Runtime}{figure.7}{}}
|
||||
\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Bar Graph and Line Graph Representations of Synchronous Firing with Comprehensive Services on State Space}}{7}{figure.8}\protected@file@percent }
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Arch Linux) (preloaded format=pdflatex 2022.4.29) 11 OCT 2022 11:57
|
||||
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:51
|
||||
entering extended mode
|
||||
restricted \write18 enabled.
|
||||
%&-line parsing enabled.
|
||||
@ -261,6 +261,8 @@ Package: float 2001/11/08 v1.3d Float enhancements (AL)
|
||||
\@float@everytoks=\toks26
|
||||
\@floatcapt=\box55
|
||||
)
|
||||
\@float@every@table=\toks27
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/xcolor/xcolor.sty
|
||||
Package: xcolor 2021/10/31 v2.13 LaTeX color extensions (UK)
|
||||
|
||||
@ -409,7 +411,7 @@ Package uniquecounter Info: New unique counter `rerunfilecheck' on input line 2
|
||||
)
|
||||
\Hy@SectionHShift=\skip55
|
||||
)
|
||||
Package hyperref Info: Option `colorlinks' set `true' on input line 26.
|
||||
Package hyperref Info: Option `colorlinks' set `true' on input line 30.
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
|
||||
File: l3backend-pdftex.def 2022-04-14 L3 backend support: PDF output (pdfTeX)
|
||||
@ -419,24 +421,24 @@ File: l3backend-pdftex.def 2022-04-14 L3 backend support: PDF output (pdfTeX)
|
||||
(./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 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for PU/pdf/m/n on input line 28.
|
||||
LaTeX Font Info: ... okay on input line 28.
|
||||
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
LaTeX Font Info: Checking defaults for PU/pdf/m/n on input line 32.
|
||||
LaTeX Font Info: ... okay on input line 32.
|
||||
|
||||
-- Lines per column: 56 (exact).
|
||||
(/usr/share/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
|
||||
@ -446,12 +448,12 @@ LaTeX Font Info: ... okay on input line 28.
|
||||
\scratchbox=\box57
|
||||
\nofMPsegments=\count297
|
||||
\nofMParguments=\count298
|
||||
\everyMPshowfont=\toks27
|
||||
\everyMPshowfont=\toks28
|
||||
\MPscratchCnt=\count299
|
||||
\MPscratchDim=\dimen179
|
||||
\MPnumerator=\count300
|
||||
\makeMPintoPDFobject=\count301
|
||||
\everyMPtoPDFconversion=\toks28
|
||||
\everyMPtoPDFconversion=\toks29
|
||||
) (/usr/share/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
|
||||
Package: epstopdf-base 2020-01-24 v2.11 Base part for package epstopdf
|
||||
Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
|
||||
@ -461,7 +463,7 @@ Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
|
||||
File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
|
||||
e
|
||||
))
|
||||
Package hyperref Info: Link coloring ON on input line 28.
|
||||
Package hyperref Info: Link coloring ON on input line 32.
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/hyperref/nameref.sty
|
||||
Package: nameref 2021-04-02 v2.47 Cross-referencing by name of section
|
||||
@ -474,26 +476,26 @@ Package: gettitlestring 2019/12/15 v1.6 Cleanup title references (HO)
|
||||
)
|
||||
\c@section@level=\count302
|
||||
)
|
||||
LaTeX Info: Redefining \ref on input line 28.
|
||||
LaTeX Info: Redefining \pageref on input line 28.
|
||||
LaTeX Info: Redefining \nameref on input line 28.
|
||||
LaTeX Info: Redefining \ref on input line 32.
|
||||
LaTeX Info: Redefining \pageref on input line 32.
|
||||
LaTeX Info: Redefining \nameref on input line 32.
|
||||
|
||||
(./Schrick-Noah_AG-CG-SyncFire.out) (./Schrick-Noah_AG-CG-SyncFire.out)
|
||||
\@outlinefile=\write3
|
||||
\openout3 = `Schrick-Noah_AG-CG-SyncFire.out'.
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 59--61
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 63--65
|
||||
[]\OT1/ptm/b/it/9 Index Terms\OT1/ptm/b/n/9 ---Attack Graph; Compliance Graph;
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 59--61
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 63--65
|
||||
\OT1/ptm/b/n/9 Synchronous Firing; High-Performance Computing;
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 2261) in paragraph at lines 73--77
|
||||
Underfull \hbox (badness 2261) in paragraph at lines 77--81
|
||||
\OT1/ptm/m/n/10 Similar difficulties arise in related fields, where social
|
||||
[]
|
||||
|
||||
@ -501,170 +503,179 @@ Underfull \hbox (badness 2261) in paragraph at lines 73--77
|
||||
|
||||
|
||||
]
|
||||
LaTeX Font Info: Trying to load font information for U+msa on input line 79.
|
||||
LaTeX Font Info: Trying to load font information for U+msa on input line 83.
|
||||
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/umsa.fd
|
||||
File: umsa.fd 2013/01/14 v3.01 AMS symbols A
|
||||
)
|
||||
LaTeX Font Info: Trying to load font information for U+msb on input line 79.
|
||||
LaTeX Font Info: Trying to load font information for U+msb on input line 83.
|
||||
|
||||
|
||||
(/usr/share/texmf-dist/tex/latex/amsfonts/umsb.fd
|
||||
File: umsb.fd 2013/01/14 v3.01 AMS symbols B
|
||||
)
|
||||
Underfull \hbox (badness 2662) in paragraph at lines 81--86
|
||||
Underfull \hbox (badness 2662) in paragraph at lines 85--90
|
||||
\OT1/ptm/m/n/10 functionality discussed by the author is similar: firing
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 2088) in paragraph at lines 81--86
|
||||
Underfull \hbox (badness 2088) in paragraph at lines 85--90
|
||||
\OT1/ptm/m/n/10 an exploit should be performed on all possible assets
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 1394) in paragraph at lines 81--86
|
||||
Underfull \hbox (badness 1394) in paragraph at lines 85--90
|
||||
\OT1/ptm/m/n/10 and group features, and grouped exploits could not be
|
||||
[]
|
||||
|
||||
<./images/non-sync_ex.drawio.png, id=114, 1014.79124pt x 400.49625pt>
|
||||
<./images/non-sync_ex.drawio.png, id=112, 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 96
|
||||
.
|
||||
Package pdftex.def Info: ./images/non-sync_ex.drawio.png used on input line 10
|
||||
0.
|
||||
(pdftex.def) Requested size: 252.0pt x 99.4516pt.
|
||||
[2 <./images/non-sync_ex.drawio.png>]
|
||||
LaTeX Font Info: Trying to load font information for OT1+pcr on input line 1
|
||||
12.
|
||||
16.
|
||||
|
||||
(/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 114--118
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 118--122
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 119--123
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 123--127
|
||||
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 124--130
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 128--134
|
||||
|
||||
[]
|
||||
|
||||
<./images/vert_Bison-Flex.drawio.png, id=136, 551.05875pt x 710.655pt>
|
||||
<./images/vert_Bison-Flex.drawio.png, id=133, 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 132.
|
||||
e 136.
|
||||
(pdftex.def) Requested size: 252.0pt x 324.98593pt.
|
||||
[3 <./images/vert_Bison-Flex.drawio.png>]
|
||||
Underfull \hbox (badness 2205) in paragraph at lines 144--147
|
||||
|
||||
Underfull \hbox (badness 2205) in paragraph at lines 148--151
|
||||
[]\OT1/ptm/m/n/10 Many of the graphs previously generated by RAGE
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 2351) in paragraph at lines 144--147
|
||||
Underfull \hbox (badness 2351) in paragraph at lines 148--151
|
||||
\OML/cmm/m/it/10 true=false\OT1/cmr/m/n/10 "$\OT1/ptm/m/n/10 , $\OT1/cmr/m/n/10
|
||||
\\OML/cmm/m/it/10 root \OT1/cmr/m/n/10 = \OML/cmm/m/it/10 true=false\OT1/cmr/m
|
||||
/n/10 "$\OT1/ptm/m/n/10 , or other general
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 1895) in paragraph at lines 154--155
|
||||
[3 <./images/vert_Bison-Flex.drawio.png>]
|
||||
Underfull \hbox (badness 1895) in paragraph at lines 158--159
|
||||
[]\OT1/ptm/m/n/10 Other changes involved updating classes (namely the
|
||||
[]
|
||||
|
||||
<./images/Sync-Fire.png, id=149, 489.83pt x 1053.9375pt>
|
||||
<./images/Sync-Fire.png, id=146, 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 161.
|
||||
Package pdftex.def Info: ./images/Sync-Fire.png used on input line 165.
|
||||
(pdftex.def) Requested size: 244.9144pt x 526.96747pt.
|
||||
|
||||
Underfull \hbox (badness 7451) in paragraph at lines 179--180
|
||||
Underfull \hbox (badness 7451) in paragraph at lines 186--187
|
||||
\OT1/ptm/m/n/10 All nodes are connected with a 10Gbps Infiniband
|
||||
[]
|
||||
|
||||
[4] [5 <./images/Sync-Fire.png>]
|
||||
<./images/Sync-Runtime-Bar.png, id=176, 602.25pt x 238.491pt>
|
||||
<./images/Sync-Runtime-Bar.png, id=173, 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 215.
|
||||
Package pdftex.def Info: ./images/Sync-Runtime-Bar.png used on input line 222.
|
||||
|
||||
(pdftex.def) Requested size: 252.0pt x 99.7907pt.
|
||||
<./images/Sync-Runtime.png, id=177, 549.69pt x 236.301pt>
|
||||
<./images/Sync-Runtime.png, id=174, 549.69pt x 236.301pt>
|
||||
File: ./images/Sync-Runtime.png Graphic file (type png)
|
||||
<use ./images/Sync-Runtime.png>
|
||||
Package pdftex.def Info: ./images/Sync-Runtime.png used on input line 216.
|
||||
Package pdftex.def Info: ./images/Sync-Runtime.png used on input line 223.
|
||||
(pdftex.def) Requested size: 252.0pt x 108.32838pt.
|
||||
<./images/Sync-StateSpace-Bar.png, id=178, 608.163pt x 223.38pt>
|
||||
<./images/Sync-StateSpace-Bar.png, id=175, 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
|
||||
23.
|
||||
30.
|
||||
(pdftex.def) Requested size: 252.0pt x 92.5578pt.
|
||||
<./images/Sync-StateSpace.png, id=179, 557.574pt x 229.512pt>
|
||||
<./images/Sync-StateSpace.png, id=176, 557.574pt x 229.512pt>
|
||||
File: ./images/Sync-StateSpace.png Graphic file (type png)
|
||||
<use ./images/Sync-StateSpace.png>
|
||||
Package pdftex.def Info: ./images/Sync-StateSpace.png used on input line 224.
|
||||
Package pdftex.def Info: ./images/Sync-StateSpace.png used on input line 231.
|
||||
(pdftex.def) Requested size: 252.0pt x 103.7312pt.
|
||||
<./images/Sync_Speedup.png, id=180, 533.265pt x 236.301pt>
|
||||
<./images/Sync_Speedup.png, id=177, 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 231.
|
||||
Package pdftex.def Info: ./images/Sync_Speedup.png used on input line 238.
|
||||
(pdftex.def) Requested size: 252.0pt x 111.66722pt.
|
||||
|
||||
Underfull \hbox (badness 2245) in paragraph at lines 283--284
|
||||
Overfull \hbox (8.37878pt too wide) in paragraph at lines 247--265
|
||||
[][]\OT1/ptm/m/n/10 `'
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 2245) in paragraph at lines 292--293
|
||||
\OT1/ptm/m/n/10 and resulting graphs presented in Section [][][]1[][] depict
|
||||
[]
|
||||
|
||||
|
||||
Underfull \hbox (badness 2173) in paragraph at lines 289--290
|
||||
Underfull \hbox (badness 2173) in paragraph at lines 298--299
|
||||
\OT1/ptm/m/n/10 in state space and an improvement in runtime. When
|
||||
[]
|
||||
|
||||
[6 <./images/Sync-Runtime-Bar.png> <./images/Sync-Runtime.png> <./images/Sync-S
|
||||
tateSpace-Bar.png> <./images/Sync-StateSpace.png> <./images/Sync_Speedup.png>]
|
||||
<./images/Comp-Sync-Runtime-Bar.png, id=196, 602.25pt x 238.491pt>
|
||||
Overfull \hbox (2.73875pt too wide) in paragraph at lines 328--347
|
||||
[][]
|
||||
[]
|
||||
|
||||
<./images/Comp-Sync-Runtime-Bar.png, id=195, 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
|
||||
340.
|
||||
351.
|
||||
(pdftex.def) Requested size: 252.0pt x 99.7907pt.
|
||||
<./images/Comp-Sync-Runtime.png, id=197, 549.69pt x 236.301pt>
|
||||
<./images/Comp-Sync-Runtime.png, id=196, 549.69pt x 236.301pt>
|
||||
File: ./images/Comp-Sync-Runtime.png Graphic file (type png)
|
||||
<use ./images/Comp-Sync-Runtime.png>
|
||||
Package pdftex.def Info: ./images/Comp-Sync-Runtime.png used on input line 341
|
||||
Package pdftex.def Info: ./images/Comp-Sync-Runtime.png used on input line 352
|
||||
.
|
||||
(pdftex.def) Requested size: 252.0pt x 108.32838pt.
|
||||
<./images/Comp-Sync-StateSpace-Bar.png, id=198, 600.717pt x 230.607pt>
|
||||
<./images/Comp-Sync-StateSpace-Bar.png, id=197, 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 348.
|
||||
ine 359.
|
||||
(pdftex.def) Requested size: 252.0pt x 96.73814pt.
|
||||
<./images/Comp-Sync-StateSpace.png, id=199, 532.17pt x 236.739pt>
|
||||
<./images/Comp-Sync-StateSpace.png, id=198, 532.17pt x 236.739pt>
|
||||
File: ./images/Comp-Sync-StateSpace.png Graphic file (type png)
|
||||
<use ./images/Comp-Sync-StateSpace.png>
|
||||
Package pdftex.def Info: ./images/Comp-Sync-StateSpace.png used on input line
|
||||
349.
|
||||
360.
|
||||
(pdftex.def) Requested size: 252.0pt x 112.1054pt.
|
||||
<./images/Comp-Sync_Speedup.png, id=200, 533.265pt x 236.301pt>
|
||||
<./images/Comp-Sync_Speedup.png, id=199, 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 356
|
||||
Package pdftex.def Info: ./images/Comp-Sync_Speedup.png used on input line 367
|
||||
.
|
||||
(pdftex.def) Requested size: 252.0pt x 111.66722pt.
|
||||
|
||||
Underfull \hbox (badness 2277) in paragraph at lines 364--365
|
||||
Underfull \hbox (badness 2277) in paragraph at lines 375--376
|
||||
\OT1/ptm/m/n/10 reduction due to the increased number of unattainable
|
||||
[]
|
||||
|
||||
[7 <./images/Comp-Sync-Runtime-Bar.png> <./images/Comp-Sync-Runtime.png> <./ima
|
||||
ges/Comp-Sync-StateSpace-Bar.png> <./images/Comp-Sync-StateSpace.png>]
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 368--369
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 379--380
|
||||
[]\OT1/ptm/m/n/10 Introducing service heuristics could improve the
|
||||
[]
|
||||
|
||||
@ -703,11 +714,11 @@ nged.
|
||||
(rerunfilecheck) Checksum: E85A8F1655CAD9A16113AB5056440CB9;2460.
|
||||
)
|
||||
Here is how much of TeX's memory you used:
|
||||
12190 strings out of 478238
|
||||
194376 string characters out of 5850456
|
||||
522026 words of memory out of 5000000
|
||||
30190 multiletter control sequences out of 15000+600000
|
||||
507907 words of font info for 102 fonts, out of 8000000 for 9000
|
||||
12171 strings out of 478238
|
||||
194196 string characters out of 5850456
|
||||
520953 words of memory out of 5000000
|
||||
30179 multiletter control sequences out of 15000+600000
|
||||
503083 words of font info for 88 fonts, out of 8000000 for 9000
|
||||
1141 hyphenation exceptions out of 8191
|
||||
60i,14n,63p,1233b,387s stack positions out of 5000i,500n,10000p,200000b,80000s
|
||||
{/usr/share/texmf-dist/fonts/enc/dvips/base/8r.enc}</usr/share/texmf-dist/fon
|
||||
@ -719,10 +730,10 @@ t/fonts/type1/urw/courier/ucrr8a.pfb></usr/share/texmf-dist/fonts/type1/urw/tim
|
||||
es/utmb8a.pfb></usr/share/texmf-dist/fonts/type1/urw/times/utmbi8a.pfb></usr/sh
|
||||
are/texmf-dist/fonts/type1/urw/times/utmr8a.pfb></usr/share/texmf-dist/fonts/ty
|
||||
pe1/urw/times/utmri8a.pfb>
|
||||
Output written on Schrick-Noah_AG-CG-SyncFire.pdf (8 pages, 909764 bytes).
|
||||
Output written on Schrick-Noah_AG-CG-SyncFire.pdf (8 pages, 909151 bytes).
|
||||
PDF statistics:
|
||||
282 PDF objects out of 1000 (max. 8388607)
|
||||
223 compressed objects within 3 object streams
|
||||
280 PDF objects out of 1000 (max. 8388607)
|
||||
221 compressed objects within 3 object streams
|
||||
56 named destinations out of 1000 (max. 500000)
|
||||
194 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
|
||||
|
||||
Binary file not shown.
@ -11,7 +11,11 @@
|
||||
\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}}
|
||||
@ -63,10 +67,10 @@ Attack Graph; Compliance Graph; Synchronous Firing; High-Performance Computing;
|
||||
\section{Introduction}
|
||||
Cybersecurity has been at the forefront of computing for decades, and vulnerability analysis modeling has been utilized to mitigate threats to aid in this effort. One such modeling approach is to represent a system or a set of systems through graphical means, and encode information into the nodes and edges of the graph. Even as early as the late 1990s, experts have composed various graphical models to map devices and vulnerabilities through attack trees, and this work can be seen through the works published by the authors of \cite{phillips_graph-based_1998}.
|
||||
This work, and other attack tree discussions of this time such as that conducted by the author of \cite{schneier_modeling_1999}, would later be referred to as early versions of modern-day attack graphs \cite{ou_scalable_2006}.
|
||||
By utilizing this graphical approach, cybersecurity postures can be measured at a system's current status, as well as hypothesize and examine other postures based on system changes over time. 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} and the authors of \cite{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}.
|
||||
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}, \cite{baloyi_guidelines_2019}, and \cite{allman_complying_2006} discuss, cyber-physical systems have seen greater usage, especially in areas such as critical infrastructure and IoT. The challenge of
|
||||
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.
|
||||
|
||||
@ -86,7 +90,7 @@ The last difference is that the work by the author of \cite{louthan_hybrid_2011}
|
||||
|
||||
\section{Inseparable Features} \label{sec:inseparable}
|
||||
One main appeal of attack graphs and compliance graphs are their exhaustiveness. The ability to generate all permutations of attack chains or to generate all possible ways a system can fall out of compliance is a valuable feature. The disadvantage of this approach is that the generation of the final graph increases in time, as does the analysis.
|
||||
One other disadvantage is that this exhaustiveness can produce states that are not actually attainable or realistic, as briefly mentioned in Section \ref{sec:sync-lit}. When a system has assets that have inseparable features, the generation process forcibly separates features to examine all permutations, since the generation process only modifies one quality at a time.
|
||||
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 Figure \ref{fig:non-sync_ex}, which is a partial attack graph showing the separation of the time feature.
|
||||
All shaded states are considered unattainable, since all of these states comprise of assets that have advanced time at different rates. It is noticeable that not only are the unattainable states themselves a wasteful generation, but they also lead to the generation of even more unattainable states that will then also be explored.
|
||||
@ -100,15 +104,15 @@ A better procedure for a generation process similar to this example is to have a
|
||||
\end{figure}
|
||||
|
||||
Post-processing is one option at removing the unattainable states. This process would simplify and reduce the time taken for the analysis process, but the generation process would still suffer from generating and exploring the unattainable states, and would still need to go through a post-processing step.
|
||||
Instead, a new feature called synchronous firing can be used to prevent the generation of these states. The goal of the synchronous firing feature is to prevent the generation of unattainable states, while also not incurring a greater computational cost. Section \ref{sec:implementing} will discuss the development of this feature, and Section \ref{sec:Results} will examine the results when using this feature in applicable networks.
|
||||
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. This Section will consist of subsections discussing the development of these four alterations.
|
||||
For the implementation of the synchronous firing feature, there were four primary changes and additions that were necessary. The first is a change in the lexical analyzer, the second involves multiple changes to PostgreSQL, the third is the implementation of compound operators, and lastly is a change in the graph generation process. 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. However, rather than having both global and group keywords, this work only incorporates the group keyword to prevent a few of the difficulties discussed in Section \ref{sec:sync-lit}.
|
||||
The new ``group" keyword is intended to be used when creating the exploit files. The design of exploits in the exploit file is developed as:
|
||||
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}
|
||||
@ -145,13 +149,13 @@ Many of the graphs previously generated by RAGE comprise of states with features
|
||||
To expand on the types and complexities of graphs that can be generated and to allow for synchronous firing, compound operators have been added to RAGE. When updating a state, rather than setting a quality to a specific value, the previous value can now be modified by an amount specified through standard compound operators such as $\mathrel{+}=$, $\mathrel{-}=$, $\mathrel{*}=$, or $\mathrel{/}=$.
|
||||
Previous work on an attack graph generator included the implementation of compound operators, as seen by the author of \cite{nichols_2018}. However, this work was conducted on the previous iteration of an attack graph generator written in Python. This attack graph generator has since been rewritten in C++ by the author of \cite{cook_rage_2018}, and compound operators were not included in the latest version of RAGE.
|
||||
|
||||
The work conducted by the author of \cite{cook_rage_2018} when designing the software architecture of RAGE included specifications for a quality encoding scheme. As the author discusses, qualities have four fields, which include the asset ID, attributes, operator, and value. The operator field is 4 bits, which allows for a total of 16 operators. Since the only operator in use at the time was the $``\mathrel{=}"$ operator, the addition of four compound operators does not surpass the 16 operator limit, and no encoding scheme changes were necessary. This also allows for additional compound operators to be incorporated in the future.
|
||||
The work conducted by the author of \cite{cook_rage_2018} when designing the software architecture of RAGE included specifications for a quality encoding scheme. As 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. Auxiliary functions related to this new member, such as prints and getters, were also added. In addition, preconditions were altered to include operator overloads to check the asset identifier, quality name, and quality values for the update process.
|
||||
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. Figure \ref{fig:sync-fire} displays the synchronous fire approach.
|
||||
@ -170,25 +174,28 @@ The implementation of synchronous firing in the graph generation process relies
|
||||
\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 Intel Xeon E5-2620 v3}
|
||||
\item{Two Intel Xeon Phi Co-Processors}
|
||||
\item{One FPGA (Nallatech PCIE-385n A7 Altera Stratix V)}
|
||||
\item{Memory: 64318MiB}
|
||||
\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 test only employs one service, and it is dedicated to brake pads. The 2 Service test 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 tests.
|
||||
The testing information is as follows:
|
||||
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 tests ran for 12 months, with time steps of 1 month.}
|
||||
\item{All tests had the same number of compliance checks: brake pads, exhaust pipes, vacuum pumps, AC filters, oil changes, and driveshaft boots.}
|
||||
\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 tests used the same network model.}
|
||||
\item{All tests used the same exploit file, with the exception of the ``group" keyword being present in the synchronous firing testing.}
|
||||
\item{Services must be performed prior to advancing time, if services are applicable.}
|
||||
\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}
|
||||
|
||||
@ -204,11 +211,11 @@ The compliance checks are as follows:
|
||||
|
||||
\subsection{Results and Analysis}
|
||||
\subsubsection{Results for the Theoretical Environment} \label{sec:theo_res}
|
||||
Using the testing 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. There was also a collection of the graphs' edge to state ratio (E/S Ratio). 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. Figure \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.
|
||||
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. Figure \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.
|
||||
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
|
||||
@ -236,6 +243,7 @@ When comparing the E/S Ratio for the non-synchronous graphs to the E/S Ratio for
|
||||
|
||||
\begin{table}[htp]
|
||||
\centering
|
||||
\setlength\tabcolsep{4pt}
|
||||
\begin{tabular}{|c|c|c|c|c|}
|
||||
\hline
|
||||
\multicolumn{5}{|c|}{Non-Synchronous Firing} \\ \hline
|
||||
@ -252,12 +260,13 @@ When comparing the E/S Ratio for the non-synchronous graphs to the E/S Ratio for
|
||||
5 & 209944 & 1254784 & 588336.01 & 5.977 \\ \hline
|
||||
6 & 423940 & 2712165 & 1581697.61 & 6.398 \\ \hline
|
||||
\end{tabular}`'
|
||||
\caption{Tabled Results for the Non-Synchronous Firing Testing}
|
||||
\caption{Results for the Non-Synchronous Firing Testing}
|
||||
\label{table:NS-Table}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[htp]
|
||||
\centering
|
||||
\setlength\tabcolsep{4pt}
|
||||
\begin{tabular}{|c|c|c|c|c|c|}
|
||||
\hline
|
||||
\multicolumn{6}{|c|}{Synchronous Firing} \\ \hline
|
||||
@ -268,21 +277,21 @@ When comparing the E/S Ratio for the non-synchronous graphs to the E/S Ratio for
|
||||
& \textbf{\begin{tabular}[c]{@{}c@{}}E/S\\Ratio\end{tabular}}
|
||||
& \textbf{\begin{tabular}[c]{@{}c@{}}Speedup\end{tabular}}
|
||||
\\ \hline
|
||||
1 & 6277 & 34569 & 14872.86 & 5.507 & 5.87 \\ \hline
|
||||
2 & 11653 & 69385 & 29251.56 & 5.954 & 3.96 \\ \hline
|
||||
3 & 25317 & 160041 & 66799.18 & 6.321 & 2.76 \\ \hline
|
||||
4 & 36949 & 241577 & 102216.30 & 6.538 & 2.47 \\ \hline
|
||||
5 & 83134 & 570930 & 243612.05 & 6.868 & 2.42 \\ \hline
|
||||
6 & 186679 & 1345818 & 581840.76 & 7.209 & 2.72 \\ \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}
|
||||
\caption{Tabled Results for the Synchronous Firing Testing}
|
||||
\caption{Results for the Synchronous Firing Testing}
|
||||
\label{table:S-Table}
|
||||
\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.
|
||||
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}).
|
||||
|
||||
@ -292,14 +301,15 @@ Leveraging comprehensive services with synchronous firing enables users to signi
|
||||
|
||||
\begin{table}[htp]
|
||||
\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}}
|
||||
& \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
|
||||
@ -308,12 +318,13 @@ Leveraging comprehensive services with synchronous firing enables users to signi
|
||||
\begin{tabular}[c]{@{}c@{}}All \\ Conjoined\end{tabular}
|
||||
& 19764 & 87024 & 47126.42 & 4.403 \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Tabled Results for the Comprehensive Services without Synchronous Firing}
|
||||
\caption{Results for the Comprehensive Services without Synchronous Firing}
|
||||
\label{table:Non-Sync-Comp-Table}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[htp]
|
||||
\centering
|
||||
\setlength\tabcolsep{4pt}
|
||||
\begin{tabular}{|c|c|c|c|c|c|}
|
||||
\hline
|
||||
\multicolumn{6}{|c|}{Comprehensive Services with Synchronous Firing} \\ \hline
|
||||
@ -331,7 +342,7 @@ Leveraging comprehensive services with synchronous firing enables users to signi
|
||||
\begin{tabular}[c]{@{}c@{}}All \\ Conjoined\end{tabular}
|
||||
& 3774 & 18370 & 9261.03 & 4.868 & 5.09 \\ \hline
|
||||
\end{tabular}
|
||||
\caption{Tabled Results for the Comprehensive Services with Synchronous Firing}
|
||||
\caption{Results for the Comprehensive Services with Synchronous Firing}
|
||||
\label{table:Sync-Comp-Table}
|
||||
\end{table}
|
||||
|
||||
@ -361,9 +372,9 @@ Leveraging comprehensive services with synchronous firing enables users to signi
|
||||
|
||||
|
||||
\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 test scenario to have a greater number of assets, and a standard set of exploits more akin to an attack graph. Other future works could include measuring the performance of synchronous firing when multiple groups of inseparable features are used. This work used a single group, but multiple groups be added to examine the performance of the feature.
|
||||
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 works 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 differences between 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.
|
||||
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.
|
||||
|
||||
|
||||
21
texput.log
Normal file
21
texput.log
Normal file
@ -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!
|
||||
Loading…
x
Reference in New Issue
Block a user