diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index b7e17a1..50483ff 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -96,7 +96,8 @@ \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). +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 Analys +is \& 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. @@ -157,156 +158,104 @@ Other additional aspects of this framework, that could come from the existing to \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}). +% 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: +\begin{equation} \label{equ:riskDefinition} + Risk = Probability * Impact +\end{equation} % 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} - -How to define `Risk'? -\begin{itemize} - \item Needs to be represented as a probability - \begin{itemize} - \item means that this value acts as a 0.00 - 1.00 scale weight. - \end{itemize} - \item Risk generally represented as: - \begin{equation} \label{equ:riskDefinition} - Risk = Probability * Impact - \end{equation} - \item How to add `Security' to the risk calculation? - \begin{multline} - `Security Risk' = `Security Metric' * direct attack probability * `cost' weight \\ - + ... + `Security Risk' * indirect attack probability * `cost' weight - \end{multline} - \item Once risk has been defined in the scope/lens of examination, can develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `value'/`worth' of any given design. -\end{itemize} - -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}. +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}. \begin{equation} \cite{Mukhopadhyay2013} \label{equ:expectedLoss} Expected Loss = Risk Frequency * Risk Amount \end{equation} -Risk is not a certainy, but a proability. (All from \cite{Ferrante2013}) -\begin{itemize} - \item Possibility depends on two aspects: (1) threat and (2) vulnerability - \begin{enumerate} - \item Threat - cause of risk (e.g. fire, kidnapping, leakage of sensitive information, etc.) - \item Vulnerability - exiting flaw or weakness which can be exploited and result in an accident - \end{enumerate} - \item Risk states that risk may result in losses for an agent - \begin{itemize} - \item Losses occur because of the consequences of an accident (called Impact) - \end{itemize} -\end{itemize} -Depending on impacted assest `Impact' may be: -\begin{enumerate} - \item Tangible (e.g. loss of revenue or financial penalties) - \item Intangible (e.g. loss of productivity or loss of reputation) -\end{enumerate} -`Asset' = anything valuable to a user/organization. -\begin{itemize} - \item can be (1) a physical object, (2) secrete information, (3) business goal, etc. -\end{itemize} -Risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact. -Complications in Risk Indentification can come from: -\begin{enumerate} - \item Lack of experience and standards - novel and have not yet standardized procedures for dealing within `Cyber-domain' - \item Evolution of System - computer systems evolve fast/quickly, system of an organization can change quickly, new technologies appear very often; changing the landscape of `cyber risks' -\end{enumerate} -Security levels are interdependent depending on implementation and scenario/situtation. +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. + +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' = `Security Metric' * direct attack probability * `cost' weight \\ + + ... + `Security Risk' * indirect attack probability * `cost' weight +\end{multline} + +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. \section{Introducing the Framework} \label{sec:framework} -Give a detailed description of the framework at this point in time. What is there and what the paper will present. - -Now that this paper has presented a meaningful manner of representing security risk as a metric, this paper moves to show that the introduced security framework is an ideal fit for continuing development and improvement of embedded system security modeling techniques and methodologies. The key points to touch upon in this section are: -\begin{itemize} - \item What does the proposed framework bring to the table that lacked in previous security framework designs? The new security framework proposed allows for generation of embedded system security models by assuming that the security requirements and architectural component capabilities can be represented in a quantitative manner. With the framework, shown in Figure~\ref{fig:AADLSecFrame}, one can take the risk equations developed in Section~\ref{sec:riskDefinition} and produce a meaningful metric estimation that can be used to compare and contrast varying security model solutions. Combination of the framework's mapping process and the risk equations developed is done in the following manner: - \begin{itemize} +Now that this paper has presented a meaningful manner of representing security risk as a metric, this paper moves to show that the introduced security framework is an ideal fit for continuing development and improvement of embedded system security modeling techniques and methodologies. What does the proposed framework bring to the table that lacked in previous security framework designs? The new security framework proposed allows for generation of embedded system security models by assuming that the security requirements and architectural component capabilities can be represented in a quantitative manner. With the framework, shown in Figure~\ref{fig:AADLSecFrame}, one can take the risk equations developed in Section~\ref{sec:riskDefinition} and produce a meaningful metric estimation that can be used to compare and contrast varying security model solutions. Combination of the framework's verification process and the risk equations developed is done in the following manner: + \begin{enumerate} \item Define the security requirements and architectural components in a numerically meaningful manner. \item Take these unit-less metrics and apply a `conversion equation' to them in order to produce a meaningful, `monetary unit' based metric. \item Develop a method of interpreting the metrics in terms of requirements met, not met, and additional features added to the system. - \item Combine these metrics in a unified equation that can be used to take in values from the functional and architectural space to produce a series of embedded system security model solutions. - \end{itemize} - \item What are the complication of combining these techniques? - \begin{itemize} - \item 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. - \item Certain aspects of this mapping 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 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). - \end{itemize} - \item Now that aspects of this framework's mapping process have been explained, allow us to apply these techniques to a sample example. -\end{itemize} - -\begin{itemize} -\item Need to create a matric of weights based on the relative importance of any given solution $s_i$ in comparison to solution $s_j$~\cite{Ferrante2013}. -\item \textit{Importance} is defined as: `case of implementation by a given company/group. -\item Will be partially arbitrary and partially cost analysis. -\item Could also come from the preference/wheel house of a given company. -\end{itemize} + \item Combine these metrics in a unified equation that can be used to take in values from the functional and architectural space to produce a series of embedded system security model solution metrics. + \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. + +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). + +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: + +\begin{equation} \cite{Ferrante2013} \label{equ:qualitative} + L_i = \sum_{j=1}^{R} g_j * v_{ji}, i = 1,2,...,S +\end{equation} + +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. + +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} `Security Metric' (Security Level) = \\ -weight_{component capability 1} * Security Level_{component capability 1} \\ -+ weight_{component capability 2} * Security Level_{component capability 2} \\ -+ {...} + weight_{component capability n} * Security Level_{component capability n} +weight_{element 1} * Security Level_{element 1} \\ ++ weight_{element 2} * Security Level_{element 2} \\ ++ {...} + weight_{element n} * Security Level_{element n} \end{multline} -\textbf{Note:} Not sure if `component capability' is the right way to describe different algorithms, elements, properties, and capabilities of these different elements of a system/device. Equation is not necessarily limited to a single use within entire process. -Example of calculating aggregated security metrics of a system (i.e. network security): +Each `element', in Equation~\ref{equ:securityMetric}, can describe different algorithms, elements, properties, and capabilities of the different components of a system or device. It is worth noting that this equation is not necessarily limited to a single use within entire process. This same style can be used at higher level abstractions of the same design to produce an overall security metric representing a larger system of components. Harking back to our discussion of risk, the following is an example of calculating aggregated security metrics of a system (i.e. network security): + \begin{multline} \label{equ:overallSecMet} `Overall Security Metric' = weight_{anti-virus} * Security Metric_{anti-virus} \\ + weight_{firewall} * Security Metric_{firewall} \\ + weight_{element i} * Security Metric_{element i} \end{multline} -\begin{multline} \label{equ:securityRisk} - `Security Risk' = Security Level * direct attacker probability * cost weight \\ - + Security Level * indirect attacker probability * cost weight -\end{multline} +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 \\ +% + Security Level * indirect attacker probability * cost weight +%\end{multline} + +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} `Estimation Metric' = `User Risk Type' * `Security Risk' + `implementation cost' + \\ - `maintainence cost' + `solution metric' * `requirements weight' + `maintenance cost' + `solution metric' * \frac{1}{`requirements weight'} \end{multline} +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. + +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. + +The `solution metric' value is a more arbitrary value coming from an internal ranking of solution `worth' to a given individual or company. For the purpose of Equation~\ref{equ:estimationMetric}, this `solution metric' should be representative of the operational cost of a given design based on a monetary cost over time unit of measurement. The aspiration behind the last part of Equation~\ref{equ:estimationMetric} is that this represents that operation cost of the design being weighted by the number of requirements that are met and those that have not been met (using a 0.00 -{}- 1.00 scale). + +Now that aspects of this framework's verification and selection process have been explained, allow us to apply these techniques to a sample example. + \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: -\begin{itemize} - \item What is the example to be shown? The simple example that this paper will examine is that of a wireless transmitter. In this example, there are four variations that exist of said transmitter: - \begin{enumerate} - \item Non-encrypted communication with a separate input and output buses. - \item Encrypted communication with separate input and output buses. - \item Non-encrypted communication with a single IO bus. - \item Encrypted communication with a single IO bus. - \end{enumerate} - For this example, one is deal with four instances of a single possible solution being generated based on two aspects of the architectural space: (1) the number of IO buses available and (2) whether or not communication should be encrypted. For the sake of simplicity, this paper makes use of the `relativity matrix' developed by Ferrante et.~al.~\cite{Ferrante2013} - \begin{itemize} - \item Wireless transmitter example - \end{itemize} - \item How does one create the security metric based on the given example? - \begin{itemize} - \item Require the creation of `relativity matrix'~\cite{Ferrante2013} for developing a relatively deterministic security metric value. (Perhaps cite work and use metrics developed by Ferrante et.~al.). The point of this is to generate a ranking for all known solutions that ranges from 0.00 -{}- 1.00 that can be used as a weight with other known cost variables to produce a metric that can be used to compare potential generated solutions. - \item How to consider differences between the four implementations of the wireless transmitter? - \begin{itemize} - \item What are the differences? 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. - \item How can they be represented? 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. - \item How does this effect the metric? 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. - \end{itemize} - \end{itemize} - \item Now that a simple example has been shown, allow this paper to now expand the considerations that are made for this simplistic example. -\end{itemize} +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. % Add in the table of elements and variations \begin{table*}[] @@ -326,6 +275,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. \begin{lstlisting}[caption={Example of User-defined Lower Level Components},label={lst:AADLUserDefineLow}] system implementation transmitter.encrypt_i @@ -359,16 +309,48 @@ processor implementation procbase.encryptembedded_i end procbase.encryptembedded_i; \end{lstlisting} +In this example, the paper assumes that there are four variations that exist of said transmitter: +\begin{enumerate} + \item Non-encrypted communication with a separate input and output buses. + \item Encrypted communication with separate input and output buses. + \item Non-encrypted communication with a single IO bus. + \item Encrypted communication with a single IO bus. +\end{enumerate} +The four instances of a single possible solution being generated based on two aspects of the architectural space: (1) the number of IO buses available and (2) whether or not communication should be encrypted. +%For the sake of simplicity, this paper makes use of the `relativity matrix' developed by Ferrante et.~al.~\cite{Ferrante2013} for representing the security level metrics on the encryption standards used. + +How does one create the security metric based on the given example? The first step requires the creation of `relativity matrix'~\cite{Ferrante2013} for developing a relatively deterministic security metric value. The point of this is to generate a ranking for all known solutions that ranges from 0.00 -{}- 1.00 that can be used as a weight or security level with other known cost variables to produce a metric that can be used to compare potential generated solutions. For the purpose of this paper, we will be making use of the encryption standard rankings developed by Ferrante et.~al. + +The next step is how to consider differences between the four 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 differences are the number of IO lines and 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. + +\textbf{SHOW THE EQUATION BEING PUT INTO PRACTICE} + +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} -What other additional expansions can be made to the simple wireless transmitter example? Additional costs, variables, levels of additional detail. +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. + +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}. + +\begin{multline} \label{equ:probRating} + `Probability Rating' = weight_{sensitivity of data} * `known vulns metric' \\ ++ weight_{exposure} * Security Level Metric_{data?} +\end{multline} + +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. + +\begin{multline} \cite{Ferrante2013} \label{equ:wealthFunction} + `Wealth Function' = Probability Nothing Happens * Initial Wealth \\ ++ Probability Event Happens * (Initial Wealth - Losses) +\end{multline} + +`Initial Wealth' can be calculated from the design model generated, while the probability of events occurring will require more statistical harvesting of information relating to known attacks or event occurring within a given system. While advantageous from a business standpoint, this equation is also tailored to a specific point of view for examination of a given embedded systems security model. Expanding on this concept of point-of-view, then next section moves to examining the generated secure embedded system models through the eyes of both the defender and the attack as well as considerations that arise. -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. This section will talk on the subject of: -\begin{itemize} - \item Physical costs (VHDL). 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. - \item Methodologies, algorithms, implementations. 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). - \item Requirements met, requirements not met, additional features due to architectural components used. To further add the weight of additional design considerations to our proposed mapping process, one can account for the requirements that a given design meets, does not meet, and additional features as a result of design decisions. 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. -\end{itemize} -One can further complicate these calculations by including a difference in examining the costs from the standpoint of both the defender of some sensitive information and the attacker trying to acquire any and all `useful' data. +\section{Examining Attack and Defense with Detail} +\label{sec:attackDefense} +The purpose of this section is to take the framework, along with the verification and selection process, and examine the stages of encryption and authentication and how including attack and defense considerations changes the landscape. Depending on the point of view of the individual examining a system, the risk and cost analysis will yield different results to different individuals based on produced incentive and attractiveness of obtainable information in comparison to the defenses that must be circumvented and the related cost. This means that when accounting for the attacker and defender view, there will be further levels of considerations and some that can be wholly arbitrary. Certain aspects may be similar, such as the number of steps an individual must go through to interact with a system (e.g. subnets). While these do exist, the area of greater interest are the aspects that differ between the two points of view. To begin this process one needs to detail out any and all statistical information about attacks on various systems, how the hardware and software nuances affect the overall ranking of different methodologies, and most difficult, one must determine a method for applying the arbitrary qualitative sense of worth for specific data to one's equations in a meaningful way. Otherwise the generated estimation metric becomes unintelligible. \begin{lstlisting}[caption={User-defined Higher Level Security Requirement},label={lst:AADLUserDefineHigh}] abstract implementation sysreq.wireless_sensor_i @@ -394,49 +376,23 @@ abstract implementation sysreq.wireless_sensor_i end sysreq.wireless_sensor_i; \end{lstlisting} -\begin{multline} \label{equ:probRating} - `Probability Rating' = weight_{sensitivity of data} * `known vulns metric' \\ -+ weight_{exposure} * Security Level Metric_{data?} -\end{multline} - -\begin{multline} \label{equ:wealthFunction} - `Wealth Function' = Probability Nothing Happens * Initial Wealth \\ -+ Probability Event Happens * (Initial Wealth - Losses) \cite{Ferrante2013} -\end{multline} -`Initial Wealth' can be calculated from the design model generated. \textbf{Note:} `Wealth Function' is focused on the future and use of a given system within an organization. - -\section{Examining Attack and Defense with Detail} -\label{sec:attackDefense} -Examination of encryption and authentication processes through the lens of the new security framework. - -The purpose of this section is to touch on the following topics: -\begin{itemize} - \item The different considerations of attackers and defenders. Depending on the point of view of the individual examining a system, the risk and cost analysis will yield different results to different individuals based on produced incentive and attractiveness of obtainable information in comparison to the defenses that must be circumvented and the related cost. - \item What aspects are the same or similar enough to take into account. Certain aspects may be similar, such as the number of steps an individual must go through to interact with a system (e.g. subnets). While these do exist, the area of greater interest are the aspects that differ between the two points of view. - \item How to begin developing the required information. Need to detail out any and all statistical information about attacks on various systems, how the hardware and software nuances affect the overall ranking of different methodologies, and most difficult, one must determine a method for applying the arbitrary qualitative sense of worth for specific data to one's equations in a meaningful way. Otherwise the generated estimation metric becomes unintelligible. -\end{itemize} - -Can create a `correlation matrix' of the inacted defenses and the affect of failure of one defence on the other existing defense (0-1 scaled as well). +One can further complicate these calculations by including a difference in examining the costs from the standpoint of both the defender of some sensitive information and the attacker trying to acquire any and all `useful' data. For example: one can create a `correlation matrix' of the enacted defenses and the affect of failure of one defense on the other existing defense (0-1 scaled as well), as this would allow for greater detail of the system from the point of the defender. Additionally, this same information would be of great importance to a would-be attacker. \subsection{Expansion of Details} -Expand further on additional details and variables that can affect the modeling of secure system solutions. - -The purpose of this section is to talk about the topics: -\begin{itemize} - \item Additional concerns of attackers/defenders that can be considered. One can begin to account for the worth of data to external parties (e.g. any other individual that is not the attacker or defender; black market or customers). Then one must account for the arbitrary worth of that information to another individual, which could also vary greatly. For example: an encrypted file that a computer novice comes across will have little worth to them, but to an individual whom has experience this may pass some calculated risk threshold. -\end{itemize} +While the examinations proposed here are specific to the system under examination, considerations can extend to a far larger scope of concern. One can begin to account for the worth of data to external parties (e.g. any other individual that is not the attacker or defender; black market or customers). Then one must account for the arbitrary worth of that information to another individual, which could also vary greatly. For example: an encrypted file that a computer novice comes across will have little worth to them, but to an individual whom has experience this may pass some calculated risk threshold. Additionally, a person could act as an `information broker' that may not have a `worth' value attached to data at this point, but in the future the worth associated with specific information could easily rise or fall depending on content and `liveliness'. \section{Additional Concerns} \label{sec:additionalConcerns} -The purpose of this section is to talk about the topics: -\begin{itemize} - \item Detail out the concerns about for needs of `libraries' of information and other data that will be required for greater formalization of calculated values. - \item Point is to try and have as few `unitless' metric values due to their arbitrary nature. At least will need to convert values to monetary value at some point since time can equal \$\$\$. - \item There are still aspects of this process that are arbitrarily decided upon. This is an extremely difficult part to remove from the current examination of security framework mapping using an adversarial risk-based approach to embedded systems security modeling, due to the need for qualitative input to a system that has yet to have standard of quantitative input. -\end{itemize} +While the considerations, up to this point, have mainly been focused on how to define risk, how to interpret qualitative values of security into quantitative one, and even how the examination of a system changes when incorporating attacker and defender points of view, there are still larger problems that must be addressed. + +One of the largest problems facing security verification and validation techniques is the requirement for a `security expert' to formulate `libraries' of information and other data that will be needed for greater formalization of calculated values. Unfortunately these `libraries' are almost entirely arbitrary with respect to the knowledge and experience of a given security expert. This allows a great deal of room for inconsistencies due to human input. While Ferrante et.~al.~developed a method for locating inconsistencies within their work, there is no standardized methodology for determining inconsistencies in general. this means that these values can not be calculated in a deterministic manner and require a more `relatively deterministic' touch. + +An other concern is that current attempts at developing security metrics produce unit-less metrics; due to their arbitrary nature. For example: in the work by Ferrante et.~al.~they are able to produce a metric value, but the interpretation of that value requires an explanation by the researchers instead of allowing for a glance-interpretation of the data. This complicates manners of comparison and is a known problem when trying to develop new benchmarks and standards for comparison. This paper proposed a standard of maintaining a monetary-time value since most aspects of security incorporate time to some degree and it is relatively simple to associate a financial value to time spent. + +The last, and perhaps largest concern, is that there are still aspects of the proposed process that are arbitrarily decided upon. This is an extremely difficult element to remove from the current examination of security framework verification and selection using an adversarial risk-based approach to embedded systems security modeling due to the need for qualitative input to a system that has yet to have standard quantitative input. While this work will continue to attempt to minimize the use of arbitrary values and rankings, it will take the effort of the entire security community to help move security measurements from a qualitative scale for a more quantitative one. \section{Conclusion} -What has this paper shown? What needs to be worked on moving forward? +Having examined a new security modeling framework, coupled with the examination of its verification and selection process, it is the hope of the paper that the reader has begun to see not only how to produce meaningful security and risk-based metrics, but also see how additional consideration of worth to attacking and defending parties can complicate calculations due to a lack of knowledge and experience of how to measure and relate them. As the security community continues to develop and grow new techniques and methodologies, they must also rigorously standardize their method of examination to allow for better, more effective verification and selection of `best fit' embedded system security modeling solutions. Future work include further development of the mapping process using a risk-based methodology, continue creating more deterministic means for describing security requirements and architectural component capabilities in a meaningful and comparable manner, and development towards an automated method for comparing generated solutions within a constrained and directed manner to arrive at best solutions for generated embedded systems security models.