AADLSecPaper.tex

% This is based on the LLNCS.DEM the demonstration file of
% the LaTeX macro package from Springer-Verlag
% for Lecture Notes in Computer Science,
% version 2.4 for LaTeX2e as of 16. April 2010
%
% See http://www.springer.com/computer/lncs/lncs+authors?SGWID=0-40209-0-0-0
% for the full guidelines.
%
\documentclass{llncs}

% Table package needs
\usepackage{tabularx,booktabs}
\usepackage{multirow}
\usepackage[normalem]{ulem}
\usepackage[english]{babel}

% Image package needs
\usepackage{graphicx}
%\usepackage{graphics}

% Equation packages
\usepackage{amsmath}

\usepackage{listings}	% Include the listings-package
\usepackage{color}
\usepackage{balance}
\useunder{\uline}{\ul}{}

\definecolor{darkgreen}{rgb}{0,0.5,0}
\definecolor{mygreen}{rgb}{0,0.6,0}
\definecolor{mygray}{rgb}{0.5,0.5,0.5}
\definecolor{mymauve}{rgb}{0.58,0,0.82}
\lstset{ %
  backgroundcolor=\color{white},   % choose the background color; you must add \usepackage{color} or \usepackage{xcolor}
  basicstyle=\ttfamily\scriptsize,        % the size of the fonts that are used for the code
  breakatwhitespace=false,         % sets if automatic breaks should only happen at whitespace
  breaklines=true,                 % sets automatic line breaking
  captionpos=b,                    % sets the caption-position to bottom
  commentstyle=\color{mygreen},    % comment style
  deletekeywords={...},            % if you want to delete keywords from the given language
  escapeinside={\%*}{*)},          % if you want to add LaTeX within your code
  extendedchars=true,              % lets you use non-ASCII characters; for 8-bits encodings only, does not work with UTF-8
  frame=single,                    % adds a frame around the code
  keepspaces=true,                 % keeps spaces in text, useful for keeping indentation of code (possibly needs columns=flexible)
  keywordstyle=\color{blue},       % keyword style
%  language=C,                 % the language of the code
  morecomment=[l]{--},
  morekeywords={property,set,is,type, constant, enumeration, end, applies, to, inherit, of, *,...},            % if you want to add more keywords to the set
  numbers=left,                    % where to put the line-numbers; possible values are (none, left, right)
  numbersep=5pt,                   % how far the line-numbers are from the code
  numberstyle=\tiny\color{mygray}, % the style that is used for the line-numbers
  rulecolor=\color{black},         % if not set, the frame-color may be changed on line-breaks within not-black text (e.g. comments (green here))
  showspaces=false,                % show spaces everywhere adding particular underscores; it overrides 'showstringspaces'
  showstringspaces=false,          % underline spaces within strings only
  showtabs=false,                  % show tabs within strings adding particular underscores
  stepnumber=1,                    % the step between two line-numbers. If it's 1, each line will be numbered
  stringstyle=\color{mymauve},     % string literal style
  tabsize=2,                       % sets default tabsize to 2 spaces
  title=\lstname                   % show the filename of files included with \lstinputlisting; also try caption instead of title
}

\begin{document}

\title{An adversarial risk-based approach to embedded systems security modeling}
%
\titlerunning{AADL Security}  % abbreviated title (for running head)
%                                     also used for the TOC unless
%                                     \toctitle is used
%
%\author{Paul Wortman \and John A. Chandy}
%
%\authorrunning{Ivar Ekeland et al.} % abbreviated author list (for running head)
%
%%%% list of authors for the TOC (use if author list has to be modified)
%\tocauthor{Ivar Ekeland, Roger Temam, Jeffrey Dean, David Grove,
%Craig Chambers, Kim B. Bruce, and Elisa Bertino}
%
%\institute{University of Connecticut, Storrs CT 06269, USA}%\\
%\email{I.Ekeland@princeton.edu},\\ WWW home page:
%\texttt{http://users/\homedir iekeland/web/welcome.html}
%\and
%Universit\'{e} de Paris-Sud,
%Laboratoire d'Analyse Num\'{e}rique, B\^{a}timent 425,\\
%F-91405 Orsay Cedex, France}

\maketitle              % typeset the title of the contribution

\begin{abstract}
%AADL is a common use language that has been developed and tweaked over the years to allow the ability to 
%describe model behavior and specifications, with more recent attempts to define language for security 
%requirements and verification.  This paper examines previous implementations of behavior, requirements, and 
%security in AADL and then goes to propose a new framework for better integration and description of security 
%requirements and behavior within the AADL lexicon.
\textbf{Something something abstract}
\keywords{security modeling, security framework, secure system design}
\end{abstract}

\section{Introduction}
Talk about need for a new security framework in AADL. What is missing, what is needed.
What will this paper be bringing to the table?

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).  
\begin{itemize}
	\item Modeling security is a difficult problem that has not been thoroughly explored.  To properly modeling 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.

\begin{figure}
	\includegraphics[width=0.5\textwidth]{./images/recursivePBD.png}
	\caption{Visualization of Recursive PBD Model~\cite{Vincentelli2007}}
	\label{fig:recursivePBD}
