Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
some more final edits
  • Loading branch information
@joc02012
joc02012 committed Jul 21, 2016
1 parent 822a9e0 commit 870b35c
Showing 1 changed file with 9 additions and 9 deletions.
18 changes: 9 additions & 9 deletions SecurityRiskPaper.tex
View file
Expand Up @@ -123,7 +123,7 @@ In order to use a design process such as this, we need to be able to have metric
How does one begin to place metrics on an arbitrary measure like security risk? Risk is generally treated as a probability that an event will occur. To understand risk from an embedded systems security modeling standpoint, one must first determine how to define risk in a meaningful manner, and how to then apply this metric to the situation that involved said `security risk' (more on this topic will be explored in Section~\ref{sec:riskDefinition}). Quantitative aspects of security will be relatively simple to incorporate with risk calculations. How does one define qualitative aspects of security? One method that can be used to assign a quantitative value to a qualitative property is to use a relative ranking system to scale all available How does one begin to place metrics on an arbitrary measure like security risk? Risk is generally treated as a probability that an event will occur. To understand risk from an embedded systems security modeling standpoint, one must first determine how to define risk in a meaningful manner, and how to then apply this metric to the situation that involved said `security risk' (more on this topic will be explored in Section~\ref{sec:riskDefinition}). Quantitative aspects of security will be relatively simple to incorporate with risk calculations. How does one define qualitative aspects of security? One method that can be used to assign a quantitative value to a qualitative property is to use a relative ranking system to scale all available
solutions from a 0.00 -{}- 1.00 scale as explored by Ferrante et.~al.~\cite{Ferrante2013}. solutions from a 0.00 -{}- 1.00 scale as explored by Ferrante et.~al.~\cite{Ferrante2013}.


First, this paper will need to develop a verification and selection process for taking all of the cataloged information and possible solutions \& compare and contrast solutions that meet user-defined security requirements while categorizing solutions that are maintaining within external constraints and the capabilities of the architectural components being used to produce a best fit; measured by this paper's verification and selection process (Section~\ref{sec:riskDefinition}). To begin this approach, one will first need to define the constraints of the system, describe the considerations that must be taken into account, and standardize a method by which an individual can produce a comparable metric for generated embedded system security model designs (Seciton~\ref{sec:framework}). In the following Sections, this paper will produce examples of the verification and selection process (Seciton~\ref{sec:simpleExample}), then expand the discussion to include additional considerations (e.g. physical, adversarial). Lastly the paper will speak to some last, larger, considerations followed by the conclusions and future work towards producing an adversarial risk-based approach to embedded systems security modeling. First, one needs to develop a verification and selection process for taking all of the cataloged information and possible solutions \& compare and contrast solutions that meet user-defined security requirements while categorizing solutions that are maintaining within external constraints and the capabilities of the architectural components being used to produce a best fit; measured by this paper's verification and selection process (Section~\ref{sec:riskDefinition}). To begin this approach, one will first need to define the constraints of the system, describe the considerations that must be taken into account, and standardize a method by which an individual can produce a comparable metric for generated embedded system security model designs (Seciton~\ref{sec:framework}). In the following Sections, we will produce examples of the verification and selection process (Seciton~\ref{sec:simpleExample}), then expand the discussion to include additional considerations (e.g. physical, adversarial). Lastly, we will speak to some last, larger, considerations followed by the conclusions and future work towards producing an adversarial risk-based approach to embedded systems security modeling.


