AADL, like most modeling languages, must be able to describe not only the requirements of a system, but also the constraints, capabilities, and costs of various implementations and methods for the purpose of modeling a gamut of different designs. Coupling this already large space with security causes the considerations and influences on the problem to grow considerably. This paper will choose to examine the field of modeling embedded system security through the lens of the Architecture Analys

is \& Design Language (AADL).

%AADL, like most modeling languages, must be able to describe not only the requirements of a system, but also the constraints, capabilities, and costs of various implementations and methods for the purpose of modeling a gamut of different designs. Coupling this already large space with security causes the considerations and influences on the problem to grow considerably. This paper will choose to examine the field of modeling embedded system security through the lens of the Architecture Analysis \& Design Language (AADL).

Modeling security 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 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~\cite{Vincentelli2007}) that aid in the development and improvement of security modeling approaches. For example, Platform-based design is a prime example of how one can take the functional space (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.

@@ -316,14 +315,13 @@ \section{Exploring a Simple Implementation}

\item Non-encrypted communication with a single IO bus.

\item Encrypted communication with a single IO bus.

\end{enumerate}

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.

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 encryption 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? The first step requires the creation of `relativity matrix'~\cite{Ferrante2013} for developing a relatively deterministic security metric value. The point of this is to generate a ranking for all known solutions that ranges from 0.00 -{}- 1.00 that can be used as a weight or security level with other known cost variables to produce a metric that can be used to compare potential generated solutions. For the purpose of this paper, we will be making use of the encryption standard rankings developed by Ferrante et.~al.

The next step is how to consider differences between the four implementations of the wireless transmitter. Differences from values can come from alternative design choices and/or algorithm and policy implementations of security or other standard constraints being imposed onto the design problem. For this simple example, the main differences are the number of IO lines and the implementation of encryption. These different aspects can be compared by assigning weights for allowing relative importance, thus representing (in some arbitrary manner) the user-defined requirements imposed on the design being generated. This human-related favoritism causes the generated metric to alter from a small amount to notable change based on the chosen importance of different features. Other areas originate from the development of `user risk type' and `solution metric', where there are some arbitary decisions made on ranking of users or generated solutions.

The next step is how to consider differences between the implementations of the wireless transmitter. Differences from values can come from alternative design choices and/or algorithm and policy implementations of security or other standard constraints being imposed onto the design problem. For this simple example, the main difference examined is the implementation of encryption. These different aspects can be compared by assigning weights for allowing relative importance, thus representing (in some arbitrary manner) the user-defined requirements imposed on the design being generated. This human-related favoritism causes the generated metric to alter from a small amount to notable change based on the chosen importance of different features. Other areas originate from the development of `user risk type' and `solution metric', where there are some arbitary decisions made on ranking of users or generated solutions.

\textbf{SHOW THE EQUATION BEING PUT INTO PRACTICE}

Before being able to calculate out the estimation matrix for our wireless transmitter example, allow this paper to 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 requirements (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 (CW), direct attack probablitiy (DAP), and indirect attack probability (IAP). For the CW 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 CW for loss becomes \$20 per 8 man-hours. 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 DAP 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 (IC), the maintenance cost (MC), and `solution metric'/operational cost (OC) since these values would come from metrics internal to a company or organization. IC is taken to be \$50 in parts and design per 40 man-hours, MC is taken to be \$50 in drive out cost per 4 man-hours to check the system, and OC 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.

@@ -396,7 +394,7 @@ \section{Examining Attack and Defense with Detail}

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. 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, 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). Then one must account for the arbitrary worth of that information to another individual, which could also vary greatly. For example: an encrypted file that a computer novice comes across will have little worth to them, but to an individual whom has experience this may pass some calculated risk threshold. Additionally, a person could act as an `information broker' that may not have a `worth' value attached to data at this point, but in the future the worth associated with specific information could easily rise or fall depending on content and `liveliness'.