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

methodologies and techniques %(e.g. Platform Based Design)

that aid in the development and improvement of security modeling approaches. For example, Platform-based design~\cite{Vincentelli2007} is a prime example of how one can take the functional space (including security requirements) and the architectural space (components and capabilities) and develop a mapping function that can produce solutions to a given design problem. As shown in Figure~\ref{fig:recursivePBD}, one can then take the mapped solution and use this as the new functional (or architectural) space for the next iteration of solution mapping.

that aid in the development and improvement of security modeling approaches. For example, Platform-based design~\cite{Vincentelli2007} is a prime example of how one can take the functional space (including security requirements) and the architectural space (components and capabilities) and develop a mapping function that can produce solutions to a given design problem.

%As shown in Figure~\ref{fig:recursivePBD},

One can then take the mapped solution and use this as the new functional (or architectural) space for the next iteration of solution mapping.

%While having an equation for security risk is great, this does not allow for a representation of a system as a whole.

Additional aspects that must be taken into account include costs of implementing a given solution, the cost of maintaining a given solution, how a generated solution's ranking will change based on the user type interacting with the system, operational costs of a given solution, as well as determination of the number of requirements met, or not met, by any chosen design solution. Taking these aspects into account, this paper proposes the following equations to calculate an overall cost

Additional aspects that must be taken into account include costs of implementing a given solution, the cost of maintaining a given solution,

%how a generated solution's ranking will change based on the user type interacting with the system,

operational costs of a given solution.

%, as well as determination of the number of requirements met, or not met, by any chosen design solution.

Taking these aspects into account, this paper proposes the following equation to calculate an overall cost

% and `estimation metric'

for any produced embedded system security modeling design.

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

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

\section{Exploring a Simple Implementation}

\label{sec:simpleExample}

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

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

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

@@ -589,7 +598,7 @@ \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 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 cost 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 fully 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 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}.