Thus the equation for determining security risk becomes:

@@ -432,15 +436,17 @@ \section{Incorporating Risk into Design}

% and `estimation metric'

for any produced embedded system security modeling design.

% Note: Removed the c_{si} element from here to be used/referenced later for the comparison graphing

\begin{equation}\label{equ:cost}

Costs = c_i + c_{si} + c_m + c_o

Costs = c_i + c_m + c_o %+ c_{si}

\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.

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 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.

@@ -509,7 +515,7 @@ \section{Exploring a Simple Implementation}

% securityspecs::isTamperProof => false;

%end procbase.encryptembedded_i;

%\end{lstlisting}

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}.

The basic requirements are that any data that is transmitted must be protected. For our purposes, we assume that there are three possible hardware design solutions that exist of said transmitter, as shown in Figure~\ref{fig:exampleDesigns}. We then expand upon the first hardware design to create a total of five potential solutions for the wireless transmitter design.

%\begin{enumerate}

% \item Non-encrypted communication with a separate input and output buses.

% \item Encrypted communication with separate input and output buses.

@@ -518,19 +524,22 @@ \section{Exploring a Simple Implementation}

\caption{Design Implementations of Wireless Transmitter}

\label{fig:exampleDesigns}

\end{figure}

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

The five solutions instances compose of (1) a baseline system where there is no encryption, (2) simalr to design \#1 but with a software implementation of AES128, (3) same

hardware design as \#1 but with a software implementation of AES256, (4) a processor with a hardware implemented version of AES128, and (5) a processor with a hardware implementation of AES256.

%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 providing 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.

%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?

@@ -543,12 +552,12 @@ \section{Exploring a Simple Implementation}

%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. 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.

simplifications and assumptions to smooth the process. First we will take the assumption that there will be five separate implementations of encryption for the wireless transmitter: hardware AES256 (MIPS), hardware AES128 (MIPS), software AES256, software AES128, and no encryption. Drawing from the work by Ferrante et.~al.~, the corresponding security level (SL) values are {1.00, 0.60, 0.10} for {AES256, AES128, and no encryption}, 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. The weight values for the different implementations are {1.00, 0.40, 0.10} for {hardware encryption, software encryption, and no encryption}, 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, 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?

Now that we have values for SL and the weight variables, 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 HW, AES128 HW, AES256 SW, AES128 SW, None} encryption implementations are {\$0, \$6.92, \$12.00, \$15.20, \$19.80} respectively.

%% Table showing the calculated security risk

%\begin{table}[]

@@ -563,7 +572,9 @@ \section{Exploring a Simple Implementation}

%\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.

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;

@@ -575,15 +586,18 @@ \section{Exploring a Simple Implementation}

Antenna & 3 \\ \hline

IO Bus & 1 \\ \hline

Basic Processor & 15 \\ \hline

Pure Encryption & 20 \\ \hline

Modular Processor & 18 \\ \hline

Encryption Module & 8 \\ \hline

Encryption Processor (AES128) & 20 \\ \hline

Encryption Processor (AES256) & 21 \\ \hline

%Encryption Module & 8 \\ \hline

\end{tabular}

\caption{Table of Individual Part Costs}

\label{tbl:partCosts}

\end{table}

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.

The costs per design, using the individual costs from Table~\ref{tbl:partCosts}, are reflected in Table~\ref{tbl:calculations} for each variation of the wireless transmitter 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 %costs and security risk metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None}.

@@ -618,8 +632,6 @@ \section{Exploring a Simple Implementation}

@@ -633,26 +645,31 @@ \section{Exploring a Simple Implementation}

\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}.

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. The $c_{si}$ variable represents any cost due to implementing security aspects into the design relative to the base, no encryption, design. 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 5 of the wireless transmitter, one finds that the difference in costs is \$6; 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 \$6.06 then the additional security cost of \$6, for a full security design, becomes not only feasible but favorable. An illustration of this is shown in Figure~\ref{fig:SRvI}.

\caption{Comparison of Impact as a Function of Security Risk for Design \#1}

\label{fig:SRvI}

\end{figure}

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.

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. It is worth noting that in the previous example, there was an assumption that the $c_a$ would be uniform no matter the system being attacked. To further add to the potential complexity of these calculations, one could take into account that there should be different values of $c_a$ depending on the type of security measures implemented into a given design; influencing the probability of an attack occuring (i.e. $p_a$). 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}