Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Addition of Sources for Business Risk
  • Loading branch information
Duncan committed Jul 10, 2016
1 parent f00642e commit 23182a6
Showing 1 changed file with 82 additions and 42 deletions.
124 changes: 82 additions & 42 deletions AADLSecPaper.tex
Expand Up @@ -220,7 +220,46 @@ One can measure risk from the probability of a failure of a given component (e.g

\subsection{Quantitative and Qualitative Security}
% Summary and application of the Ferrante work
Aggregate all the Ferrante summary stuff here you idiot!
% Development of the verification process
To begin developing the verification and selection process, one needs to create a metric of weights based on the relative importance of any given solution $s_i$ in comparison to solution $s_j$~\cite{Ferrante2013}. The purpose of these weights is to allow for comparison of varying solution elements, relative to each other, as they are used within embedded system security modeling solutions. \textit{Importance} is defined as a ranking that will depend on the case of implementation by a given company/group. Because this value is dependent on the `source' examining a particular security model, the value will be partially arbitrary and partially cost analysis. An other influencing factor could also come from the preference/wheel house of a given company or individual.

% Explain the work done by Ferrante et. al.
Borrowing from the work of Ferrante et.~al.~ using the Analytical Hierarchy Process (AHP), this paper moves to examine the process developed for producing weights for various security solutions.
%First, one must create an arbitrary 1-{}-10 ranking of the importance of any given element in comparison to any other elements of the security design model; where 1 is defined that both elements are equally important and 10 is defined that one element is absolutely more important than the other. These values are then inversed to create a matrix of `relative importances' of the various security model elements with respect to each and every other element in the design. Since the elements of the matrix are based on human judgement there is the possibility that inconsistency may exists. Ferrante et.~al.~ did develop equations to recognize these inconsistencies, but further examination of the process is left to the reader. However, not all aspects of security are going to be quantitative, some will be more qualitative and thus more difficult to deterministically produce values for. A rough method of producing quantitative values from qualitative properties was also proposed by Ferrante et.~al.~; by using the weight developed for a given requirement and multiplying this value by a series of binary representations of whether or not a given feature meets the same requirement that the feature in question is attempting to meet. This is represented by the following equation from Ferrante et.~al.'s work~\cite{Ferrante2013}:
%
%\begin{equation} \label{equ:qualitative}
% L_i = \sum_{j=1}^{R} g_j * v_{ji}, i = 1,2,...,S
%\end{equation}

% XXX what are the L, R, g, and v values?

One must note that there are essentially two values being spoken about in the work by Ferrante et.~al.~; first is the generation of a security metric (named security level) and second generation of a weight metric. The creation of the `security level' metric is a simple mapping of some physical property to a 0.00 -{}- 1.00 scale with 1 being the highest possible security level. Once one has created these weight and security level (SL) metrics, these values can be used to produce security metrics about a given embedded systems security model design.

% Introducing the Security Metric equation
The next consideration is how does one take these produced values and develop a meaningful equation for generating a comparable metric. Following the examination of the work by Ferrante et.~al.~, their definition of `security metric' is as follows:

\begin{multline} \label{equ:securityMetric}
Security Metric (SM) = \\
weight_{elem1} * SL_{elem1}
+ weight_{elem2} * SL_{elem2} \\
+ {...} + weight_{elemN} * SL_{elemN}
\end{multline}

Each `element', in Equation~\ref{equ:securityMetric}, can describe different algorithms, elements, properties, and capabilities of the different components of a system or device.
%It is worth noting that this equation is not necessarily limited to a single use within entire process.
This same style can be used at higher level abstractions of the same design to produce an overall security metric representing a larger system of components. Harking back to our discussion of risk, the following is an example of calculating aggregated security metrics of a system (i.e. network security):

\begin{multline} \label{equ:overallSecMet}
Overall SM = \\
weight_{anti-virus} * SM_{anti-virus}
+ weight_{firewall} * SM_{firewall} \\
+ {...} + weight_{element i} * SM_{element i}
\end{multline}

% Introduction to paper's Security Risk security
This allows for a designer to now create some arbitrary metric to represent whether or not a given design is better or worse at meeting not only the requirements imposed but also in comparison to other available solutions to the same design problem. While this is a step in the right direction, there no units attached to the overall
security metrics produced by the work of Ferrante et.~al. Without a proper unit attached to a generated metric, the entire process remains arbitrary and more difficult to be used in a relevant and meaningful manner. Calling back to the equation proposed in Section~\ref{sec:riskDefinition}, allow us to make use of the same techniques Ferrante et.~al.~developed but apply them in a more meaningful, cost-based manner. In this way it is possible for a `security risk' metric to be generated but also carry a recognizable worth. %instead of just an arbitrary number scheme.
But these values of cost must come from somewhere, and that is the purpose of the impact variable. This is because the impact is a representation of the potential loss caused by an event.

\section{Shit that needs to be elsewhere}

Expand Down Expand Up @@ -351,47 +390,6 @@ One complication of this technique is the requirement to create `libraries' for
% Considerations about the verification process
Ideally verification of a design should be done through validation of the requirements that were met, not met, and any additional features that were introduced due to design decisions of the developer. Certain aspects of this verification process are easier to tackle but just have not had the time and effort focused on them. One such aspect is defining security terms in a manner that can be standardized for use. However, although choosing the language to describe security concepts and ideas may be simple, having that language remain flexible and relevant over the course of security's evolution is not as easy. Working towards an effective, rigorous, and standardized security modeling framework verification methodology is something that will not only benefit the security community, but will allow for better representation and understanding in other fields as well (e.g. business).

% Development of the verification process
To begin developing the verification and selection process, one needs to create a metric of weights based on the relative importance of any given solution $s_i$ in comparison to solution $s_j$~\cite{Ferrante2013}. The purpose of these weights is to allow for comparison of varying solution elements, relative to each other, as they are used within embedded system security modeling solutions. \textit{Importance} is defined as a ranking that will depend on the case of implementation by a given company/group. Because this value is dependent on the `source' examining a particular security model, the value will be partially arbitrary and partially cost analysis. An other influencing factor could also come from the preference/wheel house of a given company or individual.

% Explain the work done by Ferrante et. al.
Borrowing from the work of Ferrante et.~al.~ using the Analytical Hierarchy Process (AHP), this paper moves to examine the process developed for producing weights for various security solutions.
%First, one must create an arbitrary 1-{}-10 ranking of the importance of any given element in comparison to any other elements of the security design model; where 1 is defined that both elements are equally important and 10 is defined that one element is absolutely more important than the other. These values are then inversed to create a matrix of `relative importances' of the various security model elements with respect to each and every other element in the design. Since the elements of the matrix are based on human judgement there is the possibility that inconsistency may exists. Ferrante et.~al.~ did develop equations to recognize these inconsistencies, but further examination of the process is left to the reader. However, not all aspects of security are going to be quantitative, some will be more qualitative and thus more difficult to deterministically produce values for. A rough method of producing quantitative values from qualitative properties was also proposed by Ferrante et.~al.~; by using the weight developed for a given requirement and multiplying this value by a series of binary representations of whether or not a given feature meets the same requirement that the feature in question is attempting to meet. This is represented by the following equation from Ferrante et.~al.'s work~\cite{Ferrante2013}:
%
%\begin{equation} \label{equ:qualitative}
% L_i = \sum_{j=1}^{R} g_j * v_{ji}, i = 1,2,...,S
%\end{equation}

% XXX what are the L, R, g, and v values?

One must note that there are essentially two values being spoken about in the work by Ferrante et.~al.~; first is the generation of a security metric (named security level) and second generation of a weight metric. The creation of the `security level' metric is a simple mapping of some physical property to a 0.00 -{}- 1.00 scale with 1 being the highest possible security level. Once one has created these weight and security level (SL) metrics, these values can be used to produce security metrics about a given embedded systems security model design.

% Introducing the Security Metric equation
The next consideration is how does one take these produced values and develop a meaningful equation for generating a comparable metric. Following the examination of the work by Ferrante et.~al.~, their definition of `security metric' is as follows:

\begin{multline} \label{equ:securityMetric}
Security Metric (SM) = \\
weight_{elem1} * SL_{elem1}
+ weight_{elem2} * SL_{elem2} \\
+ {...} + weight_{elemN} * SL_{elemN}
\end{multline}

Each `element', in Equation~\ref{equ:securityMetric}, can describe different algorithms, elements, properties, and capabilities of the different components of a system or device.
%It is worth noting that this equation is not necessarily limited to a single use within entire process.
This same style can be used at higher level abstractions of the same design to produce an overall security metric representing a larger system of components. Harking back to our discussion of risk, the following is an example of calculating aggregated security metrics of a system (i.e. network security):

\begin{multline} \label{equ:overallSecMet}
Overall SM = \\
weight_{anti-virus} * SM_{anti-virus}
+ weight_{firewall} * SM_{firewall} \\
+ {...} + weight_{element i} * SM_{element i}
\end{multline}

% Introduction to paper's Security Risk security
This allows for a designer to now create some arbitrary metric to represent whether or not a given design is better or worse at meeting not only the requirements imposed but also in comparison to other available solutions to the same design problem. While this is a step in the right direction, there no units attached to the overall
security metrics produced by the work of Ferrante et.~al. Without a proper unit attached to a generated metric, the entire process remains arbitrary and more difficult to be used in a relevant and meaningful manner. Calling back to the equation proposed in Section~\ref{sec:riskDefinition}, allow us to make use of the same techniques Ferrante et.~al.~developed but apply them in a more meaningful, cost-based manner. In this way it is possible for a `security risk' metric to be generated but also carry a recognizable worth. %instead of just an arbitrary number scheme.
But these values of cost must come from somewhere, and that is the purpose of the impact variable. This is because the impact is a representation of the potential loss caused by an event.

%\begin{multline} \label{equ:securityRisk}
% `Security Risk' = Security Level * direct attacker probability * cost weight \\
% + Security Level * indirect attacker probability * cost weight
Expand Down Expand Up @@ -630,6 +628,48 @@ Sangiovanni-Vincentelli, A.:
Quo Vadis, SLD? Reasoning About the Trends and Challenges of System Level Design,
Proceedings of the IEEE (March 2007)

\bibitem {pal2014will}
Pal, R., Golubchik, L., Psounis, K., and Hui, P.:
Will Cyber-Insurance Improve Network Security? A Market Analysis,
IEEE INFOCOM 2014-IEEE Conference on Computer Communications, Pages 235--243 (2014)

\bibitem {fauntleroy2015cyber}
Odell, L.A., Fauntleroy, J.C., and Wagner, R.R.:
Cyber Insurance - Managing Cyber Risk,
Institute for Defense Analysis (April 2015)

\bibitem {biener2015insurability}
Biener, C., Eling, M., and Wirfs, J.H.:
Insurability of Cyber Risk: An Empirical Analysis,
The Geneva Papers on Risk and Insurance Issues and Practice,
Volume 40 Issue 1 pages 131--158 (January 2015)

\bibitem {armando2004satmc}
Armando, A. and Compagna, L.:
SATMC: A SAT-Based Model Checker for Security Protocols,
Logics in Artificial Intelligence, Volume 3229 pages 730--733 (2004)

\bibitem {brucker2012securebpmn}
Brucker, A.D., Hang, I., L\"{u}ckemeyer, G., and Ruparel, R.:
SecureBPMN: Modeling and Enforcing Access Control Requirements in Business Processes,
Proceedings of the 17th ACM symposium on Access Control Models and Technologies, pages 123-126 (2012)

\bibitem {gonzalez2012quantitative}
Gonzalez, N., Miers, C., Red\'{i}golo, F., Simpl\'{i}cio, M., Carvalho, T., N\"{a}slund, M., Pourzandi, M.:
A quantitative analysis of current security concerns and solutions for cloud computing,
Journal of Cloud Computing: Advances, System and Applications Advances, Systems and Applications (2012)

\bibitem {mukherjee2013attributed}
Mukherjee, D.:
Attributed Metagraph Modelling to Design Business Process Security Management,
Journal: International Letters of Social and Humanistic Sciences,
Issue 06 pages 41--48 (2013)

\bibitem {marotta2015survey}
Marotta, A., Martinelli, S.N., Yautsiukhin, A.:
A Survery on Cyber-Insurance,
Technical Report (November 2015)

%\bibitem {SysML-Sec}
%SysML-Sec,
%\url{http://sysml-sec.telecom-paristech.fr/}
Expand Down

0 comments on commit 23182a6

Please sign in to comment.