diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index 1d0c47e..8232c7b 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -180,8 +180,8 @@ examination and evaluation an attacker may make of a system. However, before on framework to this verification and selection process, one needs to first be able to define `Security Risk' so that a relatively deterministic formula can be used to obtain a meaningful metric. -\section{Defining Risk} -\label{sec:riskDefinition} +\section{Related Work} +\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. @@ -210,7 +210,7 @@ Section~\ref{sec:attackDefense}. \begin{equation} %\cite{Mukhopadhyay2013} \label{equ:expectedLoss} - Expected Loss = Risk Frequency * Risk Amount + 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. @@ -239,6 +239,40 @@ probability of an indirect attack, where an indirect attacker is one where a mal 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} + +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'. + +\begin{figure} +\centering +\begin{tikzpicture} [xscale=3, yscale=1] +%\draw [<->] (0,3) -- (0,0) -- (4,0); +\node at (0.5,3) {MiTM}; +\draw [yellow] (0.3,3.2) rectangle (0.7,2.8); +\draw [->] (0.5,2.8) -- (1,2.25); +\node at (1.5,3) {Brute Force}; +\draw [yellow] (1.2,3.2) rectangle (1.8,2.8); +\draw [->] (1.5,2.8) -- (1,2.25); +\node at (2.5,3) {Social Engineering}; +\draw [yellow] (2.0,3.2) rectangle (3.0,2.8); +\draw [->] (2.5,2.8) -- (3,2.25); +\node at (3.5,3) {SW Vuln}; +\draw [yellow] (3.25,3.2) rectangle (3.75,2.8); +\draw [->] (3.5,2.8) -- (3,2.25); +\node at (1,2) {Break Encryption}; +\draw [orange] (0.55,2.25) rectangle (1.45,1.85); +\draw [->] (1,1.85) -- (2,1.2); +\node at (3,2) {Root Access}; +\draw [orange] (2.7,2.25) rectangle (3.3,1.85); +\draw [->] (3,1.85) -- (2,1.2); +\node at (2,1) {data}; +\draw [red] (1.8,1.2) rectangle (2.2,0.8); +\end{tikzpicture} +\caption{Illustrative Example of Attack Vector Tree} +\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? \begin{figure} \centering @@ -266,12 +300,32 @@ Security risk of an attack can be represented as a combination of the probabilit R = p_a * p_s * I \end{equation} -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. 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: \begin{equation} R = 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: + +\begin{equation} + p_a = 1 - e^{-(p_s*A - c_a)} +\end{equation} + +Thus the equation for determining security risk becomes: + +\begin{equation} \label{equ:expandedRisk} + 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 +\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} \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. @@ -327,7 +381,7 @@ weight_{anti-virus} * SM_{anti-virus} % Introduction to paper's Security Risk security This allows for a designer to now create some arbitrary metric to represent whether or not a given design is better or worse at meeting not only the requirements imposed but also in comparison to other available solutions to the same design problem. While this is a step in the right direction, there no units attached to the overall security metrics produced by the work of Ferrante et.~al. Without a proper unit attached to a generated metric, the entire process remains arbitrary and more difficult to be used in a relevant and meaningful manner. Calling back to the equation proposed in Section~\ref{sec:riskDefinition}, allow us to make use of the same techniques Ferrante et.~al.~developed but apply them in a more meaningful, cost-based manner. In this way it is possible for a `security risk' metric to be generated but also carry a recognizable worth. %instead of just an arbitrary number scheme. -But these values of cost must come from somewhere, and that is the purpose of the impact variable. This is because the impact is a representation of the potential loss caused by an event and the hours required to `repair' the problem; causing the unit of our security risk metric to become cost over time. +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. %\begin{multline} \label{equ:securityRisk} % `Security Risk' = Security Level * direct attacker probability * cost weight \\ @@ -338,20 +392,24 @@ But these values of cost must come from somewhere, and that is the purpose of th %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. -\begin{multline} \label{equ:estimationMetric} - Estimation Metric = -URT * SR + c_i + c_m + \frac{c_o}{w_r} -\end{multline} +\begin{equation} \label{equ:cost} + Costs = c_i + c_{si} + c_m + c_o +\end{equation} + +\begin{equation} \label{equ:estimationMetric} + Estimation Metric = \frac{SR+Costs}{w_r} +\end{equation} -Some of the values for this equation, 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 operational cost ($c_o$) is a value coming from a given individual or company; based on a monetary cost over time unit of measurement. +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. -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. +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. 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 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). +The aspiration 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. @@ -360,22 +418,22 @@ Now that aspects of this framework's verification and selection process have bee 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*}[] -\centering -\caption{Table illustrating different component variations} -\label{elementTypes} -\begin{tabular}{@{}llllll@{}} -\toprule -\multicolumn{6}{c}{Component Types Table} \\ \midrule -\multicolumn{1}{c}{\multirow{2}{*}{{\underline{\textbf{Elements}}}}} & \multicolumn{5}{c}{\textbf{Types}} \\ -\multicolumn{1}{c}{} & \multicolumn{1}{c}{{\underline{\textbf{I}}}} & \multicolumn{1}{c}{{\underline{ \textbf{II}}}} & \multicolumn{1}{c}{{\underline{\textbf{III}}}} & \multicolumn{1}{c}{{\underline{\textbf{IV}}}} & \multicolumn{1}{c}{{\underline{ \textbf{V}}}} \\ -Memory & Unprotected & Protected & Encrypted & Obfuscated & Combo \\ -Bus & Unprotected & Encrypted & Non-sniffable & & \\ -Processor & Simple & Embedded Encryption & Pure Encryption & & \\ -Data & Plain-text & Encryption & Protected & & \\ -Port & Normal & Encrypted & Protected & & \\ \bottomrule -\end{tabular} -\end{table*} +%\begin{table*}[] +%\centering +%\caption{Table illustrating different component variations} +%\label{elementTypes} +%\begin{tabular}{@{}llllll@{}} +%\toprule +%\multicolumn{6}{c}{Component Types Table} \\ \midrule +%\multicolumn{1}{c}{\multirow{2}{*}{{\underline{\textbf{Elements}}}}} & \multicolumn{5}{c}{\textbf{Types}} \\ +%\multicolumn{1}{c}{} & \multicolumn{1}{c}{{\underline{\textbf{I}}}} & \multicolumn{1}{c}{{\underline{ \textbf{II}}}} & \multicolumn{1}{c}{{\underline{\textbf{III}}}} & \multicolumn{1}{c}{{\underline{\textbf{IV}}}} & \multicolumn{1}{c}{{\underline{ \textbf{V}}}} \\ +%Memory & Unprotected & Protected & Encrypted & Obfuscated & Combo \\ +%Bus & Unprotected & Encrypted & Non-sniffable & & \\ +%Processor & Simple & Embedded Encryption & Pure Encryption & & \\ +%Data & Plain-text & Encryption & Protected & & \\ +%Port & Normal & Encrypted & Protected & & \\ \bottomrule +%\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} @@ -436,26 +494,39 @@ The next step is how to consider differences between the implementations of the %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 and would take one person about 8 man-hours to repair a failure; thus the $i$ for loss becomes \$20 per 8 man-hours. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name? +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. -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 and design per 40 man-hours, $c_m$ is taken to be \$50 in drive out cost per 4 man-hours to check the system, and $c_o$ is assumed to be \$3 in power costs per 12 hours of operation. The RW value is assumed to be 1.00 if the system is encrypted and 0.10 is not; since the effect of not meeting requirements can be 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. +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. +%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. + +%% Table showing the calculated security risk +%\begin{table}[] +%\centering +%\label{tabl:securityRisks} +%\begin{tabular}{|c|c|c|c|} +%\hline +% & \multicolumn{3}{c|}{Encryption Standard} \\ \cline{2-4} +% & AES256 & AES128 & None \\ \hline +%Security Risk & 0 & 2.73 & 15.84 \\ \hline +%\end{tabular} +%\caption{Calculated Security Risk for Wireless Transmitter} +%\end{table} % Please add the following required packages to your document preamble: -% \usepackage[normalem]{ulem} -% \useunder{\uline}{\ul}{} \begin{table}[] \centering -\label{tbl:estimationMetrics} -\begin{tabular}{|c|c|c|c|l} +\label{tabl:calculations} +\begin{tabular}{|c|c|c|c|} \hline - & \multicolumn{3}{c|}{User Risk Type} & \\ \cline{2-5} - & Risk Averse & Risk Neutral & Risk Seeking & \\ \hline -AES256 (MIPS) & 14.07 & 14.13 & 14.31 & \\ \cline{1-4} -AES128 (MIPS) & 14.12 & 14.21 & 14.52 & \\ \cline{1-4} -No Encryption & 16.94 & 17.50 & 19.38 & \\ \hline + & \multicolumn{3}{c|}{Encryption Standard} \\ \cline{2-4} + & AES256 & AES128 & None \\ \hline +Security Risk & 0 & 2.73 & 15.84 \\ \hline +Costs & 113 & 109 & 103 \\ \hline +Estimation Metric & 113 & 111.73 & 1188.40 \\ \hline \end{tabular} -\caption{Calculated Estimation Metrics for Wireless Transmitter (USD/man-hour)} +\caption{Calculated Values for Wireless Transmitter Example (Units USD)} \end{table} 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.