diff --git a/SecurityRiskPaper.pdf b/SecurityRiskPaper.pdf new file mode 100644 index 0000000..c8640cb Binary files /dev/null and b/SecurityRiskPaper.pdf differ diff --git a/AADLSecPaper.tex b/SecurityRiskPaper.tex similarity index 85% rename from AADLSecPaper.tex rename to SecurityRiskPaper.tex index bfc4b9b..239a87d 100644 --- a/AADLSecPaper.tex +++ b/SecurityRiskPaper.tex @@ -104,17 +104,20 @@ select the most advantageous security design. \end{abstract} \section{Introduction} +\label{sec:intro} %AADL, like most modeling languages, must be able to describe not only the requirements of a system, but also the constraints, capabilities, and costs of various implementations and methods for the purpose of modeling a gamut of different designs. Coupling this already large space with security causes the considerations and influences on the problem to grow considerably. This paper will choose to examine the field of modeling embedded system security through the lens of the Architecture Analysis \& Design Language (AADL). Modeling security risk for use in systems design is a difficult problem that has not been thoroughly explored. To properly model security one has to account not only for the security requirements being imposed by a user, or organization, but also must account for the architectural components and their capabilities when designing a best-fit solution to a given security concern. The security requirements can range from such vague concepts as ``my data must remain secure'' to more concrete requirements of ``this specific communication standard must be used''. Each requirement is capable of being implemented in a variety of manners and methods. These differences are further defined by the architectural components and their capabilities. Elements ranging from time spent to complete a given task, power consumption rate, heat radiated over time, and size, or area, that a given component will require on a printed circuit board (PCB). To further complicate matters, one must take these opposing aspects of the system design process, represent them using meaningful metrics that can be calculated from some deterministic information, and then compare and contrast generated solutions for implementing the most favorable variation of produced embedded systems security model. Fortunately there are methodologies and techniques %(e.g. Platform Based Design) -that aid in the development and improvement of security modeling approaches. For example, Platform-based design~\cite{Vincentelli2007} is a prime example of how one can take the functional space (including security requirements) and the architectural space (components and capabilities) and develop a mapping function that can produce solutions to a given design problem. As shown in Figure~\ref{fig:recursivePBD}, one can then take the mapped solution and use this as the new functional (or architectural) space for the next iteration of solution mapping. +that aid in the development and improvement of security modeling approaches. For example, Platform-based design~\cite{Vincentelli2007} is a prime example of how one can take the functional space (including security requirements) and the architectural space (components and capabilities) and develop a mapping function that can produce solutions to a given design problem. +%As shown in Figure~\ref{fig:recursivePBD}, +One can then take the mapped solution and use this as the new functional (or architectural) space for the next iteration of solution mapping. -\begin{figure} - \includegraphics[height=6.5cm,width=\textwidth]{./images/recursivePBD.png} - \caption{Visualization of Recursive PBD Model~\cite{Vincentelli2007}} - \label{fig:recursivePBD} -\end{figure} +%\begin{figure} +% \includegraphics[height=6.5cm,width=\textwidth]{./images/recursivePBD.png} +% \caption{Visualization of Recursive PBD Model~\cite{Vincentelli2007}} +% \label{fig:recursivePBD} +%\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 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 @@ -284,7 +287,8 @@ Ideally embedded system security modeling should have more deterministic interpr \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). +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 @@ -350,7 +354,7 @@ First, we modify the traditional risk model (Eq.~\ref{equ:riskDefinition}) to re 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} +\begin{equation} \label{equ:attackRisk2} SR = p_a * (1 - SM) * I \end{equation} @@ -365,8 +369,8 @@ aggregate $A$ with weighted assignments due to different attackers. First, we n 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 +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 $p_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: @@ -383,17 +387,25 @@ Thus the equation for determining security risk becomes: 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} +\begin{equation} {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. Using the substitution for $p_s$ in Eq.~\ref{equ:attackRisk2}, we get -\section{Generating an Estimation Metric} +\begin{equation} \label{equ:aggregatedRisk} + {SR}_i = \sum\limits_{j=0}^K (1 - e^{-((1-SM_{ij})*A_i - c_{a_{ij}})})*(1-SM_{ij})*I_i +\end{equation} + +Thus, Equation~\ref{equ:aggregatedRisk} represents the aggregation of all contributing attack vectors towards the potential compromise of a specific +system asset. This security risk metric, essentially, represents the expected security cost of a device over a lifetime. + +\section{Incorporating Risk into Design} \label{sec:framework} -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. +Now that we have presented a meaningful manner of representing security risk as a metric, we move to show that +how to use this risk metric in embedded system design. %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: +In Section~\ref{sec:intro}, we introduced a security design framework that allows for generation of embedded system security models by assuming that the security requirements and architectural component capabilities can be represented in a quantitative manner. With the framework, shown in Figure~\ref{fig:AADLSecFrame}, one can take the risk equations developed in Section~\ref{sec:riskDefinition} and produce a meaningful metric estimation that can be used to compare and contrast varying security model solutions. Combination of the framework's verification process and the risk equations developed is done in the following manner: \begin{enumerate} \item Define the security requirements and architectural components in a numerically meaningful manner. \item Take these unit-less metrics and apply a `conversion equation' to them in order to produce a meaningful, `monetary unit' based metric. @@ -412,15 +424,21 @@ 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 equations to calculate an overall cost and `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 equation 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 \end{equation} -\begin{equation} \label{equ:estimationMetric} - Estimation Metric = SR+Costs -\end{equation} +%\begin{equation} \label{equ:estimationMetric} +% Estimation Metric = SR+Costs +%\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. @@ -429,11 +447,13 @@ Some of the values for Equation~\ref{equ:cost}, implementation and maintenance c %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 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. +%Now that aspects of this framework's verification and selection process have been explained, allow us to apply these techniques to a sample example. + +Now that two equations have been proposed, one for security risk and one for costs, we move to show how this information can be used for a framework verification and selection process by applying these techniques to a simple example. \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. +We now introduce a simple example of a verification and selection process to produce a meaningful 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 @@ -455,7 +475,7 @@ This paper now moves to showing a simple implementation of the security framewor %\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. +The simple example that we 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}] @@ -489,7 +509,7 @@ The simple example that this paper will examine is that of a wireless transmitte % securityspecs::isTamperProof => false; %end procbase.encryptembedded_i; %\end{lstlisting} -In this example, the paper assumes that there are four variations that exist of said transmitter, as shown in Figure~\ref{fig:exampleDesigns}. +The basic requirements are that any data that is transmitted must be protected. For our purposes, we assume that there are four possible design solutions that exist of said transmitter, as shown in Figure~\ref{fig:exampleDesigns}. %\begin{enumerate} % \item Non-encrypted communication with a separate input and output buses. % \item Encrypted communication with separate input and output buses. @@ -503,7 +523,14 @@ In this example, the paper assumes that there are four variations that exist of \label{fig:exampleDesigns} \end{figure} -The four instances of a single possible solution being generated based on two aspects of the architectural space: (1) the number of IO buses available and (2) whether or not communication should be encrypted. To further simplify the considerations of this example, the paper chooses to ignore the influence of IO bus variation and focus on the implementation, or lack of, encryption. In this manner, the examination goes from four variations to two variations (encryption enabled or disabled). To better pad out this encryption scenario we choose to examine the wireless transmitter under use of an optimal AES256 encryption algorithm using a MIPS processor, the `good enough' use of AES128 encryption algorithm also on MIPS architecture, and a complete lack on implementation of encryption. It is worth noting that while in theory having no encryption should cause for the lowest values possible (0.00) but in order to show the effect of these elements this paper assumes the lowest value obtainable is 0.10. +The four solutions instances compose of (1) a baseline system where there is no encryption, (2) a processor +with built-in encryption, (3) a processor with built-in encryption and two communication channels, and (4) a +basic processor with software encryption and two communication channels. In these design choices, we envision +that the second channel allows for the creation of a separate pathway for encrypted data that may be difficult +for attackers to probe. Likewise, the processors with built-in encryption are more difficult for attackers to +probe and retrieve encryption keys, thus provide more security at some extra cost +%, of a single possible solution being generated based on two aspects of the architectural space: (1) the number of IO buses available and (2) whether or not communication should be encrypted. +To further simplify the requirement considerations of this example, the paper chooses to ignore the influence of IO bus variation and focus on the implementation, or lack of, encryption. In this manner, the examination goes from four variations to two variations (encryption enabled or disabled). To better pad out this encryption scenario we choose to examine the wireless transmitter under use of an optimal AES256 encryption algorithm using a MIPS processor, the `good enough' use of AES128 encryption algorithm also on MIPS architecture, and a complete lack on implementation of encryption. %For the sake of simplicity, this paper makes use of the `relativity matrix' developed by Ferrante et.~al.~\cite{Ferrante2013} for representing the security level metrics on the encryption standards used. %How does one create the security metric based on the given example? @@ -516,22 +543,25 @@ These different aspects can be compared by assigning weights for allowing relati %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$), 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 shown in Table~\ref{tbl:securityRisks}. -% for the {AES256, AES128, None} encryption implementations are {0, 2.73, 15.84} respectively. - -% Table showing the calculated security risk -\begin{table}[] -\centering -\label{tbl: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} +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. It is worth noting that while in theory having no encryption should cause for the lowest values possible (0.00) but in order to show the effect of these elements this paper assumes the lowest value obtainable is 0.10. +%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, 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 +%shown in Table~\ref{tbl:securityRisks}. + for the {AES256, AES128, None} encryption implementations are {\$0, \$2.73, \$15.84} respectively. + +%% Table showing the calculated security risk +%\begin{table}[] +%\centering +%\label{tbl: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} 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 an aggregation of the individual cost of parts. @@ -556,7 +586,7 @@ Encryption Module & 8 \\ \hline The cost per design, using costs from Table~\ref{tbl:partCosts}, from 1-{}-4, are {19,28,24,34}, respectively. $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:calculations} which represents the calculated costs and security risk metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None}. +%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 %costs and security risk metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None}. % and how different User Risk Types (URT) also further influence the metric. %% Please add the following required packages to your document preamble: @@ -574,50 +604,88 @@ Taking the calculation of the estimation metric (EM) from Equation~\ref{equ:esti %\caption{Calculated Values for Wireless Transmitter Example (Units USD)} %\end{table} +%\begin{table}[] +%\centering +%\begin{tabular}{|c|c|c|c|c|} +%\hline +% & Design 1 & Design 2 & Design 3 & Design 4 \\ \hline +%Costs & \$72 & \$91 & \$88 & \$93 \\ \hline +%Security Risk & \$15.84 & \$0 & \$0 & \$2 \\ \hline +%\end{tabular} +%\caption{Calculated Values for Wireless Transmitter Example (Units USD)} +%\label{tbl:calculations} +%\end{table} + \begin{table}[] \centering -\begin{tabular}{|c|c|c|c|c|} +\caption{My caption} +\label{my-label} +\begin{tabular}{|c|c|c|c|c|c|} \hline - & Design 1 & Design 2 & Design 3 & Design 4 \\ \hline -Costs & 72 & 91 & 88 & 93 \\ \hline -Security Risk & 15.84 & 0 & 0 & 2 \\ \hline + & \textbf{Design 1} & \textbf{Design 2} & \textbf{Design 3} & \textbf{Design 4} & \textbf{Design 5} \\ \hline +\textbf{SM} & 0.01 & 0.24 & 0.40 & 0.60 & 1.00 \\ \hline +\textbf{$p_s$} & 0.99 & 0.76 & 0.60 & 0.40 & 0.00 \\ \hline +\textbf{$p_a$} & 0.99 & 0.99 & 0.99 & 0.86 & 0.00 \\ \hline +\textbf{SR} & \$19.80 & \$15.20 & \$12.00 & \$6.92 & \$0.00 \\ \hline +\textbf{Costs} & \$19.00 & \$19.00 & \$19.00 & \$24.00 & \$25.00 \\ \hline \end{tabular} -\caption{Calculated Values for Wireless Transmitter Example (Units USD)} +\caption{Calculated Values for Wireless Transmitter Example} \label{tbl:calculations} \end{table} + +From these produced numbers, a developer can apply further constraints to the design selection process by mandating that costs be kept below a certain level while minimizing security risk or vice versa. For example, a development team could compare how a growth in the impact ($I$) value changes the cost value reflected by the security risk (Equation~\ref{equ:expandedRisk}) metric. Ideally a developer is looking for the point where as $I$ grows, the value of $SR$ should cross the $c_{si}$ threshold, thus indicating that the cost of additional security is warranted. In the case of comparing designs 1 and 2 of the wireless transmitter, one finds that the difference in costs is \$9; taken to be the $c_{si}$ threshold. Using the values for Design 1 of the wireless transmitter, one finds that the once the $I$ value becomes \$11.25 then the additional security cost of \$9, for a full security design, becomes not only feasible but favorable. An illustration of this is shown in Figure~\ref{fig:SRvI}. + +\begin{figure} +\centering +\begin{tikzpicture}[xscale=0.5,yscale=0.2] +\draw [<->] (0,11) -- (0,0) -- (13,0); +\node [left] at (0,11) {$SR$}; +\node [below right] at (13,0) {$I$}; +\draw [dashed, gray] (0,9) -- (13,9); +\node [left] at (0,9) {\$9}; +\draw [domain=0:13] plot (\x, {0.7999999*\x}); +%\node [left] at (0,0) {0}; +\draw [dashed, lightgray] (11.25, 0) -- (11.25, 11); +\node [below] at (11.25,0) {\$11.25}; +\end{tikzpicture} +\caption{Comparison of Impact as a Function of Security Risk for Design \#1} +\label{fig:SRvI} +\end{figure} -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. +While both the values of the costs and security risk equations produce a dollar-unit metric, they are not immediately combinable as some costs are representative of life-time costs while others incorporate more immediate costs of a design. For this reason, a pairing of security risk and cost are used to determine the favorability of a given design in comparison of other design choices. 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. \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. -\begin{lstlisting}[caption={User-defined Higher Level Security Requirement},label={lst:AADLUserDefineHigh}] -abstract implementation sysreq.wireless_sensor_i - subcomponents - serv_ADConv: abstract sysserv.ADConv_i { - servatrb::dynamicRange => 0..5 V; - secatrb::integrity::atkImpact => 300; - }; - serv_wrlsTrans: abstract sysserv.wrlsTrans_i { - servatrb::distance => 100 m; - secatrb::authentication::atkValue => 600; - secatrb::authentication::atkImpact => 400; - secatrb::authorization::atkImpact => 1200; - secatrb::dataleakage::atkImpact: => 800; - secatrb::dataleakage::atkValue: => 800; - }; - fnc_data: abstract security_props.data_i { - dataatrb::data_class => Sensor; - secatrb::atkImpact => 800; - properties - secatrb::hasProtection => false; - secatrb::AuthGroup => Employees; -end sysreq.wireless_sensor_i; -\end{lstlisting} - -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(e.g. Figure~\ref{fig:attackTree}), 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. +%\begin{lstlisting}[caption={User-defined Higher Level Security Requirement},label={lst:AADLUserDefineHigh}] +%abstract implementation sysreq.wireless_sensor_i +% subcomponents +% serv_ADConv: abstract sysserv.ADConv_i { +% servatrb::dynamicRange => 0..5 V; +% secatrb::integrity::atkImpact => 300; +% }; +% serv_wrlsTrans: abstract sysserv.wrlsTrans_i { +% servatrb::distance => 100 m; +% secatrb::authentication::atkValue => 600; +% secatrb::authentication::atkImpact => 400; +% secatrb::authorization::atkImpact => 1200; +% secatrb::dataleakage::atkImpact: => 800; +% secatrb::dataleakage::atkValue: => 800; +% }; +% fnc_data: abstract security_props.data_i { +% dataatrb::data_class => Sensor; +% secatrb::atkImpact => 800; +% properties +% secatrb::hasProtection => false; +% secatrb::AuthGroup => Employees; +%end sysreq.wireless_sensor_i; +%\end{lstlisting} + +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(e.g. Figure~\ref{fig:attackTree}), 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). @@ -656,10 +724,9 @@ users that treat security with a laissez-faire attitude). This would allow for %\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. +%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. %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.