\end{figure}


	\item What are the challenges?  The challenges faced 
	\begin{itemize}
		\item How does one begin to place units on an arbitrary thing like risk?  Risk is generally treated as a probability that an event will occur.  To define risk from an embedded systems security modeling standpoint, one must first determine how to define risk in a meaningful manner, and how to then apply this metric to the situation that involved said `security risk'.  More on this topic will be explored in Section~\ref{sec:riskDefinition}.
		\item How does one define qualitative aspects of security?  One method that can be used to assign a quantitative value to a qualitative property is to use a relative ranking system to scale all available solutions from a 0.00 -{}- 1.00 scale.  Work on implementing this can be seen in a paper by Ferrante et.~al.~\cite{Ferrante2013}.
	\end{itemize}
	\item Why use AADL?  Why should this paper have chosen to examine embedded system security modeling through the AADL language?  AADL has a large and active community that works towards development and improvement of new annexes or other extensions to the existing AADL lexicon.  In addition to the ease of extensibility, AADL is an easy language to pick up and learn.  This paired with the way in which AADL has been intuitively built, allows for ease of extension by other users or even the community at large. 
	\item What needs to be done that is not being done?
	\begin{itemize}
		\item Need to develop a mapping process for taking all of the cataloged information and possible solutions \& producing solutions that meet user-defined security requirements while maintaining within external constraints and the capabilities of the architectural components being used.  To begin this approach, one will first need to define the constraints of the system, describe the considerations that must be taken into account, and standardize a method by which an individual can produce a comparable metric for generated embedded system security model designs.%
	\end{itemize}
\end{itemize}
This paper aims to produce an adversarial risk-based approach to embedded systems security modeling.

\section{Motivation and Related Work}
Points to make in this section of the paper:
\begin{itemize}
	\item Recap summary of the SSR paper/
	\begin{itemize}
		\item What has been done by others to expand the security capabilities of AADL?
		\begin{itemize}
			\item Work has been made to describe behavior, errors, some security properties in terms of verification and validation within the AADL language.  These developments have occurred in a variety of annexes, most recently the security annex extensions and alterations that have been occurring throughout the summer of 2016~\cite{AADLSecAnnex, AADLSecAnalysis}.  Attempts are always being made to improve AADL and incorporate more in the description and detail of the language.  Recent work includes the definition of specific security-based properties, ranging from `AccessProteciton' to security level definitions to even such extensive work as defining all the different aspects of encryption (shown in Listing~\ref{lst:AADLSecEncryption}.
		\end{itemize}
		\item What is missing from the work of others?
		\begin{itemize}
			\item Current language standards used to describe security concepts, requirements, and constraints has not been developed well enough to be `all-encompassing'.  Recent AADL extensions to the security annex describes the security aspect of `trust' as a non-binary value, which this paper sees has not an accurate reflection of security concerns and does not allow for accurate verification and validation of security requirements and behavior.  While the concept of `trust' can be influenced by aspects of reliability, the metric used for measuring trust should be binary as one can not say that they trust a component, or system, 80\% of the time; whereas reliability can be easily described as a percentage.
			\item With all the work towards describing and defining security modeling aspects, there is a need to develop a method for calculating `estimation metrics' that can be used to compare and contrast generated solutions.  To even begin development of these metrics, one needs to be able to account for a `security metric' that can represent differing solutions, algorithms, methods for tackling security concerns and requirements.  This `security metric' value should be `relatively deterministic'.  What this paper means it that the values calculated should be deterministic, but that this deterministic nature will originate from a scaling, or ranking, that is `relative' to the capabilities of the security aspect being examined (e.g. ranking encryption techniques~\cite{Ferrante2013}).  Further more, these metrics must eventually all have the same basic `unit of measure', thus allowing for an `easy' interpretation of developed metrics and calculated values for various security solution implementation designs.  The easiest is a monetary amount (USD).  Since everything carries some weight of time (development, testing, production, design), then at some point one will need to convert a unit-less metric to a time metric to a monetary metric.  To better describe these security models from a financial standpoint, it might be advantageous to have the final estimation metric be represented with a money over time unit of measurement.
		\end{itemize}
		\item Section~\ref{sec:framework} will propose a security framework that can be used for applying mapping process by which a set of risk-based equations can be used to assign metrics to developed embedded system security models.  But before one can even begin to apply a framework to this mapping process, one needs to first be able to define `Security Risk' so that a relatively deterministic formula can be used to obtain a meaningful metric.
	\end{itemize}
\end{itemize}

\begin{lstlisting}[caption={AADL Security Annex Definitions of Encryption~\cite{AADLSecAnnex}},label={lst:AADLSecEncryption}]
encryption   : security_properties::encryption_type applies to
     {port, virtual bus, bus, memory, access};
encryption_type       : type record (
     method           : security_properties::supported_encryption_method;
     algorithm        : security properties::supported_encryption_algorithm;
     public_key       : aadlstring;
     private_key      : aadlstring;
     key              : aadlstring;
     operation_mode   : security_properties::supported_operation_mode;
};
supported_encryption_method       :
     type enumeration (symmetric, asymmetric, clear);
supported_encryption)algorithm    :
     type enumeration (tripledes, des, rsa, blowfish, aes, clear);
supported_operations_mode         : 
     type enumeration (ecb, cbc, pcbc, cfb, ofb, ctr);
