diff --git a/AADLSecPaper.tex b/AADLSecPaper.tex index b1ae90a..0826743 100644 --- a/AADLSecPaper.tex +++ b/AADLSecPaper.tex @@ -339,13 +339,13 @@ Since the traditional view of risk does not account for an attacker's motivation Security risk of an attack can be represented as a combination of the probability of an attack ($p_a$), probability of the attack succeeding ($p_s$), and the impact of the attack. \begin{equation} \label{equ:attackRisk} - R = p_a * p_s * I + 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: \begin{equation} - R = p_a * (1 - SM) * I + 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: @@ -357,16 +357,16 @@ One should note that as $p_s*A$, which is the probability of success multiplied Thus the equation for determining security risk becomes: \begin{equation} \label{equ:expandedRisk} - R = (1 - e^{-(p_s*A - c_a)})*p_s*I + SR = (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 + {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} @@ -398,15 +398,15 @@ Additional aspects that must be taken into account include costs of implementing \end{equation} \begin{equation} \label{equ:estimationMetric} - Estimation Metric = \frac{SR+Costs}{w_r} + 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. -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 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). +%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 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. @@ -434,40 +434,40 @@ 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. Listing~\ref{lst:AADLUserDefineLow} shows the AADL user-defined description of the wireless transmitter element being discussed. This paper makes use of AADL to aid in modeling embedded systems with security properties and constraints for giving a practical example of our proposed adversarial risk-based approach to embedded systems security modeling. AADL has a large and active community that works towards development and improvement of new annexes or other extensions to the existing AADL lexicon. In addition to the ease of extensibility, AADL is an easy language to pick up and learn. This paired with the way in which AADL has been intuitively built, allows for ease of extension by other users or even the community at large.~\cite{AADLV2Overview} - -\begin{lstlisting}[caption={Example of User-defined Lower Level Components},label={lst:AADLUserDefineLow}] -system implementation transmitter.encrypt_i - -- Subcomponents of the transmitter - subcomponents - ant_in : system recv_antenna.normal_i; - ant_out : system trns_antenna.encrypt_i; - encrproc : processor procbase.encryptembedded_i; - -- Connection definitions of the transmitter - connections - c0 : port ant_in.wired_out -> encrproc.input_port; - c1 : port encrproc.output_port -> ant_out.wired_in; - -- Flow path definition for the transmitter - flows - f0 : end to end flow ant_in.f0 -> c0 -> encrproc -> c1 -> ant_out.f0; - -- Additional properties of the transmitter - properties - securityspecs::has_encryption => true; -end transmitter.encrypt_i; - -processor implementation procbase.encryptembedded_i - properties - securityspecs::has_encryption => true; - securityspecs::encryptmodule_class => embedded; - securityspecs::encryption_class => AES; - securityspecs::encryption_variation => b256; - securityspecs::has_PUF => false; - securityspecs::has_TPM => false; - securityspecs::has_encryptedflash => false; - securityspecs::isTamperProof => false; -end procbase.encryptembedded_i; -\end{lstlisting} - +The simple example that this paper will examine is that of a wireless transmitter. +%Listing~\ref{lst:AADLUserDefineLow} shows the AADL user-defined description of the wireless transmitter element being discussed. This paper makes use of AADL to aid in modeling embedded systems with security properties and constraints for giving a practical example of our proposed adversarial risk-based approach to embedded systems security modeling. AADL has a large and active community that works towards development and improvement of new annexes or other extensions to the existing AADL lexicon. In addition to the ease of extensibility, AADL is an easy language to pick up and learn. This paired with the way in which AADL has been intuitively built, allows for ease of extension by other users or even the community at large.~\cite{AADLV2Overview} +% +%\begin{lstlisting}[caption={Example of User-defined Lower Level Components},label={lst:AADLUserDefineLow}] +%system implementation transmitter.encrypt_i +% -- Subcomponents of the transmitter +% subcomponents +% ant_in : system recv_antenna.normal_i; +% ant_out : system trns_antenna.encrypt_i; +% encrproc : processor procbase.encryptembedded_i; +% -- Connection definitions of the transmitter +% connections +% c0 : port ant_in.wired_out -> encrproc.input_port; +% c1 : port encrproc.output_port -> ant_out.wired_in; +% -- Flow path definition for the transmitter +% flows +% f0 : end to end flow ant_in.f0 -> c0 -> encrproc -> c1 -> ant_out.f0; +% -- Additional properties of the transmitter +% properties +% securityspecs::has_encryption => true; +%end transmitter.encrypt_i; +% +%processor implementation procbase.encryptembedded_i +% properties +% securityspecs::has_encryption => true; +% securityspecs::encryptmodule_class => embedded; +% securityspecs::encryption_class => AES; +% securityspecs::encryption_variation => b256; +% securityspecs::has_PUF => false; +% securityspecs::has_TPM => false; +% securityspecs::has_encryptedflash => false; +% 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}. %\begin{enumerate} % \item Non-encrypted communication with a separate input and output buses. @@ -496,36 +496,51 @@ These different aspects can be compared by assigning weights for allowing relati 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 for the {AES256, AES128, None} encryption implementations are {0, 2.73, 15.84} respectively. +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. -From this point, we make further assumptions about the implementation cost ($c_i$), security implementation cost ($c_{si}$), the maintenance cost ($c_m$), and operational cost ($c_o$) since these values would come from metrics internal to a company or organization. $c_i$ is taken to be \$50 in parts, $c_{si}$ is taken to be \$10 for AES256 and \$6 for AES128, $c_m$ is taken to be \$50 in drive out cost, and $c_o$ is assumed to be \$3 in operative power costs. +% 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. The costs assumed are \$3 per antenna, \$1 per IO bus, \$15 for a basic processor, \$20 for an encryption optimized processor, \$18 for processor that works with embedded technology, and \$8 for an encryption module; cost per design, 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 security risk, costs, and estimation metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None} and how different User Risk Types (URT) also further influence the metric. +%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 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 +%% Please add the following required packages to your document preamble: %\begin{table}[] %\centering -%\label{tabl:securityRisks} +%\label{tabl:calculations} %\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 +% & \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 Security Risk for Wireless Transmitter} +%\caption{Calculated Values for Wireless Transmitter Example (Units USD)} %\end{table} -% Please add the following required packages to your document preamble: \begin{table}[] \centering -\label{tabl:calculations} -\begin{tabular}{|c|c|c|c|} +\label{tbl:calculations} +\begin{tabular}{|c|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 -Costs & 113 & 109 & 103 \\ \hline -Estimation Metric & 113 & 111.73 & 1188.40 \\ \hline + & Design 1 & Design 2 & Design 3 & Design 4 \\ \hline +Costs & 72 & 91 & 88 & 93 \\ \hline +Estimation Metric & 87.84 & 91 & 88 & 95.73 \\ \hline \end{tabular} \caption{Calculated Values for Wireless Transmitter Example (Units USD)} \end{table} @@ -533,7 +548,9 @@ Estimation Metric & 113 & 111.73 & 1188.40 \\ \hline Now that a simple example has been shown, allow this paper to now expand the considerations that are made for this simplistic example. The following section will examine further expansion of `estimation metric' considerations, showing how the calculation of comparable metrics can become more involved and complicated. \subsection{Expanding Considerations} -Despite the efforts to simplify the embedded system security modeling problem, there are a plethora of additional variables that can be taken into consideration depending on the environment and user, or company, at risk. When calculating the estimated cost metrics used for making larger system design decisions, one ideally accounts for as many aspects of the system as possible. When dealing with the constrained domain of embedded systems, this is doubly so. Physical costs of the system carry a heavy weight when making choices about design implementations. Power costs, heat generated, run time, area requirement, etc. are all aspects that must be considered. When incorporating software, the assumption of this paper is that software has been designed correctly with no error or malicious behavior embedded within. To that case, this means that when comparing software implementations, the main considerations of the developer are run time, bits used (in the case of encryption and authentication), and power consumed (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. +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}. @@ -546,18 +563,21 @@ There can also be additional considerations that come about due to how probabili Complications of this examination range from simple questions, such as how does one measure exposure of an element, to more complicated concerns, such as how does one rank known vulnerabilities or how can one be aware of all vulnerabilities within a system. %As such, this is perhaps not the best equation for producing an overall system metric, but may play a role in a more bounded examination. -%% Explination of User Risk Type -%`User risk type' (URT) comes from a business minded examination of risk~\cite{Mukhopadhyay2013} where users can be averse to risk, risk seeking, or risk neutral. The purpose of this variable is a method of representing different users of secure systems that exist within the real-world (e.g. users that are over protective and -%users that treat security with a laissez-faire attitude). The User Risk Type should produce a lower value if a user is risk averse and a larger value if a given user is risk seeking. In this way, User Risk Type should `negatively' affect the cost of the system as more risk prone individuals become the user. +% 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. -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} +%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. -\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. +%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} @@ -588,7 +608,7 @@ abstract implementation sysreq.wireless_sensor_i 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, 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. +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).