diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index 60f23ed..b1ae90a 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -150,7 +150,9 @@ With all the work towards describing and defining security modeling aspects, the %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, since all aspects carry some weight of time (development, testing, production, design), it would be advantageous to have the final estimation metric represented with a money over time unit of measurement. +To better describe these security models, since all aspects carry some weight of time (development, testing, production, design), it would be advantageous to have the final estimation metric represented with a monetary +% over time +unit of measurement. % Add in an image of the drawing from the bulletjournal on the process \begin{figure} @@ -161,7 +163,7 @@ To better describe these security models, since all aspects carry some weight of %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. +%developed embedded system security models. The proposed design framework in Figure~\ref{fig:AADLSecFrame} would require the following steps to take place: \begin{enumerate} @@ -187,7 +189,7 @@ In this section, the paper examines the traditional definition of risk followed \label{sec:traditionalRisk} % 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. +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. Traditionally, risk is a consideration of losses based on the probability of a given event will occur~\cite{Mukhopadhyay2013,pal2014will,fauntleroy2015cyber,biener2015insurability,armando2004satmc,brucker2012securebpmn,gonzalez2012quantitative,mukherjee2013attributed,marotta2015survey}. 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{Mukhopadhyay2013}. Threat is defined as the cause of risk (e.g. fire, kidnapping, leakage of sensitive information, etc.). Vulnerability is defined as the existing 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: @@ -208,41 +210,36 @@ security risk identification can come from a lack of experience and standards or 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 +defender. Further examination of attack and defense considerations will be continued in Section~\ref{sec:attackDefense}. -\begin{equation} %\cite{Mukhopadhyay2013} -\label{equ:expectedLoss} - Expected Loss = Event 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. +%\begin{equation} %\cite{Mukhopadhyay2013} +%\label{equ:expectedLoss} +% Expected Loss = Event 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. \subsection{Quantitative and Qualitative Security} % Summary and application of the Ferrante work % Development of the verification process -To begin developing the verification and selection process, one needs to create a metric of weights based on the relative importance of any given solution $s_i$ in comparison to solution $s_j$~\cite{Ferrante2013}. The purpose of these weights is to allow for comparison of varying solution elements, relative to each other, as they are used within embedded system security modeling solutions. \textit{Importance} is defined as a ranking that will depend on the case of implementation by a given company/group. Because this value is dependent on the `source' examining a particular security model, the value will be partially arbitrary and partially cost analysis. An other influencing factor could also come from the preference/wheel house of a given company or individual. +To begin developing the verification and selection process, one needs to create a metric of weights based on the relative importance of any given solution $s_i$ in comparison to another solution $s_j$~\cite{Ferrante2013}. The purpose of these weights is to allow for comparison of varying solution elements, relative to each other, as they are used within embedded system security modeling solutions. Importance is defined as a ranking that will depend on the case of implementation by a given company/group. Because this value is dependent on the `source' examining a particular security model, the value will be partially arbitrary and partially cost analysis. An other influencing factor could also come from the preference/wheel house of a given company or individual. % Explain the work done by Ferrante et. al. -Borrowing from the work of Ferrante et.~al.~ using the Analytical Hierarchy Process (AHP), this paper moves to examine the process developed for producing weights for various security solutions. +Borrowing from the work of Ferrante et.~al.~using the Analytical Hierarchy Process (AHP), 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} \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 weight and security level (SL) metrics, these values can be used to produce security metrics about a given embedded systems security model design. +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 weight ($w$) and security level ($SL$) metrics, these values can be used to produce security metrics about a given embedded systems security model design. % Introducing the Security Metric equation The next consideration is how does one take these produced values and develop a meaningful equation for generating a comparable metric. Following the examination of the work by Ferrante et.~al.~, their definition of `security metric' is as follows: \begin{multline} \label{equ:securityMetric} Security Metric (SM) = \\ -weight_{elem1} * SL_{elem1} -+ weight_{elem2} * SL_{elem2} \\ -+ {...} + weight_{elemN} * SL_{elemN} +w_{elem1} * SL_{elem1} + w_{elem2} * SL_{elem2} + {...} + w_{elemN} * SL_{elemN} \end{multline} Each `element', in Equation~\ref{equ:securityMetric}, can describe different algorithms, elements, properties, and capabilities of the different components of a system or device. @@ -251,19 +248,16 @@ This same style can be used at higher level abstractions of the same design to p \begin{multline} \label{equ:overallSecMet} Overall SM = \\ -weight_{anti-virus} * SM_{anti-virus} -+ weight_{firewall} * SM_{firewall} \\ -+ {...} + weight_{element i} * SM_{element i} +w_{anti-virus} * SM_{anti-virus} + w_{firewall} * SM_{firewall} + {...} + w_{element i} * SM_{element i} \end{multline} % Introduction to paper's Security Risk security This allows for a designer to now create some arbitrary metric to represent whether or not a given design is better or worse at meeting not only the requirements imposed but also in comparison to other available solutions to the same design problem. While this is a step in the right direction, there no units attached to the overall -security metrics produced by the work of Ferrante et.~al. Without a proper unit attached to a generated metric, the entire process remains arbitrary and more difficult to be used in a relevant and meaningful manner. Calling back to the equation proposed in Section~\ref{sec:riskDefinition}, allow us to make use of the same techniques Ferrante et.~al.~developed but apply them in a more meaningful, cost-based manner. In this way it is possible for a `security risk' metric to be generated but also carry a recognizable worth. %instead of just an arbitrary number scheme. +security metrics produced by this work. Without a proper unit attached to a generated metric, the entire process remains arbitrary and more difficult to use in a relevant and meaningful manner. %Calling back to the equation proposed in Section~\ref{sec:riskDefinition}, allow us +This paper moves 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 impact variable. This is because the impact is a representation of the potential loss caused by an event. -\section{Shit that needs to be elsewhere} - -% Incorporating security into risk calculations +% Trouble when 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. Security levels can also be interdependent depending on implementation and scenario/situation. %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 @@ -271,20 +265,20 @@ A degree of `relativity' is required for developing a security metric, because s %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 interpretations 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' value ($SM$) and impact to the probability that either a direct or an indirect attack occurs to a given system. - -\begin{equation} \label{equ:securityRisk} - Security Risk (SR) = \frac{p_{da} * i}{SM} - + \frac{p_{ida} * i}{SM} -\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. $i$ is the impact, i.e. the cost impact of a event occurring. %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_{ida}$ 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 of examination, one can develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `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. +%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' value ($SM$) and impact to the probability that either a direct or an indirect attack occurs to a given system. +% +%\begin{equation} \label{equ:securityRisk} +% Security Risk (SR) = \frac{p_{da} * i}{SM} +% + \frac{p_{ida} * i}{SM} +%\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. $i$ is the impact, i.e. the cost impact of a event occurring. %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_{ida}$ 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 of examination, one can develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `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{Design Oriented Examination of Risk} \label{sec:riskDefinition} @@ -342,7 +336,7 @@ Each of the events illustrated in Figure~\ref{fig:attackTree} has it's own event Since the traditional view of risk does not account for an attacker's motivations, this paper moves to develop an equation that will represent not only risk due to an attacker but also account for the fact that the calculation is reliant upon multiple sources of probability. A graphical estimation of this behavior is shown in Figure~\ref{fig:attackRisk}. -Security risk of an attack can be represented as a combination of the probability of an attack, probability of the attack succeeding, and the impact of the attack. +Security risk of an attack can be represented as a combination of the probability of an attack ($p_a$), probability of the attack succeeding ($p_s$), and the impact of the attack. \begin{equation} \label{equ:attackRisk} R = p_a * p_s * I @@ -363,18 +357,18 @@ One should note that as $p_s*A$, which is the probability of success multiplied Thus the equation for determining security risk becomes: \begin{equation} \label{equ:expandedRisk} - R = (1 - e^{-(p_s*A - c_a)}*p_s*I + R = (1 - e^{-(p_s*A - c_a)})*p_s*I \end{equation} One then takes Equation~\ref{equ:expandedRisk} and now accounts for an aggregation of an asset $i$ and attack vector $j$ to create the equation: \begin{equation} \label{equ:aggregatedRisk} - R_i = \sum\limits_{j=0}^K (1 - e^{-(p_{s_{ij}}*A_i - c_{a_{ij}})}*p_{s_{ij}}*I_i + R_i = \sum\limits_{j=0}^K (1 - e^{-(p_{s_{ij}}*A_i - c_{a_{ij}})})*p_{s_{ij}}*I_i \end{equation} where K is all the contributing attack vectors for a given asset. Thus Equation~\ref{equ:aggregatedRisk} represents the aggregation of all contributing attack vectors towards the potential compromise of a specific system asset. -\section{Introducing the Framework} +\section{Generating an Estimation Metric} \label{sec:framework} 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? @@ -397,7 +391,7 @@ Ideally verification of a design should be done through validation of the requir % Introduce paper's Estimation Metric equation %While having an equation for security risk is great, this does not allow for a representation of a system as a whole. -Additional aspects that must be taken into account include costs of implementing a given solution, the cost of maintaining a given solution, how a generated solution's ranking will change based on the user type interacting with the system, operational costs of a given solution, as well as determination of the number of requirements met, or not met, by any chosen design solution. Taking these aspects into account, this paper proposes the following equation to calculate an overall `estimation metric' for any produced embedded system security modeling design. +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, operational costs of a given solution, as well as determination of the number of requirements met, or not met, by any chosen design solution. Taking these aspects into account, this paper proposes the following equations to calculate an overall cost and `estimation metric' for any produced embedded system security modeling design. \begin{equation} \label{equ:cost} Costs = c_i + c_{si} + c_m + c_o @@ -407,11 +401,7 @@ Additional aspects that must be taken into account include costs of implementing Estimation Metric = \frac{SR+Costs}{w_r} \end{equation} -Some of the values for Equation~\ref{equ:cost}, implementation and maintenance costs ($c_i$ and $c_m$ respectively), 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 $c_m$ and $c_i$ 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. The $c_{si}$ variable represents any cost due to implementing security aspects into the design. The operational cost ($c_o$) is a value coming from a given individual or company; based on a monetary cost over time unit of measurement. - -% Explination of User Risk Type -`User risk type' (URT) 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. +Some of the values for Equation~\ref{equ:cost}, implementation and maintenance costs ($c_i$ and $c_m$ respectively), 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 $c_m$ and $c_i$ 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. The $c_{si}$ variable represents any cost due to implementing security aspects into the design. The operational cost ($c_o$) is a value coming from a given individual or company; based on a monetary cost over time unit of measurement. In Equation~\ref{equ:estimationMetric}, the `requirements weight' ($w_r$) variable can be easily constructed using the same techniques developed by the Ferrante et.~al.~ to compare the requirements and 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. @@ -422,7 +412,8 @@ Now that aspects of this framework's verification and selection process have bee \section{Exploring a Simple Implementation} \label{sec:simpleExample} -This paper now moves to showing a simple implementation of the security framework's verification and selection process to produce a meaningful `estimation metric' that can be used to compare design decisions. The purpose of this examination is to give a concrete example of the verification equations being used to rank a set of produced solutions to a chosen design problem, as well as illustrate how one may go about developing some of the required rankings. When initially designing a system, there are a large number of considerations that must be taken into account. From power consumption requirements, architectural needs, spacing of parts, and weight of the developed device. When incorporating security elements, the problem becomes larger. For example, allow this paper to assume that the elements in Table~\ref{elementTypes} have numerous variations that can be simplified into a few types. +This paper now moves to showing a simple implementation of the security framework's verification and selection process to produce a meaningful `estimation metric' that can be used to compare design decisions. The purpose of this examination is to give a concrete example of the verification equations being used to rank a set of produced solutions to a chosen design problem, as well as illustrate how one may go about developing some of the required rankings. When initially designing a system, there are a large number of considerations that must be taken into account. From power consumption requirements, architectural needs, spacing of parts, and weight of the developed device. When incorporating security elements, the problem becomes larger. +%For example, allow this paper to assume that the elements in Table~\ref{elementTypes} have numerous variations that can be simplified into a few types. % Add in the table of elements and variations %\begin{table*}[] @@ -442,7 +433,8 @@ This paper now moves to showing a simple implementation of the security framewor %\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 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} +%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 @@ -497,16 +489,18 @@ The four instances of a single possible solution being generated based on two as The first step requires the creation of 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 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. +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 URT and $c_o$, where there are some arbitary decisions made on ranking of users or generated solutions. Before being able to calculate out the estimation matrix for our wireless transmitter example, we make some -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 impact ($i$), direct attack probablity ($p_{da}$), and indirect attack probability ($p_{ida}$). For the $i$ value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name? -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. +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 impact ($I$), attack cost ($c_a$), and the value to an attacker ($A$). For the $I$ value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name? +The $A$ value is assumed to be \$30 per `unit' of stolen data and the $c_a$ is assumed to be \$10 per attack attempt. Using Equation~\ref{equ:expandedRisk}, one finds that the SR values for the {AES256, AES128, None} encryption implementations are {0, 2.73, 15.84} respectively. -From this point, we make further assumptions about the implementation cost ($c_i$), the maintenance cost ($c_m$), and 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, $c_{si}$ is taken to be \$10 for AES256 and \$6 for AES128, $c_m$ is taken to be \$50 in drive out cost, and $c_o$ is assumed to be \$3 in operative power costs. +From this point, we make further assumptions about the implementation cost ($c_i$), security implementation cost ($c_{si}$), the maintenance cost ($c_m$), and 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, $c_{si}$ is taken to be \$10 for AES256 and \$6 for AES128, $c_m$ is taken to be \$50 in drive out cost, and $c_o$ is assumed to be \$3 in operative power costs. %per 12 hours of operation (\textbf{How to ignore time aspect?}). -The $w_r$ 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 viewed 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. +The $w_r$ 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 viewed more clearly. Taking the calculation of the estimation metric (EM) from Equation~\ref{equ:estimationMetric}, we produce the contents of Table~\ref{tbl:calculations} which represents the calculated security risk, costs, and estimation metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None} and how different User Risk Types (URT) also further influence the metric. %% Table showing the calculated security risk %\begin{table}[] @@ -539,16 +533,22 @@ Estimation Metric & 113 & 111.73 & 1188.40 \\ \hline Now that a simple example has been shown, allow this paper to now expand the considerations that are made for this simplistic example. The following section will examine further expansion of `estimation metric' considerations, showing how the calculation of comparable metrics can become more involved and complicated. \subsection{Expanding Considerations} -Despite the efforts to simplify the embedded system security modeling problem, there are a plethora of additional variables that can be taken into consideration depending on the environment and user, or company, at risk. When calculating the estimated cost metrics used for making larger system design decisions, one ideally accounts for as many aspects of the system as possible. When dealing with the constrained domain of embedded systems, this is doubly so. Physical costs of the system carry a heavy weight when making choices about design implementations. Power costs, heat generated, run time, area requirement, etc. are all aspects that must be considered. When incorporating software, the assumption of this paper is that software has been designed correctly with no error or malicious behavior embedded within. To that case, this means that when comparing software implementations, the main considerations of the developer are run time, bits used (in the case of encryption and authentication), and power consumed (with respect to total battery life; total system run time on a single charge). To further add the weight of additional design considerations to our proposed verification and selection process, one can account for any additional features as a result of design decisions. This would mean that the inverted requirements weight would need to be further tailored to account for additional features that a design receives due to the decisions made by a development team. In this manner a design team can further tweak the generation of certain design solutions based on the requirements met and additional features produced as result. - -There can also be additional considerations that come about due to how probabilities, risk, and weights are chosen to be interpreted. Should an individual choose to incorporate features such as exposure or concentrate on sensitivity and security level of individual data, then one could attempt to produce a `probability rating' that represents these concerns, as shown in Equation~\ref{equ:probRating}. +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 (total system run time on a single charge). To further add the weight of additional design considerations to our proposed verification and selection process, one can account for any additional features as a result of design decisions. This would mean that the inverted requirements weight would need to be further tailored to account for additional features that a design receives due to the decisions made by a development team. In this manner a design team can further tweak the generation of certain design solutions based on the requirements met and additional features produced as result. -\begin{multline} \label{equ:probRating} - `Probability Rating' = weight_{sensitivity of data} * `known vulns metric' \\ -+ weight_{exposure} * Security Level Metric_{data?} -\end{multline} +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 overall system metric, but may play a role in a more bounded examination. -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 overall system metric, but may play a role in a more bounded examination. +%% Explination of User Risk Type +%`User risk type' (URT) 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. 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} @@ -591,7 +591,9 @@ end sysreq.wireless_sensor_i; 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. One example of this are the `atkImpact' and `atkValue' fields in Listing~\ref{lst:AADLUserDefineHigh}. These represent potential metrics of importance for different elements, attack vectors, or worth of data that can be obtained by attacking a given system. As a defender, one can work towards detailing a system's defenses to have a better interpretation of the attack landscape. 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} -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'. +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} @@ -599,7 +601,7 @@ While the considerations, up to this point, have mainly been focused on how to d 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. +%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.