added alpha term to exponential model

replaced SM with SL
some other minor edits

SecurityRiskPaper.tex

@@ -257,8 +257,12 @@ w_{anti-virus} * SM_{anti-virus} + w_{firewall} * SM_{firewall} + {...} + w_{ele
 % Introduction to paper's Security Risk security
 This allows for a designer to now create some arbitrary metric to represent whether or not a given design is better or worse at meeting not only the requirements imposed but also in comparison to other available solutions to the same design problem.  While this is a step in the right direction, there no units attached to the overall 
 security metrics produced by this work.  Without a proper unit attached to a generated metric, the entire process remains arbitrary and more difficult to use in a relevant and meaningful manner.  %Calling back to the equation proposed in Section~\ref{sec:riskDefinition}, allow us 
-This paper moves to make use of the same techniques Ferrante et.~al.~developed but apply them in a more meaningful, cost-based manner.  In this way it is possible for a `security risk' metric to be generated but also carry a recognizable worth. %instead of just an arbitrary number scheme.  
-But these values of cost must come from somewhere, and that is the purpose of the impact variable.  This is because the impact is a representation of the potential loss caused by an event.
+We make use of the same techniques Ferrante et.~al.~developed but apply them in a more meaningful, cost-based 
+manner.  Thus, instead of focusing on an arbitrary security metric (SM), we focus instead on the security level 
+(SL) which can serve as a useful approximation of the probability that an attacker can defeat a particular 
+security feature.   In this way it is possible for a `security risk' metric to be generated but also carry a 
+recognizable worth. %instead of just an arbitrary number scheme.  
+However, these values of cost must come from somewhere, and that is the purpose of the impact variable.  This is because the impact is a representation of the potential loss caused by an event.
 
 % Trouble when incorporating security into risk calculations
 Different methods by which security can be incorporated into risk management include: as a weight representing implementation of security solutions, as a probability that a security concern is met or attacked, the 
@@ -352,10 +356,10 @@ First, we modify the traditional risk model (Eq.~\ref{equ:riskDefinition}) to re
 	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.  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:
+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 level (SL) value discussed earlier.  This alters Equation~\ref{equ:attackRisk} to become:
 
 \begin{equation} \label{equ:attackRisk2}
-	SR = p_a * (1 - SM) * I
+	SR = p_a * (1 - SL) * I
 \end{equation}
 
 
@@ -371,34 +375,32 @@ probability of an attack.  In other words, one would expect that as the expected
 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 $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:
+time that the $p_s*A$ aspect become meaningful.  The relationship between the expected attack
+value and $p_a$ is not well defined and further study is needed to determine an accurate model.  For the purposes of this paper, we suggest an exponential relationship 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:
-
 \begin{equation}
 	p_a = 
 	\begin{cases} 
-	1 - e^{-(p_s*A - c_a)},& 	\quad\text{if } p_s*A \geq c_a \\
+	1 - e^{-\alpha(p_s*A - c_a)},& 	\quad\text{if } p_s*A \geq c_a \\
 	0,&				\quad\text{otherwise}
 	\end{cases}
 \end{equation}
-
-Thus the equation for determining security risk becomes:
+where $\alpha$ captures the sensitivity of $p_a$ to the expected attack value.  In our example in Section~\ref{sec:simpleExample}, we assume that $\alpha=1$.  Determination of appropriate values of $\alpha$ is dependent on the particulars of an attack scenario.
+Incorporating into Eq.~\ref{equ:attackRisk}, the equation for determining security risk becomes:
 
 \begin{equation} \label{equ:expandedRisk}
-	SR = (1 - e^{-(p_s*A - c_a)})*p_s*I
+	SR = (1 - e^{-\alpha(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} 
-	{SR}_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^{-\alpha(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. 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
+	{SR}_i = \sum\limits_{j=0}^K (1 - e^{-\alpha((1-SL_{ij})*A_i - c_{a_{ij}})})*(1-SL_{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 
@@ -529,15 +531,15 @@ The basic requirements are that any data that is transmitted must be protected.
 	\label{fig:exampleDesigns}
 \end{figure}
 
-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 
+The five solutions instances compose of (1) a baseline system where there is no encryption, (2) similar 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
+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.  
 %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.
@@ -552,9 +554,9 @@ 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 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.
+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 mean 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.  Similarly, we assume the SL 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 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?
+Now that we have SL values for the encryption algorithm and the implementation approach, we can determine an overall SL value by multiplying the two SL values because of their serial dependence.  In order to arrive at an overall risk metric (SR), we must first 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 HW, AES128 HW, AES256 SW, AES128 SW, None} encryption implementations are {\$0, \$6.92, \$12.00, \$15.20, \$19.80} respectively.
@@ -635,7 +637,7 @@ $c_m$ is taken to be \$50 in drive out cost, and $c_o$ is assumed to be \$3 in o
 \begin{tabular}{|c|c|c|c|c|c|}
 \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{SL}    & 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
@@ -729,7 +731,7 @@ Complications of this examination range from simple questions, such as how does
 
 % 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 tolerant users would not only allow for riskier designs but would also be willing to tolerate low probabilities of high loss.  Likewise, risk averse users would lead to development of less risky designs that also limit the maximum potential loss.
+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 tolerant users would not only allow for riskier designs but would also be willing to tolerate low probabilities of high loss.  Likewise, risk averse users would lead to development of less risky designs that also limit the maximum potential loss.
 
 %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.