Perf Expect
This commit is contained in:
parent
71ed2b2178
commit
ad8e5866cf
@ -1,5 +1,5 @@
|
||||
\TUchapter{INTRODUCTION}
|
||||
\TUsection{Introduction to Attack Graphs}
|
||||
\TUsection{Introduction to Attack Graphs} \label{sec:Into}
|
||||
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}.
|
||||
@ -36,7 +36,7 @@ One large differentiation of attack graphs and compliance graphs can be seen thr
|
||||
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
|
||||
parameters rather than exploit files, but would otherwise function similarly in the generation process.
|
||||
\TUsubsection{Difficulties of Compliance Graphs and Introduction to Thesis Work}
|
||||
\TUsubsection{Difficulties of Compliance Graphs and Introduction to Thesis Work} \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 space presents itself as an appealing
|
||||
|
||||
@ -128,6 +128,7 @@ To ensure that the intended message is received by each node, the MPI message en
|
||||
\end{table}
|
||||
|
||||
\TUsubsection{Performance Expectations}
|
||||
Due to the amount of communication between nodes to distribute the necessary data through all stages of the tasking pipeline, this approach is not expected to outperform the serial approach in all cases. This tasking approach was specifically designed to reduce the computation time when the generation of each individual state increases in time. This approach does not offer any guarantees of processing through the frontier at an increased rate; it's main objective is to distribute the workload of individual state generation. As discussed in Section \ref{sec:Intro}, the amount of entries in the National Vulnerability database and any custom vulnerability testing to ensure adequate examination of all assets in the network sums to large number of exploits in the exploit list. Likewise for compliance graphs and compliance examinations, Section \ref{sec:CG-diff} mentioned the number of compliance checks for SOX, HIPAA, GDPR, PCI DSS, and/or any other regulatory compliance also sums to a large number of exploits in the exploit list. Since the generation of each state is largely dependent on the number of exploits present in the exploit list, this approach is best-suited for when the exploit list grows in size.
|
||||
|
||||
\TUsubsection{Results}
|
||||
Communication cost of asynchronous send for T4 and T5 is less than the time requirement of a database storage by root.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user