\end{lstlisting}

% Add in an image of the drawing from the bulletjournal on the process
\begin{figure}
	\centering\includegraphics[height=6cm]{./images/aadl_security_framework.png}
	\caption{Visualization of Security Framework}
	\label{fig:AADLSecFrame}
\end{figure}

The new security framework that this paper proposes would require the following steps to take place:
\begin{enumerate}
	\item Creation of a low-level component library that would contain normal and secure version implementations of each base component within the architectural space used for model generation.
	\item Formalized description and definition of higher level security requirements that may come from user-defined needs or from the experience of knowledge of security experts. 
	\item Creation of a mapping process by which security requirements and secure component specifications can be uniformly compared to allow for the generation of potential secure architectural system model solutions to the given inputs.
	\item Verification tools to validate mapping implementation solutions.
\end{enumerate}
Other additional aspects of this framework, that could come from the existing tools, extensions, and annexes would include code generated using the secure models.  Work towards developing these sorts of tools for secure architectures (e.g. seL4) is already one of the focuses of current AADL security annex work~\cite{AADLSecAnalysis}.

\section{Defining Risk}
\label{sec:riskDefinition}
Risk is generally defined as the potential of gaining or losing something of value.  Value can be seen as physical health, emotional well-being, financial wealth, etc.  Another definition of risk involves viewing risk as an intentional interaction made with some uncertainty.  In this scenario uncertainty is defined as a potential, unpredictable, and uncontrollable outcome; risk is seen as a consequence of action taken in spite of some given uncertainty.  Depending on the point-of-view of the individual measuring risk, its definition and application can vary a significant amount.  For example, risk can be the analysis of expected loss (as shown in Equation~\ref{equ:expectedLoss}).
\begin{itemize}
	\item For the purpose of this paper, risk will be represented as a combination of probability and impact (as shown in Equation~\ref{equ:riskDefinition}).  The reason for this interpretation is that from a security lens, it is much easier to quantify probability and impact.  
	\begin{itemize}
		\item This paper's definition of risk and cost modeling is the core of this paper.
	\end{itemize}
	\item What are the many different ways that risk can be assessed? Also, from whose perspective is the examination taking place?  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.  However, for the sake of this paper's work, the interpretation of risk to be used will focus on the probability of an event occurring multiplied by the impact of such an event's occurrence.
	\begin{itemize}
		\item Mention here the idea of measuring risk from a defender's and attacker's standpoints, how those differ, and what the similarities are. (Reference later Section here?)  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.  An other example would be 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 Section~\ref{sec:attackDefense}.
	\end{itemize}
	\item How can one add security into a risk management?
	\begin{itemize}
		\item 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.
		\item 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.
		\item Propose a method for combining security and risk in a measurable manner.  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.  This can be seen in Equation~\ref{equ:securityRisk}, where the probability aspect of risk is split between the chance of how exactly an attacker will occur.  Direct attack is defined as an event where an attacker directly attempts to brute force a given security mechanism or standard.  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.
	\end{itemize}
\end{itemize}

How to define `Risk'?
\begin{itemize}
	\item Needs to be represented as a probability
	\begin{itemize}
		\item means that this value acts as a 0.00 - 1.00 scale weight.
	\end{itemize}
	\item Risk generally represented as: 
	\begin{equation} \label{equ:riskDefinition}
		Risk = Probability * Impact
	\end{equation}
	\item How to add `Security' to the risk calculation?
	\begin{multline}
		`Security Risk' = `Security Metric' * direct attack probability * `cost' weight \\
		+ ... + `Security Risk' * indirect attack probability * `cost' weight
	\end{multline}
	\item Once risk has been defined in the scope/lens of examination, can develop an `Estimation Metric' that can be compared and contrasted with each other to determine the `value'/`worth' of any given design.
\end{itemize}

One can measure risk from the probability of a failure of a given component (e.g. firewall, anti-virus, both), the loss amount for each component failure (e.g. firewall, anti-virus, both, none), and the expected loss (average loss)~\cite{Mukhopadhyay2013}.

\begin{equation} \cite{Mukhopadhyay2013} \label{equ:expectedLoss} 
	Expected Loss = Risk Frequency * Risk Amount 
\end{equation}

Risk is not a certainy, but a proability. (All from \cite{Ferrante2013})
\begin{itemize}
	\item Possibility depends on two aspects: (1) threat and (2) vulnerability
	\begin{enumerate}
		\item Threat - cause of risk (e.g. fire, kidnapping, leakage of sensitive information, etc.)
		\item Vulnerability - exiting flaw or weakness which can be exploited and result in an accident
	\end{enumerate}
	\item Risk states that risk may result in losses for an agent
	\begin{itemize}
		\item Losses occur because of the consequences of an accident (called Impact)
	\end{itemize}
\end{itemize}
Depending on impacted assest `Impact' may be:
\begin{enumerate}
	\item Tangible (e.g. loss of revenue or financial penalties)
	\item Intangible (e.g. loss of productivity or loss of reputation)
\end{enumerate}
`Asset' = anything valuable to a user/organization.
\begin{itemize}
	\item can be (1) a physical object, (2) secrete information, (3) business goal, etc.