%\section{Motivation and Related Work} %\section{Motivation and Related Work}
%Work has been made to describe behavior, errors, some security properties in terms of verification and validation within the AADL language. These developments have occurred in a variety of annexes, most recently the security annex extensions and alterations that have been occurring throughout the summer of 2016~\cite{AADLSecAnnex,AADLSecAnalysis}. Attempts are always being made to improve AADL and incorporate more in the description and detail of the language. Recent work includes the definition of specific security-based properties, ranging from `AccessProteciton' to security level definitions to even such extensive work as defining all the different aspects of encryption (shown in Listing~\ref{lst:AADLSecEncryption}). %Work has been made to describe behavior, errors, some security properties in terms of verification and validation within the AADL language. These developments have occurred in a variety of annexes, most recently the security annex extensions and alterations that have been occurring throughout the summer of 2016~\cite{AADLSecAnnex,AADLSecAnalysis}. Attempts are always being made to improve AADL and incorporate more in the description and detail of the language. Recent work includes the definition of specific security-based properties, ranging from `AccessProteciton' to security level definitions to even such extensive work as defining all the different aspects of encryption (shown in Listing~\ref{lst:AADLSecEncryption}).
Expand Down Expand Up @@ -177,7 +177,7 @@ require the following steps to take place:
\end{enumerate} \end{enumerate}
Other additional aspects of this framework, that could come from the existing tools, extensions, and annexes would include code generated using the secure models. Other additional aspects of this framework, that could come from the existing tools, extensions, and annexes would include code generated using the secure models.
%Work towards developing these sorts of tools for secure architectures (e.g. seL4) is already one of the focuses of current AADL security annex work~\cite{AADLSecAnalysis}. %Work towards developing these sorts of tools for secure architectures (e.g. seL4) is already one of the focuses of current AADL security annex work~\cite{AADLSecAnalysis}.
While this framework is a vision of overall design process, in this paper, we focus on just the requirements While this framework is a vision of the overall design process, in this paper, we focus on just the requirements
modeling and the verification process. Specifically, we focus on how to model security goals and requirements modeling and the verification process. Specifically, we focus on how to model security goals and requirements
in such a way that they can be measured and validated. Ideally one desires a metric that incorporates not only in such a way that they can be measured and validated. Ideally one desires a metric that incorporates not only
the impact of design decisions on a system and the cost of producing a design, but also account for the the impact of design decisions on a system and the cost of producing a design, but also account for the
Expand All @@ -203,7 +203,7 @@ But to develop an equation for risk one must first define the potential of event
% Define Risk for this paper % Define Risk for this paper
For the purpose of this paper, risk will be represented as a combination of probability and impact (as shown in Equation~\ref{equ:riskDefinition}). For the purpose of this paper, risk will be represented as a combination of probability and impact (as shown in Equation~\ref{equ:riskDefinition}).
%The reason for this interpretation is that from a security lens, it is much easier to quantify probability and impact. %The reason for this interpretation is that from a security lens, it is much easier to quantify probability and impact.
In addition to these, this paper develops a methodology for evaluating design choices based on impact (risk), cost of the design, and also incorporating the attacker's side of examining any given embedded system. Without a proper method for defining risk and cost models, one can not verify, evaluate, compare, and contrast designs in a relevant and worthwhile manner. In addition to these, we have developed a methodology for evaluating design choices based on impact (risk), cost of the design, and also incorporating the attacker's side of examining any given embedded system. Without a proper method for defining risk and cost models, one can not verify, evaluate, compare, and contrast designs in a relevant and worthwhile manner.


% Differences can occur when assessing risk depending on the point of view of the individual % Differences can occur when assessing risk depending on the point of view of the individual
%Summarizing, risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact. %Summarizing, risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact.
Expand All @@ -229,7 +229,7 @@ Section~\ref{sec:attackDefense}.
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 another 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. 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. 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 another 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. 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. % 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. Borrowing from the work of Ferrante et.~al.~using the Analytical Hierarchy Process (AHP), we 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}: %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} %\begin{equation} \label{equ:qualitative}
Expand Down Expand Up @@ -376,7 +376,7 @@ the likelihood of an attack will also increase. It is also worth noting that $p
attack ($c_a$) a given system, in such a manner that if $p_s*A < c_a$ then $p_a$ = 0\%; otherwise if $p_s*A \geq attack ($c_a$) a given system, in such a manner that if $p_s*A < c_a$ then $p_a$ = 0\%; otherwise if $p_s*A \geq
c_a$ then $p_a$ should grow from 0\% to eventually 100\%. This is because $p_a$ should be zero until such a c_a$ then $p_a$ should grow from 0\% to eventually 100\%. This is because $p_a$ should be zero until such a
time that the $p_s*A$ aspect become meaningful. The relationship between the expected attack time that the $p_s*A$ aspect become meaningful. The relationship between the expected attack
value and $p_a$ is not well defined and further study is needed to determine an accurate model. For the purposes of this paper, we suggest an exponential relationship as shown in Figure~\ref{fig:attackRisk} and the following equation: value and $p_a$ is not well defined and further study is needed to determine an accurate model. As a simple model, we suggest an exponential relationship as shown in Figure~\ref{fig:attackRisk} and the following equation:
%Harking back to Figure~\ref{fig:attackRisk}, we arrive at the equation for the probability of attack becomes: %Harking back to Figure~\ref{fig:attackRisk}, we arrive at the equation for the probability of attack becomes:
\begin{equation} \begin{equation}
p_a = p_a =
Expand Down Expand Up @@ -434,7 +434,7 @@ Additional aspects that must be taken into account include costs of implementing
%how a generated solution's ranking will change based on the user type interacting with the system, %how a generated solution's ranking will change based on the user type interacting with the system,
operational costs of a given solution. operational costs of a given solution.
%, as well as determination of the number of requirements met, or not met, by any chosen design solution. %, as well as determination of the number of requirements met, or not met, by any chosen design solution.
Taking these aspects into account, this paper proposes the following equation to calculate an overall cost Taking these aspects into account, we propose the following equation to calculate an overall cost
% and `estimation metric' % and `estimation metric'
for any produced embedded system security modeling design. for any produced embedded system security modeling design.


