From 8695b955f5483c3b7bcd65fea3bcf9af07d9a910 Mon Sep 17 00:00:00 2001 From: Duncan Date: Mon, 18 Jul 2016 09:39:14 -0400 Subject: [PATCH] Edits by Professor Chandy --- AADLSecPaper.tex | 113 ++++++++++++++++++++++++++++------------------- 1 file changed, 67 insertions(+), 46 deletions(-) diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index 0826743..71261eb 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -95,7 +95,7 @@ %security in AADL and then goes to propose a new framework for better integration and description of security %requirements and behavior within the AADL lexicon. Embedded systems design and verification has become more complicated as aspects of security need to be included -in examinations. The obvious implications of adding security are the need to account for impacts of +in the design process. The obvious implications of adding security are the need to account for impacts of loss (risk) and accounting for the ensuing increased design costs. The considerations that are not traditionally examined are those of the adversary and the defender of a given system. Without accounting for the view point of the individuals interacting with any secure embedded system design, one can not verify and @@ -117,10 +117,10 @@ that aid in the development and improvement of security modeling approaches. Fo \end{figure} In order to use a design process such as this, we need to be able to have metrics that are able to evaluate the quality of a design solution in relation to the quality of other possible design solutions. -How does one begin to place metrics on an arbitrary measure like security risk? Risk is generally treated as a probability that an event will occur. To define risk from an embedded systems security modeling standpoint, one must first determine how to define risk in a meaningful manner, and how to then apply this metric to the situation that involved said `security risk' (more on this topic will be explored in Section~\ref{sec:riskDefinition}). Quantitative aspects of security will be relatively simple to incorporate with risk calculations. How does one define qualitative aspects of security? One method that can be used to assign a quantitative value to a qualitative property is to use a relative ranking system to scale all available +How does one begin to place metrics on an arbitrary measure like security risk? Risk is generally treated as a probability that an event will occur. To understand risk from an embedded systems security modeling standpoint, one must first determine how to define risk in a meaningful manner, and how to then apply this metric to the situation that involved said `security risk' (more on this topic will be explored in Section~\ref{sec:riskDefinition}). Quantitative aspects of security will be relatively simple to incorporate with risk calculations. How does one define qualitative aspects of security? One method that can be used to assign a quantitative value to a qualitative property is to use a relative ranking system to scale all available solutions from a 0.00 -{}- 1.00 scale as explored by Ferrante et.~al.~\cite{Ferrante2013}. -First this paper will need to develop a verification and selection process for taking all of the cataloged information and possible solutions \& compare and contrast solutions that meet user-defined security requirements while categorizing solutions that are maintaining within external constraints and the capabilities of the architectural components being used to produce a best fit; measured by this paper's verification and selection process (Section~\ref{sec:riskDefinition}). To begin this approach, one will first need to define the constraints of the system, describe the considerations that must be taken into account, and standardize a method by which an individual can produce a comparable metric for generated embedded system security model designs (Seciton~\ref{sec:framework}). In the following Sections, this paper will produce examples of the verification and selection process (Seciton~\ref{sec:simpleExample}), then expand the discussion to include additional considerations (e.g. physical, adversarial). Lastly the paper will speak to some last, larger, considerations followed by the conclusions and future work towards producing an adversarial risk-based approach to embedded systems security modeling. +First, this paper will need to develop a verification and selection process for taking all of the cataloged information and possible solutions \& compare and contrast solutions that meet user-defined security requirements while categorizing solutions that are maintaining within external constraints and the capabilities of the architectural components being used to produce a best fit; measured by this paper's verification and selection process (Section~\ref{sec:riskDefinition}). To begin this approach, one will first need to define the constraints of the system, describe the considerations that must be taken into account, and standardize a method by which an individual can produce a comparable metric for generated embedded system security model designs (Seciton~\ref{sec:framework}). In the following Sections, this paper will produce examples of the verification and selection process (Seciton~\ref{sec:simpleExample}), then expand the discussion to include additional considerations (e.g. physical, adversarial). Lastly the paper will speak to some last, larger, considerations followed by the conclusions and future work towards producing an adversarial risk-based approach to embedded systems security modeling. %\section{Motivation and Related Work} %Work has been made to describe behavior, errors, some security properties in terms of verification and validation within the AADL language. These developments have occurred in a variety of annexes, most recently the security annex extensions and alterations that have been occurring throughout the summer of 2016~\cite{AADLSecAnnex,AADLSecAnalysis}. Attempts are always being made to improve AADL and incorporate more in the description and detail of the language. Recent work includes the definition of specific security-based properties, ranging from `AccessProteciton' to security level definitions to even such extensive work as defining all the different aspects of encryption (shown in Listing~\ref{lst:AADLSecEncryption}). @@ -283,7 +283,12 @@ Ideally embedded system security modeling should have more deterministic interpr \section{Design Oriented Examination of Risk} \label{sec:riskDefinition} -While traditional views of risk only deal with a single source of probability, the examination of security risk is more involved due to multiple sources of probability (e.g. probability of attack, probability of success). Each possible attack vector upon a system has two sources of probability, meaning that as multiple steps are taken to perform a successful data exfiltration attack one needs to accurately aggregate the individual costs of each event in the process. To help with the visualization of potential attack vectors, this paper presents a illustrative example of a potential `attack tree'. +While traditional views of risk only deal with a single source of probability, the examination of security risk +is more involved due to multiple sources of probability.% (e.g. probability of attack, probability of success). +Each possible attack vector upon a system is dependent on a series of exploits, meaning that as multiple steps +are taken to perform a successful data exfiltration attack, one needs to accurately aggregate the individual +costs of each event in the process. To help with the visualization of potential attack vectors, we +present an illustrative example of a potential `attack tree' on a piece of data. \begin{figure} \centering @@ -314,7 +319,8 @@ While traditional views of risk only deal with a single source of probability, t \label{fig:attackTree} \end{figure} -Each of the events illustrated in Figure~\ref{fig:attackTree} has it's own event probability and cost attached to the respective event. Further complication in the attack vector tree can come from variation in each event; is the encryption being attacked 64-bit or 128-bit? +Each of the events illustrated in Figure~\ref{fig:attackTree} has it's own event probability and cost.% attached to the respective event. +Further complication in the attack vector tree can come from variation in each event - for example, is the encryption being attacked 64-bit or 128-bit? \begin{figure} \centering @@ -334,21 +340,36 @@ Each of the events illustrated in Figure~\ref{fig:attackTree} has it's own event \label{fig:attackRisk} \end{figure} -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 ($p_a$), probability of the attack succeeding ($p_s$), and the impact of the attack. +Beyond the notion of an attack vector, the traditional view of risk also does not account for an attacker's +motivations. This paper moves to develop a model that will not only account for the fact that the calculation is reliant upon multiple sources of probability but also represent risk due to an attacker's intent. +First, we modify the traditional risk model (Eq.~\ref{equ:riskDefinition}) to represent the security risk, $SR$, 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} SR = p_a * p_s * I \end{equation} -The probability of an attack is defined as the chance that a given system, or element, is going to be targeted by an attacker's efforts. The probability of success is defined as the chance that an attacker's efforts will pay off positively for the attack, or negatively for the defending system. The probability of success is tied to the level of security implemented in the design, represented by the security metric (SM) value. This alters Equation~\ref{equ:attackRisk} to become: +The probability of an attack is defined as the chance that a given system, or element, is going to be targeted by an attacker's efforts. In other words, if the system is not of any interest to an attacker, i.e. $p_a=0$, the risk is 0. If the system is highly desirable to attackers, i.e. $p_a=1$, the risk is dependent completely on the probability of success. The probability of success is defined as the chance that an attacker's efforts will pay off positively for the attack, or negatively for the defending system. The probability of success is thus tied to the quality of the security defenses built into the system design. While determining this probability is difficult and will require further study, a useful approximation can be represented by the security metric (SM) value discussed earlier. This alters Equation~\ref{equ:attackRisk} to become: \begin{equation} SR = p_a * (1 - SM) * I \end{equation} -One should note that as $p_s*A$, which is the probability of success multiplied by the value to an attacker, changes so should the value of $p_a$, or the probability of an attack. It is also worth noting that $p_a$ is influenced by the cost to attack ($c_a$) a given system, in such a manner that if $p_s*A < c_a$ then $p_a$ = 0\% otherwise if $p_s*A \geq c_a$ then $p_a$ should grow from 0\% to, eventually, 100\%. This is because $c_a$ should be zero until such a time that the $p_s*A$ aspect become meaningful. Harking back to Figure~\ref{fig:attackRisk}, we arrive at the equation for the probability of attack becomes: + +Now, we turn our attention to determining an appropriate value for $p_a$. First, we introduce a new variable, +$A$, which we define as the value of an attack to an attacker. This is distinct from $I$ which is the impact of +an attack to the defender. As an example, a credit card number has a current value of a few dollars to an +attacker. However, a defender may have impact costs of hundreds of dollars due to lost reputation, credit +monitoring fees, regulatory fines, etc. Similarly, different attackers may also assign different values, $A$, +to assets under attack. For our purposes, we assume a single attacker model, but one could arrived at an +aggregate $A$ with weighted assignments due to different attackers. First, we note that as $p_s*A$, which is +the probability of success multiplied by the value to an attacker, changes so should the value of $p_a$, or the +probability of an attack. In other words, one would expect that as the expected value of an attack increases, +the likelihood of an attack will also increase. It is also worth noting that $p_a$ is influenced by the cost to +attack ($c_a$) a given system, in such a manner that if $p_s*A < c_a$ then $p_a$ = 0\% otherwise if $p_s*A \geq +c_a$ then $p_a$ should grow from 0\% to, eventually, 100\%. This is because $c_a$ should be zero until such a +time that the $p_s*A$ aspect become meaningful. We suggest an exponential relationship between the expected +value and $p_a$ as shown in Figure~\ref{fig:attackRisk} and the following equation: +%Harking back to Figure~\ref{fig:attackRisk}, we arrive at the equation for the probability of attack becomes: \begin{equation} p_a = 1 - e^{-(p_s*A - c_a)} @@ -366,11 +387,11 @@ One then takes Equation~\ref{equ:expandedRisk} and now accounts for an aggregati {SR}_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. +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{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. +Now that we have presented a meaningful manner of representing security risk as a metric, we move 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} @@ -547,42 +568,10 @@ Estimation Metric & 87.84 & 91 & 88 & 95.73 \\ \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 (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}. -% -%\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. - -% 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 would be as 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). This would allow for the risk value produced to account for a degree of user tolerance. For example: the expected risk of two designs may be calculated to be \$10,000 (1\% of \$1,000,000 or 10\% of 100,000) but the type of user expected to interact with the designed system leads to a preference for one design over an other. Thus, a developer must now also account for the behavior of the people using the system and incorporate how the user risk type affects the potential losses incurred. Risk averse users would allow for riskier designs to be considered, whereas having the expectation of risk seeking users leads to development of less risky designs. - -%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} -% -%\begin{multline} \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. - \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 views, 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. +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 views, 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 @@ -615,8 +604,40 @@ While the examinations proposed here are specific to the system under examinatio %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} +%\section{Additional Concerns} +\section{Expanding Considerations} \label{sec:additionalConcerns} +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. + +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. + +% 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 would be as 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). This would allow for the risk value produced to account for a degree of user tolerance. For example: the expected risk of two designs may be calculated to be \$10,000 (1\% of \$1,000,000 or 10\% of 100,000) but the type of user expected to interact with the designed system leads to a preference for one design over an other. Thus, a developer must now also account for the behavior of the people using the system and incorporate how the user risk type affects the potential losses incurred. Risk tolerant users would not only allow for riskier designs but would also be willing to tolerate low probabilities of high loss. Likewise, risk averse users would lead to development of less risky designs that also limit the maximum potential loss. + +%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} +% +%\begin{multline} \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. + 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 ones, 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.