diff --git a/SecurityRiskPaper.tex b/SecurityRiskPaper.tex index 481b427..23d56ad 100644 --- a/SecurityRiskPaper.tex +++ b/SecurityRiskPaper.tex @@ -104,6 +104,7 @@ 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 @@ -353,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} @@ -368,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: @@ -386,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. This security risk metric, essentially, represents the calculated cost of a device over a lifetime. +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 + +\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{Generating Estimations} +\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. @@ -440,11 +449,11 @@ Some of the values for Equation~\ref{equ:cost}, implementation and maintenance c %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, this paper moves to show how this information can be used for a framework verification and selection process by applying these techniques to a simple 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 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 @@ -466,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}] @@ -500,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. @@ -514,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 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. 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? @@ -527,10 +543,12 @@ 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? +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. + for the {AES256, AES128, None} encryption implementations are {\$0, \$2.73, \$15.84} respectively. %% Table showing the calculated security risk %\begin{table}[] @@ -591,14 +609,14 @@ The cost per design, using costs from Table~\ref{tbl:partCosts}, from 1-{}-4, ar \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 +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} -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 indticating 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}. +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