Expand Down Expand Up @@ -554,7 +554,7 @@ These different aspects can be compared by assigning weights for allowing relati
%Other areas originate from the development of URT and $c_o$, where there are some arbitary decisions made on ranking of users or generated solutions. %Other areas originate from the development of URT and $c_o$, where there are some arbitary decisions made on ranking of users or generated solutions.


Before being able to calculate out the estimation matrix for our wireless transmitter example, we make some Before being able to calculate out the estimation matrix for our wireless transmitter example, we make some
simplifications and assumptions to smooth the process. First we will take the assumption that there will be five separate implementations of encryption for the wireless transmitter: hardware AES256 (MIPS), hardware AES128 (MIPS), software AES256, software AES128, and no encryption. Drawing from the work by Ferrante et.~al.~, the corresponding security level (SL) values are {1.00, 0.60, 0.10} for {AES256, AES128, and no encryption}, respectively. It is worth noting that while in theory having no encryption should mean the lowest values possible (0.00) but in order to show the effect of these elements this paper assumes the lowest value obtainable is 0.10. Similarly, we assume the SL values for the different implementations are {1.00, 0.40, 0.10} for {hardware encryption, software encryption, and no encryption}, respectively. simplifications and assumptions to smooth the process. First we will take the assumption that there will be five separate implementations of encryption for the wireless transmitter: hardware AES256 (MIPS), hardware AES128 (MIPS), software AES256, software AES128, and no encryption. Drawing from the work by Ferrante et.~al.~, the corresponding security level (SL) values are {1.00, 0.60, 0.10} for {AES256, AES128, and no encryption}, respectively. It is worth noting that while in theory having no encryption should mean the lowest values possible (0.00) but in order to show the effect of these elements, we assume the lowest value obtainable is 0.10. Similarly, we assume the SL values for the different implementations are {1.00, 0.40, 0.10} for {hardware encryption, software encryption, and no encryption}, respectively.
%Since we have simplified the example to having a single requirement (i.e. encryption of data), then the weight value used for calculating the Security Metric (SM) is 1.00. %Since we have simplified the example to having a single requirement (i.e. encryption of data), then the weight value used for calculating the Security Metric (SM) is 1.00.
Now that we have SL values for the encryption algorithm and the implementation approach, we can determine an overall SL value by multiplying the two SL values because of their serial dependence. In order to arrive at an overall risk metric (SR), we must first make some assumptions about the impact ($I$), attack cost ($c_a$), and the value to an attacker ($A$). For the $I$ value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name? Now that we have SL values for the encryption algorithm and the implementation approach, we can determine an overall SL value by multiplying the two SL values because of their serial dependence. In order to arrive at an overall risk metric (SR), we must first make some assumptions about the impact ($I$), attack cost ($c_a$), and the value to an attacker ($A$). For the $I$ value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name?
The $A$ value is assumed to be \$30 per `unit' of stolen data and the $c_a$ is assumed to be \$10 per attack attempt. Using Equation~\ref{equ:expandedRisk}, one finds that the SR values The $A$ value is assumed to be \$30 per `unit' of stolen data and the $c_a$ is assumed to be \$10 per attack attempt. Using Equation~\ref{equ:expandedRisk}, one finds that the SR values
Expand Down Expand Up @@ -671,7 +671,7 @@ From these produced numbers, a developer can apply further constraints to the de
\label{fig:SRvI} \label{fig:SRvI}
\end{figure} \end{figure}