\end{itemize}
Risk is a combination of (1) a threat, (2) a vulnerability, (3) an impact.
Complications in Risk Indentification can come from:
\begin{enumerate}
	\item Lack of experience and standards - novel and have not yet standardized procedures for dealing within `Cyber-domain'
	\item Evolution of System - computer systems evolve fast/quickly, system of an organization can change quickly, new technologies appear very often; changing the landscape of `cyber risks'
\end{enumerate}
Security levels are interdependent depending on implementation and scenario/situtation.

\section{Introducing the Framework}
\label{sec:framework}
Give a detailed description of the framework at this point in time.  What is there and what the paper will present.

Now that this paper has presented a meaningful manner of representing security risk as a metric, this paper moves to show that the introduced security framework is an ideal fit for continuing development and improvement of embedded system security modeling techniques and methodologies.  The key points to touch upon in this section are:
\begin{itemize}
	\item What does the proposed framework bring to the table that lacked in previous security framework designs?  The new security framework proposed allows for generation of embedded system security models by assuming that the security requirements and architectural component capabilities can be represented in a quantitative manner.  With the framework, shown in Figure~\ref{fig:AADLSecFrame}, one can take the risk equations developed in Section~\ref{sec:riskDefinition} and produce a meaningful metric estimation that can be used to compare and contrast varying security model solutions.  Combination of the framework's mapping process and the risk equations developed is done in the following manner:
	\begin{itemize}
		\item Define the security requirements and architectural components in a numerically meaningful manner.
		\item Take these unit-less metrics and apply a `conversion equation' to them in order to produce a meaningful, `monetary unit' based metric.
		\item Develop a method of interpreting the metrics in terms of requirements met, not met, and additional features added to the system.
		\item Combine these metrics in a unified equation that can be used to take in values from the functional and architectural space to produce a series of embedded system security model solutions.
	\end{itemize}
	\item What are the complication of combining these techniques?
	\begin{itemize}
		\item One complication of this technique is the requirement to create `libraries' for certain aspects of the security modeling framework; for example, the various solution implementations for `keeping data secure'.  More will be touched upon this subject in Section~\ref{sec:additionalConcerns}.  Another concern is how one ranks all the various security solutions, algorithms, and methodologies in such a manner that the capabilities of the architectural components play a part in determining the best solution models that can be generated from a given set of constraints.
		\item Certain aspects of this mapping process are easier to tackle  but just have not had the time and effort focused on them.  One such aspect is defining security terms in a manner that can be standardized for use.  However, although choosing the language to describe security concepts and ideas may be simple, having that language remain flexible and relevant over the course of security's evolution is not as easy.  Working towards an effective, rigorous, and standardized security modeling framework is something that will not only benefit the security community, but will allow for better representation and understanding in other fields as well (e.g. business).
	\end{itemize}
	\item Now that aspects of this framework's mapping process have been explained, allow us to apply these techniques to a sample example.
\end{itemize}

\begin{itemize}
\item Need to create a matric of weights based on the relative importance of any given solution $s_i$ in comparison to solution $s_j$~\cite{Ferrante2013}.  
\item \textit{Importance} is defined as: `case of implementation by a given company/group.
\item Will be partially arbitrary and partially cost analysis.
\item Could also come from the preference/wheel house of a given company.
\end{itemize}

\begin{multline} \label{equ:securityMetric}
	`Security Metric' (Security Level) = \\
weight_{component capability 1} * Security Level_{component capability 1} \\
+ weight_{component capability 2} * Security Level_{component capability 2} \\
+ {...} + weight_{component capability n} * Security Level_{component capability n}
\end{multline}
\textbf{Note:} Not sure if `component capability' is the right way to describe different algorithms, elements, properties, and capabilities of these different elements of a system/device.  Equation is not necessarily limited to a single use within entire process.

Example of calculating aggregated security metrics of a system (i.e. network security):
\begin{multline} \label{equ:overallSecMet}
	`Overall Security Metric' = weight_{anti-virus} * Security Metric_{anti-virus} \\
+ weight_{firewall} * Security Metric_{firewall} \\
+ weight_{element i} * Security Metric_{element i}
\end{multline}

\begin{multline}	\label{equ:securityRisk}
	`Security Risk' = Security Level * direct attacker probability * cost weight \\
	+ Security Level * indirect attacker probability * cost weight
\end{multline}

\begin{multline} \label{equ:estimationMetric}
	`Estimation Metric' = `User Risk Type' * `Security Risk' + `implementation cost' + \\
 `maintainence cost' + `solution metric' * `requirements weight'
\end{multline}

\section{Exploring a Simple Implementation}
How does a simple examples such as a wireless transmitter get represented in this new framework?

