From 8d872aacfe3febc2f75415829c08ec305ab02c67 Mon Sep 17 00:00:00 2001 From: "John A. Chandy" Date: Tue, 5 Jul 2016 07:59:45 -0400 Subject: [PATCH] various edits --- AADLSecPaper.tex | 167 +++++++++++++++++++++++++++++------------------ 1 file changed, 103 insertions(+), 64 deletions(-) diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index 5fcaa89..c18f066 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -61,9 +61,9 @@ \begin{document} -\title{An adversarial risk-based approach to embedded systems security modeling} +\title{An Adversarial Risk-based Approach to Embedded Systems Security Modeling and Design} % -\titlerunning{AADL Security} % abbreviated title (for running head) +\titlerunning{Adversarial Risk-based Security Modeling} % abbreviated title (for running head) % also used for the TOC unless % \toctitle is used % @@ -91,14 +91,21 @@ %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. -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. +Embedded systems design and verification has become more complicated as aspects of security need to be included +in examinations. The obvious implications of adding security are the need to account for impacts of +loss (risk) and accounting for the ensuing increased design costs. 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} \section{Introduction} %AADL, like most modeling languages, must be able to describe not only the requirements of a system, but also the constraints, capabilities, and costs of various implementations and methods for the purpose of modeling a gamut of different designs. Coupling this already large space with security causes the considerations and influences on the problem to grow considerably. This paper will choose to examine the field of modeling embedded system security through the lens of the Architecture Analysis \& Design Language (AADL). -Modeling security is a difficult problem that has not been thoroughly explored. To properly model security one has to account not only for the security requirements being imposed by a user, or organization, but also must account for the architectural components and their capabilities when designing a best-fit solution to a given security concern. The security requirements can range from such vague concepts as ``my data must remain secure'' to more concrete requirements of ``this specific communication standard must be used''. Each requirement capable of being implemented in a variety of manners and methods. These differences are further defined by the architectural components and their capabilities. Elements ranging from time spent to complete a given task, power consumption rate, heat radiated over time, and size, or area, that a given component will require on a printed circuit board (PCB). To further complicate matters, one must take these opposing aspects of the system design process, represent them using meaningful metrics that can be calculated from some deterministic information, and then compare and contrast generated solutions for implementing the most favorable variation of produced embedded systems security model. Fortunately there are methodologies and techniques (e.g. Platform Based Design~\cite{Vincentelli2007}) that aid in the development and improvement of security modeling approaches. For example, Platform-based design is a prime example of how one can take the functional space (security requirements) and the architectural space (components and capabilities) and develop a mapping function that can produce solutions to a given design problem. As shown in Figure~\ref{fig:recursivePBD}, one can then take the mapped solution and use this as the new functional (or architectural) space for the next iteration of solution mapping. +Modeling security risk for use in systems design is a difficult problem that has not been thoroughly explored. To properly model security one has to account not only for the security requirements being imposed by a user, or organization, but also must account for the architectural components and their capabilities when designing a best-fit solution to a given security concern. The security requirements can range from such vague concepts as ``my data must remain secure'' to more concrete requirements of ``this specific communication standard must be used''. Each requirement is capable of being implemented in a variety of manners and methods. These differences are further defined by the architectural components and their capabilities. Elements ranging from time spent to complete a given task, power consumption rate, heat radiated over time, and size, or area, that a given component will require on a printed circuit board (PCB). To further complicate matters, one must take these opposing aspects of the system design process, represent them using meaningful metrics that can be calculated from some deterministic information, and then compare and contrast generated solutions for implementing the most favorable variation of produced embedded systems security model. Fortunately there are +methodologies and techniques %(e.g. Platform Based Design) +that aid in the development and improvement of security modeling approaches. For example, Platform-based design~\cite{Vincentelli2007} is a prime example of how one can take the functional space (including security requirements) and the architectural space (components and capabilities) and develop a mapping function that can produce solutions to a given design problem. As shown in Figure~\ref{fig:recursivePBD}, one can then take the mapped solution and use this as the new functional (or architectural) space for the next iteration of solution mapping. \begin{figure} \includegraphics[width=\textwidth]{./images/recursivePBD.png} @@ -106,34 +113,33 @@ Modeling security is a difficult problem that has not been thoroughly explored. \label{fig:recursivePBD} \end{figure} - -How does one begin to place units on an arbitrary thing like risk? Risk is generally treated as a probability that an event will occur. To define 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. Work on implementing this can be seen in a paper by Ferrante et.~al.~\cite{Ferrante2013}. - -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. +In order to use a design process such as this, we need to be able to have metrics that are able to evaluate the quality of a design solution in relation to the quality of other possible design solutions. +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 define 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}. 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}). - -\begin{lstlisting}[caption={AADL Security Annex Definitions of Encryption~\cite{AADLSecAnnex}},label={lst:AADLSecEncryption}] -encryption : security_properties::encryption_type applies to - {port, virtual bus, bus, memory, access}; -encryption_type : type record ( - method : security_properties::supported_encryption_method; - algorithm : security properties::supported_encryption_algorithm; - public_key : aadlstring; - private_key : aadlstring; - key : aadlstring; - operation_mode : security_properties::supported_operation_mode; -}; -supported_encryption_method : - type enumeration (symmetric, asymmetric, clear); -supported_encryption)algorithm : - type enumeration (tripledes, des, rsa, blowfish, aes, clear); -supported_operations_mode : - type enumeration (ecb, cbc, pcbc, cfb, ofb, ctr); -\end{lstlisting} +%\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}). +% +%\begin{lstlisting}[caption={AADL Security Annex Definitions of Encryption~\cite{AADLSecAnnex}},label={lst:AADLSecEncryption}] +%encryption : security_properties::encryption_type applies to +% {port, virtual bus, bus, memory, access}; +%encryption_type : type record ( +% method : security_properties::supported_encryption_method; +% algorithm : security properties::supported_encryption_algorithm; +% public_key : aadlstring; +% private_key : aadlstring; +% key : aadlstring; +% operation_mode : security_properties::supported_operation_mode; +%}; +%supported_encryption_method : +% type enumeration (symmetric, asymmetric, clear); +%supported_encryption)algorithm : +% type enumeration (tripledes, des, rsa, blowfish, aes, clear); +%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. @@ -144,23 +150,36 @@ These metrics must eventually all have the same basic `unit of measure', thus al % Add in an image of the drawing from the bulletjournal on the process \begin{figure} \centering\includegraphics[height=6cm]{./images/aadl_security_framework.png} - \caption{Visualization of Security Framework} + \caption{Visualization of Security Design Framework} \label{fig:AADLSecFrame} \end{figure} -Section~\ref{sec:framework} will propose a security framework that can be used for applying a verification and selection process by which a set of risk-based equations can be used to assign metrics to developed embedded system security models. The new security framework in Figure~\ref{fig:AADLSecFrame} would require the following steps to take place: +Section~\ref{sec:framework} will propose a security design framework that can be used for applying a +verification and selection process by which a set of risk-based equations can be used to assign metrics to +developed embedded system security models. The proposed design framework in Figure~\ref{fig:AADLSecFrame} would +require the following steps to take place: \begin{enumerate} \item Creation of a low-level component library that would contain normal and secure version implementations of each base component within the architectural space used for model generation. \item Formalized description and definition of higher level security requirements that may come from user-defined needs or from the experience of knowledge of security experts. \item Creation of a mapping process by which security requirements and secure component specifications can be uniformly verified and selected to allow for the generation of potential secure architectural system model solutions to the given inputs. \item Verification tools to validate mapping implementation solutions. \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. 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}. 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 examination and evaluation an attacker may make of a system. But before one can even begin to apply a framework to this verification and selection process, one needs to first be able to define `Security Risk' so that a relatively deterministic formula can be used to obtain a meaningful metric. +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}. +While this framework is a vision of 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 +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 +examination and evaluation an attacker may make of a system. However, before one can even begin to apply a +framework to this verification and selection process, one needs to first be able to define `Security Risk' so +that a relatively deterministic formula can be used to obtain a meaningful metric. \section{Defining Risk} \label{sec:riskDefinition} % Risk traditionally defined -Risk is generally defined as the potential of gaining or losing something of value. Value can be seen as physical health, emotional well-being, financial wealth, etc. Another definition of risk involves viewing risk as an intentional interaction made with some uncertainty. In this scenario uncertainty is defined as a potential, unpredictable, and uncontrollable outcome; risk is seen as a consequence of action taken in spite of some given uncertainty. Depending on the point-of-view of the individual measuring risk, its definition and application can vary a significant amount. For example, risk can be the analysis of expected loss (as shown in Equation~\ref{equ:expectedLoss}). Risk is not a certainy of an event occurring, but a proability that it will happen. But to develop an equation for risk one must first define the potential of events and the losses that could be incurred. Possibility, in risk, depends on two aspects: (1) threat and (2) vulnerability ~\cite{Ferrante2013}. Threat is defined as thecause of risk (e.g. fire, kidnapping, leakage of sensitive information, etc.). Vulnerability is defined as the exiting flaw or weakness which can be exploited and result in an accident. The concept of risk states that risk may result in losses for an agent, user, company, etc. Losses occur because of the consequences of an accident (defined as Impact). Depending on the impacted assest `Impact' may be defined as a tangible (e.g. loss of revenue or financial penalties) or as intangible (e.g. loss of productivity or loss of reputation)~\cite{Mukhopadhyay2013}. An `asset' can be defined as anything valuable to a user or organization or company. An asset can be (1) a physical object, (2) secrete information, (3) business goal, etc. As mentioned earlier, risk requires an element of probability, meaning that the probability value acts as a 0.00 -{}- 1.00 scale weight. Risk is generally represented as follows: +Risk is generally defined as the potential of gaining or losing something of value. Value can be seen as physical health, emotional well-being, financial wealth, etc. Another definition of risk involves viewing risk +as an intentional interaction made with some uncertainty. In this scenario, uncertainty is defined as a potential, unpredictable, and uncontrollable outcome; risk is seen as a consequence of action taken in spite of some given uncertainty. Depending on the point-of-view of the individual measuring risk, its definition and application can vary a significant amount. For example, risk can be the analysis of expected loss %(as shown in Equation~\ref{equ:expectedLoss}). +Risk is not a certainty of an event occurring, but a probability that it will happen. But to develop an equation for risk one must first define the potential of events and the losses that could be incurred. Possibility, in risk, depends on two aspects: (1) threat and (2) vulnerability ~\cite{Ferrante2013}. Threat is defined as the cause of risk (e.g. fire, kidnapping, leakage of sensitive information, etc.). Vulnerability is defined as the exiting flaw or weakness which can be exploited and result in an accident. The concept of risk states that risk may result in losses for an agent, user, company, etc. Losses occur because of the consequences of an accident (defined as Impact). Depending on the impacted asset, `Impact' may be defined as a tangible (e.g. loss of revenue or financial penalties) or as intangible (e.g. loss of productivity or loss of reputation)~\cite{Mukhopadhyay2013}. An `asset' can be defined as anything valuable to a user or organization or company. An asset can be (1) a physical object, (2) secrete information, (3) business goal, etc. As mentioned earlier, risk requires an element of probability, meaning that the probability value acts as a 0.00 -{}- 1.00 scale weight. Putting everything together, risk is generally represented as follows: \begin{equation} \label{equ:riskDefinition} Risk = Probability * Impact \end{equation} @@ -169,25 +188,39 @@ 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 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} +Summarizing, risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact. Complications in +security 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. Another example would be that 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 \end{equation} One can measure risk from the probability of a failure of a given component (e.g. firewall, anti-virus, both), the loss amount for each component failure (e.g. firewall, anti-virus, both, none), and the expected loss (average loss)~\cite{Mukhopadhyay2013}. In this manner an individual can measure risk for a larger, interconnected system, but as the scope of the risk examination changes, so does do the methods by which risk is measured. % Incorporating security into risk calculations -Different methods by which security can be incorporated into risk management include: as a weight representing implementation of security solutions, as a probability that a security concern is met or attacked, the possibility of a security failure, etc. Given all these variations how can one define security in a meaningful and relatively deterministic manner? The first part that needs to be tackled is why is `relatively' good enough for this security metric? The reason that a degree of `relativity' is required for developing a security metric, is that security changes and evolves over time, meaning that the algorithms and methodologies will transform and improve over time. This change means that the measurement for security must remain important relative to the existing security solution space. The reason that this value can not be fully deterministic is that security is constantly progressing and improving, meaning that any deterministic nature in the calculation of a security metric must also account for this change over time. Ideally embedded system security modeling should have more deterministic interpretation of generated security solutions, but at the current point this is not realistically achievable. Security levels can also be interdependent depending on implementation and scenario/situation. +Different methods by which security can be incorporated into risk management include: as a weight representing implementation of security solutions, as a probability that a security concern is met or attacked, the +possibility of a security failure, etc. Given all these variations, how can one define security in a meaningful and relatively deterministic manner? The first part that needs to be tackled is why is `relatively' good enough for this security metric? The reason that a degree of `relativity' is required for developing a security metric, is that security changes and evolves over time, meaning that the algorithms and methodologies will transform and improve over time. This change means that the measurement for security must remain important relative to the existing security solution space. The reason that this value can not be fully deterministic is that security is constantly progressing and improving, meaning that any deterministic nature in the calculation of a security metric must also account for this change over time. Ideally embedded system security modeling should have more deterministic interpretation of generated security solutions, but at the current point this is not realistically achievable. Security levels can also be interdependent depending on implementation and scenario/situation. The purpose of this paper is to propose a method for combining security and risk in a measurable and meaningful manner. Taking the already defined risk equation (i.e. Equation~\ref{equ:riskDefinition}), we move to add in the existence of a `security metric' and `cost weight' to the probability that either a direct or an indirect attack occurs to a given system. -\begin{multline} \label{equ:securityRisk} - `Security Risk' = \frac{direct attack probability * `cost' weight}{`Security Metric'}\\ - + \frac{indirect attack probability * `cost' weight}{`Security Metic'} -\end{multline} +\begin{equation} \label{equ:securityRisk} + Security Risk = \frac{p_{da} * w_c}{Security Metric} + + \frac{p_{ida} * w_c}{Security Metic} +\end{equation} -This can be seen in Equation~\ref{equ:securityRisk}, where the probability aspect of risk is split between the chance of how exactly an attack will occur. Direct attack is defined as an event where an attacker directly attempts to brute force a given security mechanism or standard. An indirect attacker is one where a malicious user attempts to circumvent existing security by some aspect that is not directly related to the mentioned security implementation. Once risk has been defined in the scope/lens of examination, one can move develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `value'/`worth' of any given design. However, before these metrics can be developed, one must first determine a framework by which these calculations will be incorporated to allow for a relevant and meaningful interpretation of verification and selection metrics. +This can be seen in Equation~\ref{equ:securityRisk}, where the probability aspect of risk is split between the +chance of how exactly an attack will occur. $w_c$ is the cost weight, i.e. the weight assigned to the cost of +the system. %XXX is this the right definition of cost weight? +$p_{da}$ represents the probability of a direct attack, where direct attack is defined as an event where an +attacker directly attempts to brute force a given security mechanism or standard. $p_{da}$ represents the +probability of an indirect attack, where an indirect attacker is one where a malicious user attempts to circumvent existing security by some aspect that is not directly related to the mentioned security implementation. +%XXX What is the definition of security metric in the equation? +Once risk has been defined in the scope/lens of examination, one can move develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `value'/`worth' of any given design. However, before these metrics can be developed, one must first determine a framework by which these calculations will be incorporated to allow for a relevant and meaningful interpretation of verification and selection metrics. \section{Introducing the Framework} \label{sec:framework} @@ -207,12 +240,14 @@ Ideally verification of a design should be done through validation of the requir 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. -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: +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} \cite{Ferrante2013} \label{equ:qualitative} +\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 `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 @@ -234,7 +269,8 @@ Each `element', in Equation~\ref{equ:securityMetric}, can describe different alg \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. +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} % `Security Risk' = Security Level * direct attacker probability * cost weight \\ @@ -251,7 +287,8 @@ While having an equation for security risk is great, this does not allow for a r Some of the values for this equation, implementation and maintenance costs, are expected to be flat costs that are pre-calculated by a company or business since these values will be specific to the given organization. An important difference between these values are that the `maintenance cost' and `implementation cost' values do not incorporate the operational costs of the design, they only account for the cost of initial implementation of a system design and the cost of performing upkeep for said design. -`User risk type' comes from a business minded examination of risk~\cite{Mukhopadhyay2013} where users can be averse to risk, risk seeking, or risk neutral. The purpose of this variable is a method of representing different users of secure systems that exist within the real-world (e.g. users that are over protective and users that treat security with a laissez-faire attitude). The User Risk Type should produce a lower value is a user is risk averse and a larger value if a given user is risk seeking. In this way, User Risk Type should `negatively' affect the cost of the system as more risk prone individuals become the user. +`User risk type' comes from a business minded examination of risk~\cite{Mukhopadhyay2013} where users can be averse to risk, risk seeking, or risk neutral. The purpose of this variable is a method of representing different users of secure systems that exist within the real-world (e.g. users that are over protective and +users that treat security with a laissez-faire attitude). The User Risk Type should produce a lower value if a user is risk averse and a larger value if a given user is risk seeking. In this way, User Risk Type should `negatively' affect the cost of the system as more risk prone individuals become the user. The `requirements weight' variable can be easily constructed using the same techniques developed by the Ferrante et.~al.~ group to produce a `relativity matrix' of the requirements met, not met, or additional features brought to a design due to the methods, components, and algorithms implemented in a given design. To simplify calculations, one can stick to a more binary representation of requirements as either being met or not being met. The behavior of this requirements weight should be such that having `negative requirements' (e.g. requirements not being met) should cause a larger cost of the design due to specific needs not being met; hence the purpose behind inverting the value. @@ -281,7 +318,7 @@ Port & Normal \end{tabular} \end{table*} -This table will represent the possible architectural components choices that can be made when attempting to develop a new security embedded systems design. The simple example that this paper will examine is that of a wireless transmitter. Listing~\ref{lst:AADLUserDefineLow} shows the AADL user-defined description of the wireless transmitter element being discussed. +This table will represent the possible architectural components choices that can be made when attempting to develop a new security embedded systems design. The simple example that this paper will examine is that of a wireless transmitter. Listing~\ref{lst:AADLUserDefineLow} shows the AADL user-defined description of the wireless transmitter element being discussed. This paper makes use of AADL to aid in modeling embedded systems with security properties and constraints for giving a practical example of our proposed adversarial risk-based approach to embedded systems security modeling. 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.~\cite{AADLV2Overview} \begin{lstlisting}[caption={Example of User-defined Lower Level Components},label={lst:AADLUserDefineLow}] system implementation transmitter.encrypt_i @@ -329,9 +366,11 @@ How does one create the security metric based on the given example? The first s The next step is how to consider differences between the implementations of the wireless transmitter. Differences from values can come from alternative design choices and/or algorithm and policy implementations of security or other standard constraints being imposed onto the design problem. For this simple example, the main difference examined is the implementation of encryption. These different aspects can be compared by assigning weights for allowing relative importance, thus representing (in some arbitrary manner) the user-defined requirements imposed on the design being generated. This human-related favoritism causes the generated metric to alter from a small amount to notable change based on the chosen importance of different features. Other areas originate from the development of `user risk type' and `solution metric', 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, allow this paper to make some simplifications and assumptions to smooth the process. First we will take the assumption that there will be three separate implementations of encryption for the wireless transmitter: AES256 (MIPS), AES128 (MIPS), and no encryption. Drawing from the work by Ferrante et.~al.~, the corresponding security level (SL) values are {1.00, 0.60, 0.10} respectively. Since we have simplified the example to having a single requirements (i.e. encryption of data) then the weight value used for calculating the Security Metric (SM) is 1.00. Now that we have values for SL and the weight, we can move to calculating the SM value for our different encryption scenarios. However, first we must make some assumptions about the cost weight (CW), direct attack probablitiy (DAP), and indirect attack probability (IAP). For the CW value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost and would take one person about 8 man-hours to repair a failure; thus the CW for loss becomes \$20 per 8 man-hours. As for the attack probabilities, this paper assumes that attacking any other wireless transmitter (indirect attack) would be the same as attacking a chosen wireless transmitter and that attacking a central aggregation computer would be out of scope for this example, therefore the indirect attack probability can be taken as 0\%. Assuming that an employee has a less than enthusiastic installation of the transmitter, the DAP value is taken to be 25\% chance of an adversary brute forcing encryption to see the transmitted data. Using Equation~\ref{equ:riskDefinition}, one finds that the SR values for the {AES256, AES128, None} encryption implementations are {0.625, 1.04, 6.25} respectively. +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 three separate implementations of encryption for the wireless transmitter: AES256 (MIPS), AES128 (MIPS), and no encryption. Drawing from the work by Ferrante et.~al.~, the corresponding security level (SL) values are {1.00, 0.60, 0.10} 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. Now that we have values for SL and the weight, we can move to calculating the SM value for our different encryption scenarios. However, first we must make some assumptions about the cost weight ($w_c$), direct attack probablity ($p_{da}$), and indirect attack probability ($p_{ida}$). For the $w_c$ value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost and would take one person about 8 man-hours to repair a failure; thus the $w_c$ for loss becomes \$20 per 8 man-hours. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name? +As for the attack probabilities, this paper assumes that attacking any other wireless transmitter (indirect attack) would be the same as attacking a chosen wireless transmitter and that attacking a central aggregation computer would be out of scope for this example, therefore the indirect attack probability can be taken as 0\%. Assuming that an employee has a less than enthusiastic installation of the transmitter, the $p_{da}$ value is taken to be 25\% chance of an adversary brute forcing encryption to see the transmitted data. Using Equation~\ref{equ:riskDefinition}, one finds that the SR values for the {AES256, AES128, None} encryption implementations are {0.625, 1.04, 6.25} respectively. -From this point, we make further assumptions about the implementation cost (IC), the maintenance cost (MC), and `solution metric'/operational cost (OC) since these values would come from metrics internal to a company or organization. IC is taken to be \$50 in parts and design per 40 man-hours, MC is taken to be \$50 in drive out cost per 4 man-hours to check the system, and OC is assumed to be \$3 in power costs per 12 hours of operation. The RW value is assumed to be 1.00 if the system is encrypted and 0.10 is not; since the effect of not meeting requirements can be view more clearly. Taking the calculation of the estimation metric (EM) from Equation~\ref{equ:estimationMetric}, we produce the contents of Table~\ref{tbl:estimationMetrics} which represents the estimation metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None} and how different User Risk Types (URT) also further influence the metric. +From this point, we make further assumptions about the implementation cost ($c_i$), the maintenance cost ($c_m$), and `solution metric'/operational cost ($c_o$) since these values would come from metrics internal to a company or organization. $c_i$ is taken to be \$50 in parts and design per 40 man-hours, $c_m$ is taken to be \$50 in drive out cost per 4 man-hours to check the system, and $c_o$ is assumed to be \$3 in power costs per 12 hours of operation. The RW value is assumed to be 1.00 if the system is encrypted and 0.10 is not; since the effect of not meeting requirements can be view more clearly. Taking the calculation of the estimation metric (EM) from Equation~\ref{equ:estimationMetric}, we produce the contents of Table~\ref{tbl:estimationMetrics} which represents the estimation metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None} and how different User Risk Types (URT) also further influence the metric. % Please add the following required packages to your document preamble: % \usepackage[normalem]{ulem} @@ -364,9 +403,9 @@ There can also be additional considerations that come about due to how probabili Complications of this examination range from simple questions, such as how does one measure exposure of an element, to more complicated concerns, such as how does one rank known vulnerabilities or how can one be aware of all vulnerabilities within a system. As such, this is perhaps not the best equation for producing an over system metric, but may play a role in a more bounded examination. -An other method of examination would be to focus on the total `wealth' of a system over time. In this case one's focus would be more towards the future and use of a given system within an organization. +Another method of examination would be to focus on the total `wealth' of a system over time. In this case one's focus would be more towards the future and use of a given system within an organization.~\cite{Ferrante2013} -\begin{multline} \cite{Ferrante2013} \label{equ:wealthFunction} +\begin{multline} \label{equ:wealthFunction} `Wealth Function' = Probability Nothing Happens * Initial Wealth \\ + Probability Event Happens * (Initial Wealth - Losses) \end{multline} @@ -463,10 +502,10 @@ Proceedings of the IEEE (March 2007) %AADL, %\url{http://www.aadl.info/aadl/currentsite/} % -%\bibitem {AADLV2Overview} -%Feiler, P.: -%SAE AADL V2: An Overview. -%Carnegie Mellon University (2010) +\bibitem {AADLV2Overview} +Feiler, P.: +SAE AADL V2: An Overview. +Carnegie Mellon University (2010) % %\bibitem {AADLTools} %AADL Tools, @@ -513,15 +552,15 @@ Proceedings of the IEEE (March 2007) %BLESS: Formal Specification and Verification of Behaviors for Embedded Systems with Software, %\url{https://ti.arc.nasa.gov/m/events/nfm2013/pubs/BLESS.pdf} % -\bibitem {AADLSecAnnex} -Delange, J., Feiler, P., Klieber, W., Nam, M., Seibel, J.: -AADL Security Annex, -\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-annex-May2016.pdf} - -\bibitem {AADLSecAnalysis} -Delange, J., Nam, M., Seibel, J.: -AADL Security Analysis Tools, -\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-analysis-May2016.pdf} +%\bibitem {AADLSecAnnex} +%Delange, J., Feiler, P., Klieber, W., Nam, M., Seibel, J.: +%AADL Security Annex, +%\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-annex-May2016.pdf} +% +%\bibitem {AADLSecAnalysis} +%Delange, J., Nam, M., Seibel, J.: +%AADL Security Analysis Tools, +%\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-analysis-May2016.pdf} % %\bibitem {ellison2015extending} %Ellison, R., Householder, A., Hudak, J., Kazman, R., Woody, C.: