in examinations. The obvious implications of adding security are the need to account for impacts of

loss (risk) and accounting for the ensuing increased design costs. The considerations that are not

traditionally examined are those of the adversary and the defender of a given system. Without accounting for

the view point of the individuals interacting with any secure embedded system design, on can not verify and

the view point of the individuals interacting with any secure embedded system design, one can not verify and

select the most advantageous security design.

\keywords{security modeling, security framework, secure system design}

\end{abstract}

@@ -189,7 +189,7 @@ \section{Defining Risk}

% Differences can occur when assessing risk depending on the point of view of the individual

Summarizing, risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact. Complications in

security risk identification can come from a lack of experience and standards or due to the evolution of a system. The first comes the fact that defining `security risk' is still novel and does not have standardized procedures for dealing within the cyber-modeling domain. The second issue originates from the fact that computer systems evolve quickly over time. The system within an organization can change quickly with new technologies appear very often; changing the landscape of `cyber risks' and other cyber-domain concerns. Risk can be assessed differently based on how it is examined. Depending on where uncertainties originate from, how impacts of actions are measured, and how these variables interact with each other, different variations of risk equations can be developed. To further complicate possible risk calculations, the equation for interpreting risk can differ based on the role of the individual measuring said risk. What may be a calculated risk to a defender, could prove to be advantageous to an attacker by causing less risk of being observed or even allow for

security risk identification can come from a lack of experience and standards or due to the evolution of a system. The first comes the fact that defining `security risk' is still novel and does not have standardized procedures for dealing within the cyber-modeling domain. The second issue originates from the fact that computer systems evolve quickly over time. The system within an organization can change quickly with new technologies appearing very often; changing the landscape of `cyber risks' and other cyber-domain concerns. Risk can be assessed differently based on how it is examined. Depending on where uncertainties originate from, how impacts of actions are measured, and how these variables interact with each other, different variations of risk equations can be developed. To further complicate possible risk calculations, the equation for interpreting risk can differ based on the role of the individual measuring said risk. What may be a calculated risk to a defender, could prove to be advantageous to an attacker by causing less risk of being observed or even allow for

less risky attacks to be performed against a system. Another example would be that heavy security

implementation may cause a larger risk value for an attacker, but would produce a minimal risk value for the

defender of the same system. Further examination of attack and defense considerations will be continued in

@@ -204,7 +204,7 @@ \section{Defining Risk}

% 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

possibility of a security failure, etc. Given all these variations, how can one define security in a meaningful and relatively deterministic manner? The first part that needs to be tackled is why is `relatively' good enough for this security metric? The reason that a degree of `relativity' is required for developing a security metric, is that security changes and evolves over time, meaning that the algorithms and methodologies will transform and improve over time. This change means that the measurement for security must remain important relative to the existing security solution space. The reason that this value can not be fully deterministic is that security is constantly progressing and improving, meaning that any deterministic nature in the calculation of a security metric must also account for this change over time. Ideally embedded system security modeling should have more deterministic interpretation of generated security solutions, but at the current point this is not realistically achievable. Security levels can also be interdependent depending on implementation and scenario/situation.

possibility of a security failure, etc. Given all these variations, how can one define security in a meaningful and relatively deterministic manner? The first part that needs to be tackled is why is `relatively' good enough for this security metric? The reason that a degree of `relativity' is required for developing a security metric, is that security changes and evolves over time, meaning that the algorithms and methodologies will transform and improve over time. This change means that the measurement for security must remain important relative to the existing security solution space. The reason that this value can not be fully deterministic is that security is constantly progressing and improving, meaning that any deterministic nature in the calculation of a security metric must also account for this change over time. Ideally embedded system security modeling should have more deterministic interpretations of generated security solutions, but at the current point this is not realistically achievable. Security levels can also be interdependent depending on implementation and scenario/situation.

The purpose of this paper is to propose a method for combining security and risk in a measurable and meaningful manner. Taking the already defined risk equation (i.e. Equation~\ref{equ:riskDefinition}), we move to add in the existence of a `security metric' and `cost weight' to the probability that either a direct or an indirect attack occurs to a given system.

@@ -217,7 +217,7 @@ \section{Defining Risk}

chance of how exactly an attack will occur. $w_c$ is the cost weight, i.e. the weight assigned to the cost of

the system. %XXX is this the right definition of cost weight?

$p_{da}$ represents the probability of a direct attack, where direct attack is defined as an event where an

attacker directly attempts to brute force a given security mechanism or standard. $p_{da}$ represents the

attacker directly attempts to brute force a given security mechanism or standard. $p_{ida}$ represents the

probability of an indirect attack, where an indirect attacker is one where a malicious user attempts to circumvent existing security by some aspect that is not directly related to the mentioned security implementation.

%XXX What is the definition of security metric in the equation?

Once risk has been defined in the scope/lens of examination, one can move develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `value'/`worth' of any given design. However, before these metrics can be developed, one must first determine a framework by which these calculations will be incorporated to allow for a relevant and meaningful interpretation of verification and selection metrics.

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

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 cost weight ($w_c$), direct attack probablity ($p_{da}$), and indirect attack probability ($p_{ida}$). For the $w_c$ value we make the assumption that some company may find that the data collected by this wireless transmitter is worth \$20 if lost and would take one person about 8 man-hours to repair a failure; thus the $w_c$ for loss becomes \$20 per 8 man-hours. % XXX is the cost weight really the impact? Should you use impact or $i$ as the variable name?

As for the attack probabilities, this paper assumes that attacking any other wireless transmitter (indirect attack) would be the same as attacking a chosen wireless transmitter and that attacking a central aggregation computer would be out of scope for this example, therefore the indirect attack probability can be taken as 0\%. Assuming that an employee has a less than enthusiastic installation of the transmitter, the $p_{da}$ value is taken to be 25\% chance of an adversary brute forcing encryption to see the transmitted data. Using Equation~\ref{equ:riskDefinition}, one finds that the SR values for the {AES256, AES128, None} encryption implementations are {0.625, 1.04, 6.25} respectively.

From this point, we make further assumptions about the implementation cost ($c_i$), the maintenance cost ($c_m$), and `solution metric'/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 and design per 40 man-hours, $c_m$ is taken to be \$50 in drive out cost per 4 man-hours to check the system, and $c_o$ is assumed to be \$3 in power costs per 12 hours of operation. The RW 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 view more clearly. Taking the calculation of the estimation metric (EM) from Equation~\ref{equ:estimationMetric}, we produce the contents of Table~\ref{tbl:estimationMetrics} which represents the estimation metric for each encryption scenario {AES256 (MIPS), AES128 (MIPS), None} and how different User Risk Types (URT) also further influence the metric.

From this point, we make further assumptions about the implementation cost ($c_i$), the maintenance cost ($c_m$), and `solution metric'/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 and design per 40 man-hours, $c_m$ is taken to be \$50 in drive out cost per 4 man-hours to check the system, and $c_o$ is assumed to be \$3 in power costs per 12 hours of operation. The RW 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:estimationMetrics} which represents the estimation 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: