Editing Chapter 1
This commit is contained in:
parent
e2c2bf4d05
commit
c6f3760767
@ -1228,8 +1228,40 @@
|
||||
|
||||
|
||||
@misc{lawrence_livermore_national_laboratory_mpip_nodate,
|
||||
title = {{mpiP}},
|
||||
title = {mpiP},
|
||||
shorttitle = {A light-weight {MPI} profiler.},
|
||||
url = {https://software.llnl.gov/mpiP/},
|
||||
author = {{Lawrence Livermore National Laboratory}},
|
||||
}
|
||||
|
||||
|
||||
@misc{noauthor_sarbanes-oxley_2002,
|
||||
title = {Sarbanes-{Oxley} {Act} of 2002},
|
||||
url = {https://www.govinfo.gov/content/pkg/PLAW-107publ204/html/PLAW-107publ204.htm},
|
||||
year = {2002},
|
||||
}
|
||||
|
||||
@misc{noauthor_health_1996,
|
||||
title = {Health {Insurance} {Portability} and {Accountability} {Act} of 1996},
|
||||
url = {https://www.govinfo.gov/content/pkg/PLAW-104publ191/html/PLAW-104publ191.htm},
|
||||
year = {1996},
|
||||
}
|
||||
|
||||
@online{EUdataregulations2018,
|
||||
title = {REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
|
||||
of 27},
|
||||
url = {https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679},
|
||||
author = {The European Parliment and the Council of the European Union},
|
||||
date = {2016-04-27}
|
||||
}
|
||||
|
||||
@misc{PCI,
|
||||
title = {Payment Card Industry (PCI) Data Security Standard},
|
||||
url = {https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf},
|
||||
month = may,
|
||||
year = {2018},
|
||||
author = {PCI Security Standards Council}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
12
Chapter1.aux
12
Chapter1.aux
@ -12,13 +12,17 @@
|
||||
\citation{baloyi_guidelines_2019}
|
||||
\citation{allman_complying_2006}
|
||||
\citation{j_hale_compliance_nodate}
|
||||
\citation{j_hale_compliance_nodate}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1.2}\bf Application to Compliance}{2}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.1}\it Introduction to Compliance Graphs}{2}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.2}\it Defining Compliance Graphs}{2}{}\protected@file@percent }
|
||||
\newlabel{CG-alter}{{1.2.2}{2}}
|
||||
\citation{j_hale_compliance_nodate}
|
||||
\citation{noauthor_sarbanes-oxley_2002}
|
||||
\citation{noauthor_health_1996}
|
||||
\citation{EUdataregulations2018}
|
||||
\citation{PCI}
|
||||
\citation{cook_rage_2018}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.3}\it Difficulties of Compliance Graphs and Introduction to Thesis Work}{3}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.2}\it Defining Compliance Graphs}{3}{}\protected@file@percent }
|
||||
\newlabel{CG-alter}{{1.2.2}{3}}
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2.3}\it Difficulties of Compliance Graphs}{3}{}\protected@file@percent }
|
||||
\newlabel{sec:CG-diff}{{1.2.3}{3}}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1.3}\bf Objectives and Contributions}{4}{}\protected@file@percent }
|
||||
\@setckpt{Chapter1}{
|
||||
|
||||
36
Chapter1.tex
36
Chapter1.tex
@ -7,42 +7,40 @@ This work, and other attack tree discussions of this time such as that conducted
|
||||
\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 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
|
||||
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 the authors of \cite{ou_scalable_2006} examine, even very small networks with only 10 hosts and 5 vulnerabilities yield graphs with 10 million
|
||||
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, this becomes infeasible. Similar difficulties arise in related fields, where social networks, bio-informatics, and neural network representations also result in graphs with millions of
|
||||
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}. Various efforts that will be discussed in Section \ref{sec:related_works} demonstrate methods and techniques that can mitigate these difficulties and improve performance.
|
||||
|
||||
\TUsection{Application to Compliance}
|
||||
\TUsubsection{Introduction to Compliance Graphs}
|
||||
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 like critical infrastructure and Internet of Things. The challenge of
|
||||
\cite{baloyi_guidelines_2019}, and \cite{allman_complying_2006} discuss, cyber-physical systems have seen greater usage, especially in areas such as critical infrastructure and Internet of Things. The challenge of
|
||||
cyber-physical systems lies not only in the demand for cybersecurity of these systems, but also the concern for safe, stable, and undamaged equipment. The industry in which these devices are used can lead to
|
||||
additional compliance guidelines that must be followed. Compliance graphs are promising tools that can aid in minimizing the difficulties of these systems.
|
||||
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.
|
||||
|
||||
A few alterations are needed to attack graph generators to function as compliance graph generators, and these alterations
|
||||
A few alterations are required for attack graph generators to function as compliance graph generators, and these alterations
|
||||
are discussed in Section \ref{CG-alter}. Compliance requirements are broad and varying, and can function as safety regulations, maintenance compliance, or any
|
||||
other regulatory compliance. In the same fashion as attack graphs, compliance graphs are exhaustive, and future system states can be analyzed to determine appropriate steps that need to be taken for
|
||||
preventative measures \cite{j_hale_compliance_nodate}.
|
||||
\TUsubsection{Defining Compliance Graphs} \label{CG-alter}
|
||||
The common features of attack graphs serve separate purposes in compliance graphs. The nodes of an attack graph typically represent the system state that includes the qualities and topologies of all assets
|
||||
The common encodings of attack graph properties have different encoding definitions in compliance graphs. The nodes of an attack graph typically represent the system state that includes the qualities and topologies of all assets
|
||||
in the network as they pertain to cybersecurity postures. Nodes of a compliance graphs also represent the system state, however they include the qualities and topologies of all assets in the network as they
|
||||
pertain to compliance regulation. For instance, a quality for a vehicle's maintenance compliance could be described as: \textit{car:months\_since\_oil\_change=6}, or \textit{car:miles\_since\_oil\_change=10,000}.
|
||||
Edges represent changes to a system state that inserted, modified, or deleted a quality or topology. Using the car example, an edge could represent the addition of more mileage or more time since the last oil change.
|
||||
One large differentiation of attack graphs and compliance graphs can be seen through topologies. For assets in attack graphs, topologies typically represent a connection of assets through a digital medium. For
|
||||
compliance graphs, topologies not only need to represent the digital connections of assets, but also need extensions to incorporate hardware devices such as sensors, actuators, or other equipment
|
||||
\cite{j_hale_compliance_nodate}. In addition, rather than using applicable exploits or vulnerabilities, compliance violation detections should be used. An attack graph generation engine would need to use compliance
|
||||
compliance graphs, topologies not only need to represent the digital connections of assets, but also need extensions to incorporate hardware devices such as sensors, actuators, or other physical equipment
|
||||
\cite{j_hale_compliance_nodate}. In addition, rather than using applicable exploits or vulnerabilities to an asset, compliance violation detections should be used. An attack graph generation engine would need to use compliance
|
||||
parameters rather than exploit files, but would otherwise function similarly in the generation process.
|
||||
\TUsubsection{Difficulties of Compliance Graphs and Introduction to Thesis Work} \label{sec:CG-diff}
|
||||
\TUsubsection{Difficulties of Compliance Graphs} \label{sec:CG-diff}
|
||||
Like attack graphs, compliance graphs suffer from the state space explosion problem. Since compliance graphs are also exhaustive, the resulting networks can grow to incredibly large sizes. Compliance regulations
|
||||
that need to be checked at each system state such as SOX, HIPAA, GDPR, PCI DSS, or any other regulatory compliance in conjunction with a large number of assets that need to be checked can very quickly produce
|
||||
these large resulting graphs. The creation of these graphs through a serial approach likewise becomes increasingly infeasible. Due to this, the high-performance computing (HPC) space presents itself as an appealing
|
||||
approach. This work aims to extend the attack graph generator engine RAGE presented by the author in \cite{cook_rage_2018} to begin development for compliance graph generation. The example networks in this
|
||||
work will also be in the compliance graph space, specifically examining vehicle maintenance compliance. This work will also examine approaches to leverage high-performance computing to aid in the generation of
|
||||
compliance graphs.
|
||||
that need to be checked at each system state such as SOX \cite{noauthor_sarbanes-oxley_2002}, HIPAA \cite{noauthor_health_1996}, GDPR \cite{EUdataregulations2018}, PCI DSS \cite{PCI}, or any other regulatory compliance in conjunction with a large number of assets that need to be checked can very quickly produce large resulting graphs. The creation of these graphs through a serial approach likewise becomes increasingly infeasible in a reasonable amount of time. Due to this, the high-performance computing (HPC) space presents itself as an appealing
|
||||
approach. This work aims to extend the attack graph generator engine RAGE in \cite{cook_rage_2018} to begin development for compliance graph generation. The example networks in this
|
||||
work will also be in the compliance graph space, specifically examining vehicle maintenance compliance. This work will also examine approaches to leverage high-performance computing to aid in the generation of compliance graphs.
|
||||
|
||||
\TUsection{Objectives and Contributions}
|
||||
The objectives of this thesis are:
|
||||
@ -51,12 +49,12 @@ The objectives of this thesis are:
|
||||
\begin{enumerate}
|
||||
\item{Reduce the complexity required for network model and exploit file creation}
|
||||
\item{Expand the complexity of attack modeling}
|
||||
\item{Allow for the creation of an infinite sized Attack Graph, assuming infinite storage}
|
||||
\item{Allow for the creation of a very large sized attack graph, assuming very large storage}
|
||||
\item{Split Attack Graphs into subgraphs to simplify analysis of individual clusters}
|
||||
\end{enumerate}
|
||||
\item{Implement solutions to reduce state space explosion for inseparable features while remaining exhaustive and capturing all necessary information}
|
||||
\item{Extend RAGE to function for heterogeneous distributed computing environments}
|
||||
\item{Extend and utilize RAGE for compliance graph generation}
|
||||
\item{Implement a synchronous firing solution to reduce state space explosion for inseparable features while remaining exhaustive and capturing all necessary information}
|
||||
\item{Extend RAGE to function for distributed computing environments}
|
||||
\item{Extend RAGE to support compliance graph generation}
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
@ -1,7 +1,12 @@
|
||||
|
||||
@misc{lawrence_livermore_national_laboratory_mpip_nodate,
|
||||
title = {{mpiP}},
|
||||
shorttitle = {A light-weight {MPI} profiler.},
|
||||
url = {https://software.llnl.gov/mpiP/},
|
||||
author = {{Lawrence Livermore National Laboratory}},
|
||||
@misc{noauthor_sarbanes-oxley_2002,
|
||||
title = {Sarbanes-{Oxley} {Act} of 2002},
|
||||
url = {https://www.govinfo.gov/content/pkg/PLAW-107publ204/html/PLAW-107publ204.htm},
|
||||
year = {2002},
|
||||
}
|
||||
|
||||
@misc{noauthor_health_1996,
|
||||
title = {Health {Insurance} {Portability} and {Accountability} {Act} of 1996},
|
||||
url = {https://www.govinfo.gov/content/pkg/PLAW-104publ191/html/PLAW-104publ191.htm},
|
||||
year = {1996},
|
||||
}
|
||||
|
||||
@ -28,28 +28,32 @@
|
||||
\bibcite{j_hale_compliance_nodate}{6}
|
||||
\bibcite{baloyi_guidelines_2019}{7}
|
||||
\bibcite{allman_complying_2006}{8}
|
||||
\bibcite{cook_rage_2018}{9}
|
||||
\bibcite{berry_graph_2007}{10}
|
||||
\bibcite{noauthor_sarbanes-oxley_2002}{9}
|
||||
\bibcite{noauthor_health_1996}{10}
|
||||
\bibcite{EUdataregulations2018}{11}
|
||||
\@writefile{toc}{{\hfill \ }}
|
||||
\@writefile{toc}{\contentsline {section}{\hspace {-\parindent }NOMENCLATURE}{53}{}\protected@file@percent }
|
||||
\@writefile{toc}{\addvspace {10pt}}
|
||||
\@writefile{toc}{\contentsline {section}{\hspace {-\parindent }BIBLIOGRAPHY}{53}{}\protected@file@percent }
|
||||
\@writefile{toc}{{\hfill \ }}
|
||||
\bibcite{ainsworth_graph_2016}{11}
|
||||
\bibcite{yao_efficient_2018}{12}
|
||||
\bibcite{dai_fpgp_2016}{13}
|
||||
\bibcite{arifuzzaman_fast_2015}{14}
|
||||
\bibcite{yu_construction_2018}{15}
|
||||
\bibcite{liakos_memory-optimized_2016}{16}
|
||||
\bibcite{balaji_graph_2016}{17}
|
||||
\bibcite{noauthor_overview_nodate}{18}
|
||||
\bibcite{noauthor_boost_nodate}{19}
|
||||
\bibcite{cook_scalable_2016}{20}
|
||||
\bibcite{li_concurrency_2019}{21}
|
||||
\bibcite{9150145}{22}
|
||||
\bibcite{7087377}{23}
|
||||
\bibcite{li_combining_2019}{24}
|
||||
\bibcite{CVE-2019-10747}{25}
|
||||
\bibcite{louthan_hybrid_2011}{26}
|
||||
\bibcite{PCI}{12}
|
||||
\bibcite{cook_rage_2018}{13}
|
||||
\bibcite{berry_graph_2007}{14}
|
||||
\bibcite{ainsworth_graph_2016}{15}
|
||||
\bibcite{yao_efficient_2018}{16}
|
||||
\bibcite{dai_fpgp_2016}{17}
|
||||
\bibcite{arifuzzaman_fast_2015}{18}
|
||||
\bibcite{yu_construction_2018}{19}
|
||||
\bibcite{liakos_memory-optimized_2016}{20}
|
||||
\bibcite{balaji_graph_2016}{21}
|
||||
\bibcite{noauthor_overview_nodate}{22}
|
||||
\bibcite{noauthor_boost_nodate}{23}
|
||||
\bibcite{cook_scalable_2016}{24}
|
||||
\bibcite{li_concurrency_2019}{25}
|
||||
\bibcite{9150145}{26}
|
||||
\bibcite{7087377}{27}
|
||||
\bibcite{li_combining_2019}{28}
|
||||
\bibcite{CVE-2019-10747}{29}
|
||||
\bibcite{louthan_hybrid_2011}{30}
|
||||
\bibstyle{ieeetr}
|
||||
\gdef \@abspage@last{65}
|
||||
\gdef \@abspage@last{66}
|
||||
|
||||
@ -39,6 +39,20 @@ N.~Baloyi and P.~Kotzé, ``Guidelines for {Data} {Privacy} {Compliance}: {A}
|
||||
E.~Allman, ``Complying with {Compliance}: {Blowing} it off is not an option.,''
|
||||
{\em ACM Queue}, vol.~4, no.~7, 2006.
|
||||
|
||||
\bibitem{noauthor_sarbanes-oxley_2002}
|
||||
``Sarbanes-{Oxley} {Act} of 2002,'' 2002.
|
||||
|
||||
\bibitem{noauthor_health_1996}
|
||||
``Health {Insurance} {Portability} and {Accountability} {Act} of 1996,'' 1996.
|
||||
|
||||
\bibitem{EUdataregulations2018}
|
||||
T.~E. Parliment and the Council of~the European~Union, ``Regulation (eu)
|
||||
2016/679 of the european parliament and of the council of 27.''
|
||||
|
||||
\bibitem{PCI}
|
||||
P.~S.~S. Council, ``Payment card industry (pci) data security standard,'' May
|
||||
2018.
|
||||
|
||||
\bibitem{cook_rage_2018}
|
||||
K.~Cook, {\em {RAGE}: {The} {Rage} {Attack} {Graph} {Engine}}.
|
||||
\newblock PhD thesis, 2018.
|
||||
|
||||
@ -7,45 +7,45 @@ A level-1 auxiliary file: Chapter3.aux
|
||||
A level-1 auxiliary file: Chapter4.aux
|
||||
A level-1 auxiliary file: Chapter5.aux
|
||||
A level-1 auxiliary file: Chapter6.aux
|
||||
A level-1 auxiliary file: Chapter7.aux
|
||||
The style file: ieeetr.bst
|
||||
A level-1 auxiliary file: Appendices.aux
|
||||
Database file #1: Bibliography.bib
|
||||
Warning--entry type for "j_hale_compliance_nodate" isn't style-file defined
|
||||
--line 272 of file Bibliography.bib
|
||||
Warning--entry type for "EUdataregulations2018" isn't style-file defined
|
||||
--line 1250 of file Bibliography.bib
|
||||
Warning--empty journal in ou_scalable_2006
|
||||
Warning--empty school in cook_rage_2018
|
||||
Warning--empty school in louthan_hybrid_2011
|
||||
You've used 26 entries,
|
||||
You've used 30 entries,
|
||||
1876 wiz_defined-function locations,
|
||||
611 strings with 8617 characters,
|
||||
and the built_in function-call counts, 6036 in all, are:
|
||||
= -- 571
|
||||
> -- 237
|
||||
622 strings with 9004 characters,
|
||||
and the built_in function-call counts, 6493 in all, are:
|
||||
= -- 608
|
||||
> -- 251
|
||||
< -- 0
|
||||
+ -- 90
|
||||
- -- 64
|
||||
* -- 401
|
||||
:= -- 842
|
||||
add.period$ -- 26
|
||||
call.type$ -- 26
|
||||
change.case$ -- 24
|
||||
+ -- 97
|
||||
- -- 67
|
||||
* -- 418
|
||||
:= -- 895
|
||||
add.period$ -- 29
|
||||
call.type$ -- 30
|
||||
change.case$ -- 28
|
||||
chr.to.int$ -- 0
|
||||
cite$ -- 29
|
||||
duplicate$ -- 317
|
||||
empty$ -- 623
|
||||
format.name$ -- 64
|
||||
if$ -- 1474
|
||||
cite$ -- 33
|
||||
duplicate$ -- 333
|
||||
empty$ -- 695
|
||||
format.name$ -- 67
|
||||
if$ -- 1596
|
||||
int.to.chr$ -- 0
|
||||
int.to.str$ -- 26
|
||||
int.to.str$ -- 30
|
||||
missing$ -- 19
|
||||
newline$ -- 84
|
||||
num.names$ -- 23
|
||||
pop$ -- 119
|
||||
newline$ -- 96
|
||||
num.names$ -- 25
|
||||
pop$ -- 147
|
||||
preamble$ -- 1
|
||||
purify$ -- 0
|
||||
quote$ -- 0
|
||||
skip$ -- 210
|
||||
skip$ -- 231
|
||||
stack$ -- 0
|
||||
substring$ -- 347
|
||||
swap$ -- 108
|
||||
@ -54,7 +54,7 @@ text.prefix$ -- 0
|
||||
top$ -- 0
|
||||
type$ -- 0
|
||||
warning$ -- 3
|
||||
while$ -- 57
|
||||
width$ -- 28
|
||||
write$ -- 223
|
||||
(There were 4 warnings)
|
||||
while$ -- 59
|
||||
width$ -- 32
|
||||
write$ -- 248
|
||||
(There were 5 warnings)
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
This is pdfTeX, Version 3.141592653-2.6-1.40.23 (TeX Live 2021/Arch Linux) (preloaded format=pdflatex 2022.3.21) 27 MAR 2022 13:31
|
||||
This is pdfTeX, Version 3.141592653-2.6-1.40.23 (TeX Live 2021/Arch Linux) (preloaded format=pdflatex 2022.3.21) 27 MAR 2022 17:52
|
||||
entering extended mode
|
||||
restricted \write18 enabled.
|
||||
%&-line parsing enabled.
|
||||
@ -486,7 +486,7 @@ CHAPTER 6.
|
||||
|
||||
|
||||
|
||||
] [54]) [55]
|
||||
] [54] [55]) [56]
|
||||
(./Schrick-Noah_MS-Thesis.aux (./Chapter1.aux) (./Chapter2.aux) (./Chapter3.aux
|
||||
) (./Chapter4.aux) (./Chapter5.aux) (./Chapter6.aux))
|
||||
|
||||
@ -495,7 +495,7 @@ LaTeX Warning: There were undefined references.
|
||||
)
|
||||
(\end occurred inside a group at level 6)
|
||||
|
||||
### semi simple group (level 6) entered at line 200 (\begingroup)
|
||||
### semi simple group (level 6) entered at line 197 (\begingroup)
|
||||
### semi simple group (level 5) entered at line 182 (\begingroup)
|
||||
### semi simple group (level 4) entered at line 182 (\begingroup)
|
||||
### semi simple group (level 3) entered at line 182 (\begingroup)
|
||||
@ -503,10 +503,10 @@ LaTeX Warning: There were undefined references.
|
||||
### semi simple group (level 1) entered at line 52 (\begingroup)
|
||||
### bottom level
|
||||
Here is how much of TeX's memory you used:
|
||||
3746 strings out of 478276
|
||||
71206 string characters out of 5853013
|
||||
362050 words of memory out of 5000000
|
||||
21877 multiletter control sequences out of 15000+600000
|
||||
3750 strings out of 478276
|
||||
71286 string characters out of 5853013
|
||||
362066 words of memory out of 5000000
|
||||
21881 multiletter control sequences out of 15000+600000
|
||||
473155 words of font info for 41 fonts, out of 8000000 for 9000
|
||||
1141 hyphenation exceptions out of 8191
|
||||
67i,8n,77p,2199b,1424s stack positions out of 5000i,500n,10000p,200000b,80000s
|
||||
@ -518,10 +518,10 @@ ts/type1/public/amsfonts/cm/cmr12.pfb></usr/share/texmf-dist/fonts/type1/public
|
||||
y10.pfb></usr/share/texmf-dist/fonts/type1/public/amsfonts/cm/cmti12.pfb></usr/
|
||||
share/texmf-dist/fonts/type1/public/amsfonts/cm/cmtt12.pfb></usr/share/texmf-di
|
||||
st/fonts/type1/public/cm-super/sfrm1200.pfb>
|
||||
Output written on Schrick-Noah_MS-Thesis.pdf (65 pages, 2059503 bytes).
|
||||
Output written on Schrick-Noah_MS-Thesis.pdf (66 pages, 2061592 bytes).
|
||||
PDF statistics:
|
||||
304 PDF objects out of 1000 (max. 8388607)
|
||||
171 compressed objects within 2 object streams
|
||||
307 PDF objects out of 1000 (max. 8388607)
|
||||
173 compressed objects within 2 object streams
|
||||
0 named destinations out of 1000 (max. 500000)
|
||||
131 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
|
||||
|
||||
Binary file not shown.
@ -154,10 +154,10 @@
|
||||
\fifthmember{} % as needed
|
||||
\sixthmember{} % as needed
|
||||
|
||||
\numofpages{92} % number of pages in the document
|
||||
\numofpages{65} % number of pages in the document
|
||||
\numofchapters=6 % number of chapters in the document
|
||||
\lastchapter{Conclusions and Future Works} % the title of the last numbered chapter
|
||||
\numofabstractwords{29} % number of words in the abstract
|
||||
\numofabstractwords{196} % number of words in the abstract
|
||||
|
||||
%
|
||||
% If this is a thesis use \thesistrue
|
||||
@ -185,7 +185,7 @@
|
||||
%
|
||||
% Place the text of the abstract here
|
||||
%
|
||||
Attack graphs have historically been used to represent the state of a system or set of systems, and illustrate ways that attackers can carry out exploits to put the systems in a critical position. By refining the information and format of Attack Graphs, a similar process can be applied for compliance and regulation representations to illustrate ways that systems may violate or fall out of compliance in a format called compliance graphs. Like attack graphs, compliance graphs also suffer from the state space explosion problem, and generated graphs quickly become very large even for small networks. This work introduces extensions to an attack graph generator, RAGE, to support compliance graph generation, and these extensions have led to successfully generating compliance graphs that can then be analyzed through an independent process. Additional extensions have been introduced to support the utility of RAGE, and also implements a synchronous firing feature to prevent generation of states where assets deviate from a shared, inseparable feature such as time. The attack graph generation algorithm has also been modified in different two approaches to expand the generation process to function for distributed computing environments using Message Passing Interface (MPI).
|
||||
Attack graphs have historically been used to represent the state of a system or set of systems, and illustrate ways that attackers can carry out exploits to put the systems in a critical position. By refining the information and format of attack graphs, a similar process can be applied for compliance and regulation representations to illustrate ways that systems may violate or fall out of compliance in a format called compliance graphs. Like attack graphs, compliance graphs also suffer from the state space explosion problem, and generated graphs quickly become very large even for small networks. This work introduces extensions to an attack graph generator, RAGE, to support compliance graph generation, and these extensions have led to successfully generating compliance graphs that can then be analyzed through an independent process. Additional extensions have been introduced to support the utility of RAGE, and this includes the implementation of a synchronous firing feature to prevent generation of states where assets deviate from a shared, inseparable feature such as time. The attack graph generation algorithm has also been modified by two different approaches to expand the generation process to function for distributed computing environments using Message Passing Interface (MPI).
|
||||
|
||||
\acknowledgementsp
|
||||
%
|
||||
|
||||
@ -14,8 +14,8 @@
|
||||
\contentsline {section}{\numberline {1.1}\bf Introduction to Attack Graphs}{1}{}%
|
||||
\contentsline {section}{\numberline {1.2}\bf Application to Compliance}{2}{}%
|
||||
\contentsline {subsection}{\numberline {1.2.1}\it Introduction to Compliance Graphs}{2}{}%
|
||||
\contentsline {subsection}{\numberline {1.2.2}\it Defining Compliance Graphs}{2}{}%
|
||||
\contentsline {subsection}{\numberline {1.2.3}\it Difficulties of Compliance Graphs and Introduction to Thesis Work}{3}{}%
|
||||
\contentsline {subsection}{\numberline {1.2.2}\it Defining Compliance Graphs}{3}{}%
|
||||
\contentsline {subsection}{\numberline {1.2.3}\it Difficulties of Compliance Graphs}{3}{}%
|
||||
\contentsline {section}{\numberline {1.3}\bf Objectives and Contributions}{4}{}%
|
||||
\contentsline {chapter}{\numberline {CHAPTER 2: }{\bf \uppercase {RELATED WORKS}}}{5}{}%
|
||||
\contentsline {section}{\numberline {2.1}\bf Introduction to Graph Generation}{5}{}%
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user