While both the values of the costs and security risk equations produce a dollar-unit metric, they are not immediately combinable as some costs are representative of life-time costs while others incorporate more immediate costs of a design. For this reason, a pairing of security risk and cost are used to determine the favorability of a given design in comparison of other design choices. It is worth noting that in the previous example, there was an assumption that the $c_a$ would be uniform no matter the system being attacked. To further add to the potential complexity of these calculations, one could take into account that there should be different values of $c_a$ depending on the type of security measures implemented into a given design; influencing the probability of an attack occuring (i.e. $p_a$). Now that a simple example has been shown, allow this paper to now expand the considerations that are made for this simplistic example. The following section will examine further expansion of `estimation metric' considerations, showing how the calculation of comparable metrics can become more involved and complicated. While both the values of the costs and security risk equations produce a dollar-unit metric, they are not immediately combinable as some costs are representative of life-time costs while others incorporate more immediate costs of a design. For this reason, a pairing of security risk and cost are used to determine the favorability of a given design in comparison of other design choices. It is worth noting that in the previous example, there was an assumption that the $c_a$ would be uniform no matter the system being attacked. To further add to the potential complexity of these calculations, one could take into account that there should be different values of $c_a$ depending on the type of security measures implemented into a given design; influencing the probability of an attack occuring (i.e. $p_a$). In other words, more complex security features may require much more costs to defeat those features. Now that a simple example has been shown, we now expand the considerations that are made for this simplistic example. The following section will examine further expansion of `estimation metric' considerations, showing how the calculation of comparable metrics can become more involved and complicated.


\section{Examining Attack and Defense with Detail} \section{Examining Attack and Defense with Detail}
\label{sec:attackDefense} \label{sec:attackDefense}
Expand Down Expand Up @@ -753,7 +753,7 @@ One of the largest problems facing security verification and validation techniqu
The last, and perhaps largest concern, is that there are still aspects of the proposed process that are arbitrarily decided upon. This is an extremely difficult element to remove from the current examination of security framework verification and selection using an adversarial risk-based approach to embedded systems security modeling due to the need for qualitative input to a system that has yet to have standard quantitative input. While this work will continue to attempt to minimize the use of arbitrary values and rankings, it will take the effort of the entire security community to help move security measurements from a qualitative scale for a more quantitative one. The last, and perhaps largest concern, is that there are still aspects of the proposed process that are arbitrarily decided upon. This is an extremely difficult element to remove from the current examination of security framework verification and selection using an adversarial risk-based approach to embedded systems security modeling due to the need for qualitative input to a system that has yet to have standard quantitative input. While this work will continue to attempt to minimize the use of arbitrary values and rankings, it will take the effort of the entire security community to help move security measurements from a qualitative scale for a more quantitative one.


\section{Conclusion} \section{Conclusion}
Having examined a new security modeling framework, coupled with the examination of its verification and selection process, it is the hope of the paper that the reader has begun to see not only how to produce meaningful security and risk-based metrics, but also see how additional consideration of worth to attacking and defending parties can complicate calculations due to a lack of knowledge and experience of how to measure and relate them. As the security community continues to develop and grow new techniques and methodologies, they must also rigorously standardize their method of examination to allow for better, more effective verification and selection of `best fit' embedded system security modeling solutions. Having examined a new security modeling framework, coupled with the examination of its verification and selection process, we have introduced new meaningful security and risk-based metrics that take into consideration of worth to attacking and defending parties can complicate calculations due to a lack of knowledge and experience of how to measure and relate them. As the security community continues to develop and grow new techniques and methodologies, they must also rigorously standardize their method of examination to allow for better, more effective verification and selection of `best fit' embedded system security modeling solutions.


Future work include further development of the mapping process using a risk-based methodology, continue creating more deterministic means for describing security requirements and architectural component capabilities in a meaningful and comparable manner, and development towards an automated method for comparing generated solutions within a constrained and directed manner to arrive at best solutions for generated embedded systems security models. Future work include further development of the mapping process using a risk-based methodology, continue creating more deterministic means for describing security requirements and architectural component capabilities in a meaningful and comparable manner, and development towards an automated method for comparing generated solutions within a constrained and directed manner to arrive at best solutions for generated embedded systems security models.


Expand Down

0 comments on commit 870b35c

Please sign in to comment.