This paper now moves to showing a simple implementation of the security framework's mapping process to produce a meaningful `estimation metric' that can be used to compare design decisions.  This Section must be sure to cover:
\begin{itemize}
	\item What is the example to be shown?  The simple example that this paper will examine is that of a wireless transmitter.  In this example, there are four variations that exist of said transmitter:
	\begin{enumerate}
		\item Non-encrypted communication with a separate input and output buses.
		\item Encrypted communication with separate input and output buses.
		\item Non-encrypted communication with a single IO bus.
		\item Encrypted communication with a single IO bus.
	\end{enumerate}
	For this example, one is deal with 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.  For the sake of simplicity, this paper makes use of the `relativity matrix' developed by Ferrante et.~al.~\cite{Ferrante2013}
	\begin{itemize}
		\item Wireless transmitter example
	\end{itemize}
	\item How does one create the security metric based on the given example?
	\begin{itemize}
		\item Require the creation of `relativity matrix'~\cite{Ferrante2013} for developing a relatively deterministic security metric value. (Perhaps cite work and use metrics developed by Ferrante et.~al.).  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 with other known cost variables to produce a metric that can be used to compare potential generated solutions.
		\item How to consider differences between the four implementations of the wireless transmitter?
		\begin{itemize}
			\item What are the differences?  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.
			\item How can they be represented?  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.
			\item How does this effect the metric?  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.
		\end{itemize}
	\end{itemize}
	\item Now that a simple example has been shown, allow this paper to now expand the considerations that are made for this simplistic example.
\end{itemize}

% Add in the table of elements and variations
\begin{table*}[]
\centering
\caption{Table illustrating different component variations}
\label{elementTypes}
\begin{tabular}{@{}llllll@{}}
\toprule
\multicolumn{6}{c}{Component Types Table}                                                                                                                                                                                                                           \\ \midrule
\multicolumn{1}{c}{\multirow{2}{*}{{\underline{\textbf{Elements}}}}} & \multicolumn{5}{c}{\textbf{Types}}                                                                                                                                                                   \\
\multicolumn{1}{c}{}                                         & \multicolumn{1}{c}{{\underline{\textbf{I}}}} & \multicolumn{1}{c}{{\underline{ \textbf{II}}}} & \multicolumn{1}{c}{{\underline{\textbf{III}}}} & \multicolumn{1}{c}{{\underline{\textbf{IV}}}} & \multicolumn{1}{c}{{\underline{ \textbf{V}}}} \\
Memory                                                       & Unprotected                          & Protected                             & Encrypted                              & Obfuscated                            & Combo                                \\
Bus                                                          & Unprotected                          & Encrypted                             & Non-sniffable                          &                                       &                                      \\
Processor                                                    & Simple                               & Embedded Encryption                   & Pure Encryption                        &                                       &                                      \\
Data                                                         & Plain-text                           & Encryption                            & Protected                              &                                       &                                      \\
Port                                                         & Normal                               & Encrypted                             & Protected                              &                                       &                                      \\ \bottomrule
\end{tabular}
\end{table*}


\begin{lstlisting}[caption={Example of User-defined Lower Level Components},label={lst:AADLUserDefineLow}]
system implementation transmitter.encrypt_i
  -- Subcomponents of the transmitter
  subcomponents
    ant_in : system recv_antenna.normal_i;
    ant_out : system trns_antenna.encrypt_i;
    encrproc : processor procbase.encryptembedded_i;
  -- Connection definitions of the transmitter
  connections
    c0 : port ant_in.wired_out -> encrproc.input_port;
    c1 : port encrproc.output_port -> ant_out.wired_in;
  -- Flow path definition for the transmitter
  flows
    f0 : end to end flow ant_in.f0 -> c0 -> encrproc -> c1 -> ant_out.f0;
   -- Additional properties of the transmitter
  properties
    securityspecs::has_encryption => true;
end transmitter.encrypt_i;

processor implementation procbase.encryptembedded_i
  properties
    securityspecs::has_encryption => true;
    securityspecs::encryptmodule_class => embedded;
    securityspecs::encryption_class => AES;
    securityspecs::encryption_variation => b256;
    securityspecs::has_PUF => false;
    securityspecs::has_TPM => false;
    securityspecs::has_encryptedflash => false;
    securityspecs::isTamperProof => false;
end procbase.encryptembedded_i;
\end{lstlisting}

\subsection{Expanding Considerations}
What other additional expansions can be made to the simple wireless transmitter example? Additional costs, variables, levels of additional detail.

Despite the efforts to simplify the embedded system security modeling problem, there are a plethora of additional variables that can be taken into consideration depending on the environment and user, or company, at risk.  This section will talk on the subject of:
\begin{itemize}
	\item Physical costs (VHDL).  When calculating the estimated cost metrics used for making larger system design decisions, one ideally accounts for as many aspects of the system as possible.  When dealing with the constrained domain of embedded systems, this is doubly so.  Physical costs of the system carry a heavy weight when making choices about design implementations.  Power costs, heat generated, run time, area requirement, etc. are all aspects that must be considered.
	\item Methodologies, algorithms, implementations.  When incorporating software, the assumption of this paper is that software has been designed correctly with no error or malicious behavior embedded within.  To that case, this means that when comparing software implementations, the main considerations of the developer are run time, bits used (in the case of encryption and authentication), and power consumed (with respect to total battery life; total system run time on a single charge).
	\item Requirements met, requirements not met, additional features due to architectural components used.  To further add the weight of additional design considerations to our proposed mapping process, one can account for the requirements that a given design meets, does not meet, and additional features as a result of design decisions.  In this manner a design team can further tweak the generation of certain design solutions based on the requirements met and additional features produced as result.
\end{itemize}
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.

