diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index 6126034..b7e17a1 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -96,50 +96,25 @@ \end{abstract} \section{Introduction} -Talk about need for a new security framework in AADL. What is missing, what is needed. -What will this paper be bringing to the table? - 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). -\begin{itemize} - \item Modeling security is a difficult problem that has not been thoroughly explored. To properly modeling 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 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. \begin{figure} - \includegraphics[width=0.5\textwidth]{./images/recursivePBD.png} + \includegraphics[width=\textwidth]{./images/recursivePBD.png} \caption{Visualization of Recursive PBD Model~\cite{Vincentelli2007}} \label{fig:recursivePBD} \end{figure} - \item What are the challenges? The challenges faced - \begin{itemize} - \item 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}. - \item 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}. - \end{itemize} - \item Why use AADL? 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. - \item What needs to be done that is not being done? - \begin{itemize} - \item Need to develop a mapping process for taking all of the cataloged information and possible solutions \& producing solutions that meet user-defined security requirements while maintaining within external constraints and the capabilities of the architectural components being used. 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.% - \end{itemize} -\end{itemize} -This paper aims to produce an adversarial risk-based approach to embedded systems security modeling. +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. + +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. \section{Motivation and Related Work} -Points to make in this section of the paper: -\begin{itemize} - \item Recap summary of the SSR paper/ - \begin{itemize} - \item What has been done by others to expand the security capabilities of AADL? - \begin{itemize} - \item 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}. - \end{itemize} - \item What is missing from the work of others? - \begin{itemize} - \item 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. - \item 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 an `easy' 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. - \end{itemize} - \item Section~\ref{sec:framework} will propose a security framework that can be used for applying mapping process by which a set of risk-based equations can be used to assign metrics to developed embedded system security models. But before one can even begin to apply a framework to this mapping 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. - \end{itemize} -\end{itemize} +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 @@ -160,6 +135,10 @@ 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. + +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} \centering\includegraphics[height=6cm]{./images/aadl_security_framework.png} @@ -167,32 +146,29 @@ supported_operations_mode : \label{fig:AADLSecFrame} \end{figure} -The new security framework that this paper proposes would require the following steps to take place: +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: \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 compared to allow for the generation of potential secure architectural system model solutions to the given inputs. + \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}. +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. \section{Defining Risk} \label{sec:riskDefinition} 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}). -\begin{itemize} - \item 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. - \begin{itemize} - \item This paper's definition of risk and cost modeling is the core of this paper. - \end{itemize} - \item What are the many different ways that risk can be assessed? Also, from whose perspective is the examination taking place? 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. However, for the sake of this paper's work, the interpretation of risk to be used will focus on the probability of an event occurring multiplied by the impact of such an event's occurrence. - \begin{itemize} - \item Mention here the idea of measuring risk from a defender's and attacker's standpoints, how those differ, and what the similarities are. (Reference later Section here?) 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}. - \end{itemize} - \item How can one add security into a risk management? - \begin{itemize} - \item 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. - \item 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. - \item Propose a method for combining security and risk in a measurable manner. 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. This can be seen in Equation~\ref{equ:securityRisk}, where the probability aspect of risk is split between the chance of how exactly an attacker 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. + +% 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}). 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 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}. + +% 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. + +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. This can be seen in Equation~\ref{equ:securityRisk}, where the probability aspect of risk is split between the chance of how exactly an attacker 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. \end{itemize} \end{itemize} @@ -303,6 +279,7 @@ Example of calculating aggregated security metrics of a system (i.e. network sec \end{multline} \section{Exploring a Simple Implementation} +\label{sec:simpleExample} How does a simple examples such as a wireless transmitter get represented in this new framework? 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. This Section must be sure to cover: