From 2a72429fdd6634a39b3db3e88305911a2aaed991 Mon Sep 17 00:00:00 2001 From: Duncan Date: Fri, 1 Jul 2016 21:24:43 -0400 Subject: [PATCH] Small edits: addition of abstract, remove of some writing. --- AADLSecPaper.tex | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index cccae5b..5fcaa89 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -91,7 +91,7 @@ %requirements and verification. This paper examines previous implementations of behavior, requirements, and %security in AADL and then goes to propose a new framework for better integration and description of security %requirements and behavior within the AADL lexicon. -\textbf{Something something abstract} +Embedded systems model generation and verification has become a more complicated as aspects of security need to be included in examinations. The obvious implications of adding security are those of needing to account for impacts of loss (risk) and accounting for the costs of the design. The considerations that are not traditionally examined are those of the adversary and the defender of a given system. Without accounting for the view point of the individuals interacting with any secure embedded system design, on can not verify and select the most advantageous security design. \keywords{security modeling, security framework, secure system design} \end{abstract} @@ -111,7 +111,7 @@ How does one begin to place units on an arbitrary thing like risk? Risk is gene Why should this paper have chosen to examine embedded system security modeling through the AADL language? AADL has a large and active community that works towards development and improvement of new annexes or other extensions to the existing AADL lexicon. In addition to the ease of extensibility, AADL is an easy language to pick up and learn. This paired with the way in which AADL has been intuitively built, allows for ease of extension by other users or even the community at large. This paper makes use of AADL to aid in modeling embedded systems with security properties and constraints that will be used in Section~\ref{sec:simpleExample} for giving a practical example of our proposed adversarial risk-based approach to embedded systems security modeling. -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 catagorizing 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 folowing 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 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. \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}). @@ -135,9 +135,11 @@ supported_operations_mode : type enumeration (ecb, cbc, pcbc, cfb, ofb, ctr); \end{lstlisting} -Current language standards used to describe security concepts, requirements, and constraints has not been developed well enough to be `all-encompassing'. Recent AADL extensions to the security annex describes the security aspect of `trust' as a non-binary value, which this paper sees has not an accurate reflection of security concerns and does not allow for accurate verification and validation of security requirements and behavior. While the concept of `trust' can be influenced by aspects of reliability, the metric used for measuring trust should be binary as one can not say that they trust a component, or system, 80\% of the time; whereas reliability can be easily described as a percentage. +%Current language standards used to describe security concepts, requirements, and constraints has not been developed well enough to be `all-encompassing'. Recent AADL extensions to the security annex describes the security aspect of `trust' as a non-binary value, which this paper sees has not an accurate reflection of security concerns and does not allow for accurate verification and validation of security requirements and behavior. While the concept of `trust' can be influenced by aspects of reliability, the metric used for measuring trust should be binary as one can not say that they trust a component, or system, 80\% of the time; whereas reliability can be easily described as a percentage. -With all the work towards describing and defining security modeling aspects, there is a need to develop a method for calculating `estimation metrics' that can be used to compare and contrast generated solutions. To even begin development of these metrics, one needs to be able to account for a `security metric' that can represent differing solutions, algorithms, methods for tackling security concerns and requirements. This `security metric' value should be `relatively deterministic'. What this paper means it that the values calculated should be deterministic, but that this deterministic nature will originate from a scaling, or ranking, that is `relative' to the capabilities of the security aspect being examined (e.g. ranking encryption techniques~\cite{Ferrante2013}). Further more, these metrics must eventually all have the same basic `unit of measure', thus allowing for a relevant interpretation of developed metrics and calculated values for various security solution implementation designs. The easiest is a monetary amount (USD). Since everything carries some weight of time (development, testing, production, design), then at some point one will need to convert a unit-less metric to a time metric to a monetary metric. To better describe these security models from a financial standpoint, it might be advantageous to have the final estimation metric be represented with a money over time unit of measurement. +With all the work towards describing and defining security modeling aspects, there is a need to develop a method for calculating `estimation metrics' that can be used to compare and contrast generated solutions. To even begin development of these metrics, one needs to be able to account for a `security metric' that can represent differing solutions, algorithms, methods for tackling security concerns and requirements. +%This `security metric' value should be `relatively deterministic'. What this paper means it that the values calculated should be deterministic, but that this deterministic nature will originate from a scaling, or ranking, that is `relative' to the capabilities of the security aspect being examined (e.g. ranking encryption techniques~\cite{Ferrante2013}). Further more, +These metrics must eventually all have the same basic `unit of measure', thus allowing for a relevant interpretation of developed metrics and calculated values for various security solution implementation designs. The easiest is a monetary amount (USD). Since everything carries some weight of time (development, testing, production, design), then at some point one will need to convert a unit-less metric to a time metric to a monetary metric. To better describe these security models from a financial standpoint, it might be advantageous to have the final estimation metric be represented with a money over time unit of measurement. % Add in an image of the drawing from the bulletjournal on the process \begin{figure} @@ -167,7 +169,7 @@ Risk is generally defined as the potential of gaining or losing something of val 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. 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. % Differences can occur when assessing risk depending on the point of view of the individual -Risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact. Complications in Risk Indentification can come from a lack of experience and standards or due to the evolution of a system. The first comes the fact that defining `security risk' is still novel and does not have standardized procedures for dealing within the cyber-modeling domain. The second issue originates from the fact that computer systems evolve quickly over time. The system within an organization can change quickly with new technologies appear very often; changing the landscape of `cyber risks' and other cyber-domain concerns. Risk can be assessed differently based on how it is examined. Depending on where uncertainties originate from, how impacts of actions are measured, and how these variables interact with each other, different variations of risk equations can be developed. To further complicate possible risk calculations, the equation for interpreting risk can differ based on the role of the individual measuring said risk. What may be a calculated risk to a defender, could prove to be advantageous to an attacker by causing less risk of being observed or even allow for less risky attacks to be performed against a system. An other example would be heavy security implementation may cause a larger risk value for an attacker, but would produce a minimal risk value for the defender of the same system. Further examination of attack and defense considerations will be continued in Section~\ref{sec:attackDefense}. +Risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact. Complications in risk identification can come from a lack of experience and standards or due to the evolution of a system. The first comes the fact that defining `security risk' is still novel and does not have standardized procedures for dealing within the cyber-modeling domain. The second issue originates from the fact that computer systems evolve quickly over time. The system within an organization can change quickly with new technologies appear very often; changing the landscape of `cyber risks' and other cyber-domain concerns. Risk can be assessed differently based on how it is examined. Depending on where uncertainties originate from, how impacts of actions are measured, and how these variables interact with each other, different variations of risk equations can be developed. To further complicate possible risk calculations, the equation for interpreting risk can differ based on the role of the individual measuring said risk. What may be a calculated risk to a defender, could prove to be advantageous to an attacker by causing less risk of being observed or even allow for less risky attacks to be performed against a system. An other example would be heavy security implementation may cause a larger risk value for an attacker, but would produce a minimal risk value for the defender of the same system. Further examination of attack and defense considerations will be continued in Section~\ref{sec:attackDefense}. \begin{equation} \cite{Mukhopadhyay2013} \label{equ:expectedLoss} Expected Loss = Risk Frequency * Risk Amount @@ -198,8 +200,10 @@ Now that this paper has presented a meaningful manner of representing security r \end{enumerate} One complication of this technique is the requirement to create `libraries' for certain aspects of the security modeling framework; for example, the various solution implementations for `keeping data secure'. More will be touched upon this subject in Section~\ref{sec:additionalConcerns}. Another concern is how one ranks all the various security solutions, algorithms, and methodologies in such a manner that the capabilities of the architectural components play a part in determining the best solution models that can be generated from a given set of constraints. +% 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}, with respect to the aforementioned `relative importance' matrix, 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. @@ -211,6 +215,7 @@ Borrowing from the work of Ferrante et.~al.~ using the Analytical Hierarchy Proc 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 `relativity matrix' and `security level' 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 level' is as follows: \begin{multline} \label{equ:securityMetric} @@ -228,6 +233,7 @@ Each `element', in Equation~\ref{equ:securityMetric}, can describe different alg + weight_{element i} * Security Metric_{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 `cost weight' variable. This is because the `cost weight' is a representation of the potential loss caused by an event and the hours required to `repair' the problem. This causes the unit of our security risk metric to become cost over time. %\begin{multline} \label{equ:securityRisk} @@ -235,6 +241,7 @@ This allows for a designer to now create some arbitrary metric to represent whet % + Security Level * indirect attacker probability * cost weight %\end{multline} +% Introduce paper's Estimation Metric equation While having an equation for security risk is great, this does not allow for a representation of a system as a whole. Additional aspects that must be taken into account include costs of implementing a given solution, the cost of maintaining a given solution, how a generated solution's ranking will change based on the user type interacting with the system, a metric given to the solution as a whole, 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 `estimation metric' for any produced embedded system security modeling design. \begin{multline} \label{equ:estimationMetric} @@ -254,7 +261,7 @@ Now that aspects of this framework's verification and selection process have bee \section{Exploring a Simple Implementation} \label{sec:simpleExample} -This paper now moves to showing a simple implementation of the security framework's mapping process to produce a meaningful `estimation metric' that can be used to compare design decisions. The purpose of this examination is to give a concrete example of the verification equations being used to rank a set of produced solutions to a chosen design problem, as well as illustrate how one may go about developing some of the required rankings. When initially designing a system, there are a large number of considerations that must be taken into account. From power consumption requirements, architectural needs, spacing of parts, and weight of the developed device. When incorporating security elements, the problem becomes larger. For example, allow this paper to assume that the elements in Table~\ref{elementTypes} have numerous variations that can be simplified into a few types. +This paper now moves to showing a simple implementation of the security framework's verification and selection process to produce a meaningful `estimation metric' that can be used to compare design decisions. The purpose of this examination is to give a concrete example of the verification equations being used to rank a set of produced solutions to a chosen design problem, as well as illustrate how one may go about developing some of the required rankings. When initially designing a system, there are a large number of considerations that must be taken into account. From power consumption requirements, architectural needs, spacing of parts, and weight of the developed device. When incorporating security elements, the problem becomes larger. For example, allow this paper to assume that the elements in Table~\ref{elementTypes} have numerous variations that can be simplified into a few types. % Add in the table of elements and variations \begin{table*}[] @@ -346,7 +353,7 @@ No Encryption & 16.94 & 17.50 & 19.38 & \\ \hline 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. \subsection{Expanding Considerations} -Despite the efforts to simplify the embedded system security modeling problem, there are a plethora of additional variables that can be taken into consideration depending on the environment and user, or company, at risk. When calculating the estimated cost metrics used for making larger system design decisions, one ideally accounts for as many aspects of the system as possible. When dealing with the constrained domain of embedded systems, this is doubly so. Physical costs of the system carry a heavy weight when making choices about design implementations. Power costs, heat generated, run time, area requirement, etc. are all aspects that must be considered. When incorporating software, the assumption of this paper is that software has been designed correctly with no error or malicious behavior embedded within. To that case, this means that when comparing software implementations, the main considerations of the developer are run time, bits used (in the case of encryption and authentication), and power consumed (with respect to total battery life; total system run time on a single charge). To further add the weight of additional design considerations to our proposed mapping process, one can account for any additional features as a result of design decisions. This would mean that the inverted requirements weight would need to be further tailored to account for additional features that a design receives due to the decisions made by a development team. In this manner a design team can further tweak the generation of certain design solutions based on the requirements met and additional features produced as result. +Despite the efforts to simplify the embedded system security modeling problem, there are a plethora of additional variables that can be taken into consideration depending on the environment and user, or company, at risk. When calculating the estimated cost metrics used for making larger system design decisions, one ideally accounts for as many aspects of the system as possible. When dealing with the constrained domain of embedded systems, this is doubly so. Physical costs of the system carry a heavy weight when making choices about design implementations. Power costs, heat generated, run time, area requirement, etc. are all aspects that must be considered. When incorporating software, the assumption of this paper is that software has been designed correctly with no error or malicious behavior embedded within. To that case, this means that when comparing software implementations, the main considerations of the developer are run time, bits used (in the case of encryption and authentication), and power consumed (with respect to total battery life; total system run time on a single charge). To further add the weight of additional design considerations to our proposed verification and selection process, one can account for any additional features as a result of design decisions. This would mean that the inverted requirements weight would need to be further tailored to account for additional features that a design receives due to the decisions made by a development team. In this manner a design team can further tweak the generation of certain design solutions based on the requirements met and additional features produced as result. There can also be additional considerations that come about due to how probabilities, risk, and weights are chosen to be interpreted. Should an individual choose to incorporate features such as exposure or concentrate on sensitivity and security level of individual data, then one could attempt to produce a `probability rating' that represents these concerns, as shown in Equation~\ref{equ:probRating}.