\begin{lstlisting}[caption={User-defined Higher Level Security Requirement},label={lst:AADLUserDefineHigh}]
abstract implementation sysreq.wireless_sensor_i
  subcomponents
    serv_ADConv: abstract sysserv.ADConv_i {
          servatrb::dynamicRange => 0..5 V;
          secatrb::integrity::atkImpact => 300;
          };
    serv_wrlsTrans: abstract sysserv.wrlsTrans_i {
          servatrb::distance => 100 m;
          secatrb::authentication::atkValue => 600;
          secatrb::authentication::atkImpact => 400;
          secatrb::authorization::atkImpact => 1200;
          secatrb::dataleakage::atkImpact: => 800;
          secatrb::dataleakage::atkValue: => 800;
          };
    fnc_data: abstract security_props.data_i {
          dataatrb::data_class => Sensor;
          secatrb::atkImpact => 800;
  properties
    secatrb::hasProtection => false;
    secatrb::AuthGroup => Employees;
end sysreq.wireless_sensor_i;
\end{lstlisting}

\begin{multline} \label{equ:probRating}
	`Probability Rating' = weight_{sensitivity of data} * `known vulns metric' \\
+ weight_{exposure} * Security Level Metric_{data?}
\end{multline}

\begin{multline} \label{equ:wealthFunction}
	`Wealth Function' = Probability Nothing Happens * Initial Wealth \\
+ Probability Event Happens * (Initial Wealth - Losses) \cite{Ferrante2013}
\end{multline}
`Initial Wealth' can be calculated from the design model generated.  \textbf{Note:} `Wealth Function' is focused on the future and use of a given system within an organization.

\section{Examining Attack and Defense with Detail}
\label{sec:attackDefense}
Examination of encryption and authentication processes through the lens of the new security framework.

The purpose of this section is to touch on the following topics:
\begin{itemize}
	\item The different considerations of attackers and defenders.  Depending on the point of view of the individual examining a system, the risk and cost analysis will yield different results to different individuals based on produced incentive and attractiveness of obtainable information in comparison to the defenses that must be circumvented and the related cost.
	\item What aspects are the same or similar enough to take into account.  Certain aspects may be similar, such as the number of steps an individual must go through to interact with a system (e.g. subnets).  While these do exist, the area of greater interest are the aspects that differ between the two points of view.
	\item How to begin developing the required information.  Need to detail out any and all statistical information about attacks on various systems, how the hardware and software nuances affect the overall ranking of different methodologies, and most difficult, one must determine a method for applying the arbitrary qualitative sense of worth for specific data to one's equations in a meaningful way.  Otherwise the generated estimation metric becomes unintelligible.
\end{itemize}

Can create a `correlation matrix' of the inacted defenses and the affect of failure of one defence on the other existing defense (0-1 scaled as well).

\subsection{Expansion of Details}
Expand further on additional details and variables that can affect the modeling of secure system solutions.

The purpose of this section is to talk about the topics:
\begin{itemize}
	\item Additional concerns of attackers/defenders that can be considered.  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.
\end{itemize}

\section{Additional Concerns}
\label{sec:additionalConcerns}
The purpose of this section is to talk about the topics:
\begin{itemize}
	\item Detail out the concerns about for needs of `libraries' of information and other data that will be required for greater formalization of calculated values.
	\item Point is to try and have as few `unitless' metric values due to their arbitrary nature.  At least will need to convert values to monetary value at some point since time can equal \$\$\$.
	\item There are still aspects of this process that are arbitrarily decided upon.  This is an extremely difficult part to remove from the current examination of security framework mapping using an adversarial risk-based approach to embedded systems security modeling, due to the need for qualitative input to a system that has yet to have standard of quantitative input.
\end{itemize}

\section{Conclusion}
What has this paper shown? What needs to be worked on moving forward?

Future work include further development of the mapping process using a risk-based methodology, continue creating more deterministic means for describing security requirements and architectural component capabilities in a meaningful and comparable manner, and development towards an automated method for comparing generated solutions within a constrained and directed manner to arrive at best solutions for generated embedded systems security models.

%
% ---- Bibliography ----
%
\begin{thebibliography}{5}

\bibitem {Ferrante2013}
Ferrante, A., Milosevic, J., Janju\u{s}evi\`{c}, M.:
A Security-enhanced Design Methodology for Embedded Systems,
International Conference on Security and Cryptography (SECRYPT) (2013)

\bibitem {Mukhopadhyay2013}
Mukhopadhyay, A., Chatterjee, S., Saha, D., Mahanti, A., Sadhukhan, S.k.:
Cyber-risk decision models: To insure IT or not?,
Decision Support Systems, Volume 56 pages 11--26 (2013)

\bibitem {Vincentelli2007}
Sangiovanni-Vincentelli, A.: 
Quo Vadis, SLD? Reasoning About the Trends and Challenges of System Level Design,
Proceedings of the IEEE (March 2007)

%\bibitem {SysML-Sec}
%SysML-Sec,
%\url{http://sysml-sec.telecom-paristech.fr/}
%
%\bibitem {jurjens2005secure}
%J{\"u}rjens, J.:
%Secure systems development with UML,
%Springer Science \& Business Media (2005)
%
%\bibitem {jurjens2002umlsec}
%J{\"u}rjens, J.:
%UMLsec: Extending UML for secure systems development,
%UML 2002—The Unified Modeling Language, Springer Publishing, pages 412--425 (2002)
%
%\bibitem {SysML}
%SysML,
%\url{http://sysml.org/}
%
%\bibitem {AADLSite}
%AADL,
%\url{http://www.aadl.info/aadl/currentsite/}
%
%\bibitem {AADLV2Overview}
%Feiler, P.:
%SAE AADL V2: An Overview.
%Carnegie Mellon University (2010)
%
%\bibitem {AADLTools}
%AADL Tools,
%\url{https://wiki.sei.cmu.edu/aadl/index.php/AADL\_tools}
%
%\bibitem {Osate2}
%Osate 2,
%\url{https://wiki.sei.cmu.edu/aadl/index.php/Osate\_2}
%
%\bibitem {Osate2Examples}
%Osate 2 Example Repository,
%\url{https://github.com/osate/examples}
%
%\bibitem {UserDaysMay2016}
%User Days - May 2016,
%\url{https://github.com/saeaadl/userdays/tree/master/UserDays/May2016}
%
%\bibitem {AADLResolute}
%Resolute Website,
%\url{http://loonwerks.com/tools/resolute.html}
%
%\bibitem {RDALOverview}
%Blouin, D.:
%AADL Requirements Annex Review,
%\url{http://www.aadl.info/aadl/downloads/committee/feb2013/presentations/aadl\_standards\_requirements\_annex\_review\_06022013.pdf}
%
%\bibitem {gacek2014resolute}
%Gacek, A., Backes, J., Cofer, D., Slind, K., Whalen, M.:
%Resolute: An assurance case language for architecture models,
%ACM SIGAda Ada Letters, Volume 34 Number 3, pages 19--28 (2014)
%
%\bibitem {EMV1}
%Feiler, P.:
%SAE AADL Error Model Annex: An Overview,
%\url{https://wiki.sei.cmu.edu/aadl/images/1/13/ErrorModelOverview-Sept222011-phf.pdf}
%
%\bibitem {EMV2}
%Feiler, P.:
%SAE AADL Error Model Annex: Discussion Items,
%\url{https://wiki.sei.cmu.edu/aadl/images/1/13/ErrorModelOverview-Sept222011-phf.pdf}
%
%\bibitem {BLESS2013}
%Larson, B.R., Chalin, P., Hatcliff, J.:
%BLESS: Formal Specification and Verification of Behaviors for Embedded Systems with Software,
%\url{https://ti.arc.nasa.gov/m/events/nfm2013/pubs/BLESS.pdf}
%
\bibitem {AADLSecAnnex}
Delange, J., Feiler, P., Klieber, W., Nam, M., Seibel, J.:
AADL Security Annex,
\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-annex-May2016.pdf}

\bibitem {AADLSecAnalysis}
Delange, J., Nam, M., Seibel, J.:
AADL Security Analysis Tools,
\url{https://github.com/saeaadl/userdays/blob/master/UserDays/May2016/security-analysis-May2016.pdf}
%
%\bibitem {ellison2015extending}
%Ellison, R., Householder, A., Hudak, J., Kazman, R., Woody, C.:
%Extending AADL for Security Design Assurance of Cyber-Physical Systems,
%Software Engineering Institute, CMU/SEI-2015-TR-014 (2015)
%
%\bibitem {jeepHack}
%Drozhzhin, A.:
%Black Hat USA 2015: The full story of how that Jeep was hacked,
%\url{https://blog.kaspersky.com/blackhat-jeep -cherokee-hack-explained/9493/}
%
%\bibitem {planeHack}
%Zetter, K.:
%Feds say that banned researcher commandeered a plane,
%\url{http://www.wired.com/2015/05/feds-say-banned-researcher-commandeered-plane/}
%
%\bibitem {superFish}
%Hope, P.:
%Superfish adware weakens security and injects ads on some Lenovo laptops,
%\url{http://www.techrepublic.com/article/superfish-adware-weakens-security-and-injects-ads-on-some-lenovo-laptops/}
%
%\bibitem {lenovoWPBT}
%Sanders, J.:
%Windows and UEFI anti-theft mechanism makes systems less secure,
%\url{http://www.techrepublic.com/article/windows-and -uefi-anti-theft-mechanism-makes-systems-less-secure/}
%
%\bibitem {govHack}
%Olorunnipa, T.:
%Breach of Employee Data Wider Than Initial Report, U.S. Says,
%\url{http://www.bloomberg.com/politics/articles/2015-06-12/white-house-says-personnel-records-possibly-breached-twice}
%
%\bibitem {stageFright}
%Vaughan-Nicholas, S.J.:
%Stagefright: Just how scary is it for Android users?,
%\url{http://www.zdnet.com/article/stagefright-just-how-scary-is-it-for-android-users/}
%
%\bibitem {stageFright2}
%Whittaker, Z.:
%Stagefright is back, and affecting millions of Android devices,
%\url{http://www.zdnet.com/article/new-stagefright-2-0-flaws-affect-millions-of-android-devices/}
%
%\bibitem {androidUpdates}
%Tofel, K.:
%HTC says monthly Android security updates are ``unrealistic'',
%\url{http://www.zdnet.com/article/htc-says-monthly-stagefright-android-security-updates-are-unrealistic/}
%
%\bibitem {androidMarshmallow}
%Jack Wallen, J.:
%The woes of Android updates, and how to fix the process,
%\url{http://www.techrepublic.com/article/the-woes-of-android-updates-and-how-to-fix-the-process/}
%
%\bibitem {googleAndroid}
%Sanders, J.:
%Google finally doubles down on security with monthly Android updates,
%\url{http://www.techrepublic.com/article/google-and-some -android-phone-vendors-introduce-welcome-changes-to-security-update-process/}
%
%\bibitem {aaraj2008analysis}
%Aaraj, N., Raghunathan, A., Jha, N.K.:
%Analysis and design of a hardware/software trusted platform module for embedded systems,
%ACM Transactions on Embedded Computing Systems (TECS), Volume 8 Number 1, page 8 (2008)
%
%\bibitem {denning1996location}
%Denning, D.E., MacDoran, P.F.:
%Location-based authentication: Grounding cyberspace for better security,
%Computer Fraud \& Security, Volume 1996 Number 2, pages 12--16 (1996)
%
%\bibitem {saito2015case}
%Saito, M., Hazeyama, A., Yoshioka, N., Kobashi, T., Washizaki, H., Kaiya, H., Ohkubo, T.:
%A case-based management system for secure software development using software security knowledge,
%Procedia Computer Science, Volume 60, pages 1092--1100 (2015)
%
%\bibitem {denning2015toward}
%Denning, D.E.:
%Toward more secure software,
%Communications of the ACM, Volume 8 Number 4, pages 24--26 (2015)
%
%\bibitem {nguyen2015model}
%Nguyen, P.:
%Model-Driven Security With Modularity and Reusability For Engineering Secure Software Systems,
%University of Luxembourg (2015)
%
%\bibitem {ravi2004security}
%Ravi, S., Raghunathan, A., Kocher, P., Hattangady, S.:
%Security in embedded systems: Design challenges,
%ACM Transactions on Embedded Computing Systems (TECS), Volume 3 Number 3, pages 461--491 (2004)
%
%\bibitem {gokhale2008model}
%Gokhale, A., Balasubramanian, K., Krishna, A.S., Balasubramanian, J., Edwards, G., Deng, G., Turkay, E., Parsons, J., Schmidt, D.C.:
%Model driven middleware: A new paradigm for developing distributed real-time and embedded systems,
%Science of Computer programming, Volume 73 Number 1, pages 39--58  (2008)
%
%\bibitem {perez2006vtpm}
%Perez, R., Sailer, R., van Doorn, L., and others:
%vTPM: virtualizing the trusted platform module,
%Proc. 15th Conf. on USENIX Security Symposium, pages 305--320
%
%\bibitem {yan2015novel}
%Yan, W., Tehranipoor, F., Chandy, J.A.:
%A Novel Way to Authenticate Untrusted Integrated Circuits,
%Proceedings of the IEEE/ACM International Conference on Computer-Aided Design, pages 132--138 (2015)
%
%\bibitem {tehranipoor2015dram}
%Tehranipoor, F., Karimina, N., Xiao, K., Chandy, J.:
%DRAM based intrinsic physical unclonable functions for system level security,
%Proceedings of the 25th edition on Great Lakes Symposium on VLSI, pages 15--20 (2015)
%
%\bibitem {CommonCriteria}
%Common Criteria for Information Technology Security Evaluation,
%ISO/IEC, Number ISO/IEC 15408, July 2015
%
%\bibitem {benzel2005design}
%Benzel, T.V., Irvine, C.E., Levin, T.E., Bhaskara, G., Nguyen, T.D., Clark, P.C.:
%Design principles for security (2005)
%
%\bibitem {lin2013security}
%Lin, C., Zhu, Q., Phung, C., Sangiovanni-Vincentelli, A.:
%Security-aware mapping for CAN-based real-time distributed automotive systems,
%Computer-Aided Design (ICCAD), 2013 IEEE/ACM International Conference on, pages 115--121 (2013)
%
%\bibitem {markose2008systematic}
%Markose, S., Liu, X., McMillin, B.:
%A systematic framework for structured object-oriented security requirements analysis in embedded systems,
% IEEE/IFIP International Conference on Embedded and Ubiquitous Computing, 2008. EUC'08, Volume 1, pages 75--81 (2008)
%
%\bibitem {yu1997towards}
%Yu, E.S.:
%Towards modelling and reasoning support for early-phase requirements engineering,
%Proceedings of the Third IEEE International Symposium on Requirements Engineering, pages 226--235 (1997)
%
%\bibitem {massacci2010security}
%Massacci, F., Mylopoulos, J., Zannone, N.:
%Security requirements engineering: the SI* modeling language and the secure tropos methodology,
%Advances in Intelligent Information Systems, pages 147--174 (2010)
%
%\bibitem {sangiovanni2007quo}
%Sangiovanni-Vincentelli, A.:
%Quo vadis, SLD? Reasoning about the trends and challenges of system level design,
%Proceedings of the IEEE, Volume 95 Number 3, pages 467--506 (2007)
%
%\bibitem {ALISA2016}
%Delange, J., Feiler, P., Neil, E.:
%Incremental Life Cycle Assurance of Safety-Critical Systems,
%8th European Congress on Embedded Real Time Software and Systems (ERTS 2016)

\end{thebibliography}

\end{document}