Fleshing out of bullet outline for each section. Next step: Complete …

…bullet outline for sections 4 to the end. Next: incorporate all the included images, equations, and writing into a complete draft of the paper by the end of the day Wednesday.

AADLSecPaper.tex

@@ -101,29 +101,24 @@ 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 What are the needs for security modeling?
-	\begin{itemize}
-		\item Security Requirements (High level \& abstract)
-		\item Component Capabilities (Low level \& concrete)
-		\item Mapping equation for relating the two spaces (Talk about PBD and why it's a great fit! :D)
-	\end{itemize}
-	\item What are the challenges?
-	\begin{itemize}
-		\item How does one begin to place units on an arbitrary thing like risk?
-		\item How does one define qualitative aspects of security?
-		\begin{itemize}
-			\item Use 0.00 -{}- 1.00 scale using number of bits as ranking system (encryption example).
-		\end{itemize}
-	\end{itemize}
-	\item Why use AADL?
+	\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 Large active community
-		\item Easy to learn language
-		\item Intuitively built to allow for extension by users/community
+		\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 \textbf{MENTION AUTHORS OF SECURITY METRIC PAPER}~\cite{CITE SECURITY METRIC PAPER}.
 	\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 producing solutions that meet user-defined security requirements while maintaining within external constraints and the capabilities of the architectural components being used.
+		\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.
@@ -135,19 +130,12 @@ Points to make in this section of the paper:
 	\begin{itemize}
 		\item What has been done by others to expand the security capabilities of AADL?
 		\begin{itemize}
-			\item Work to describe behavior, errors, some security properties in terms of verification and validation.
-			\item Attempts always being made to improve AADL and incorporate more in the description and detail of the language
+			\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'.
-			\item Need to develop a method for calculating `estimation metrics' that can be used to compare and contrast generated solutions.
-		\end{itemize}
-		\item What needs to be brought to the table for improving AADL into a security modeling language?
-		\begin{itemize}
-			\item Account for a security metric that is `relatively deterministic'.
-			\item Have a basic `unit of measure' that allows for `easy' interpretation of developed/calculated metric.
-			\item \textbf{Note:} 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 unitless metric to a time metric to a monetary metric. (Perhaps a monetary over time unit?).
+			\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{SECURITY METRICS PAPER}).  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}
@@ -189,24 +177,22 @@ The new security framework that this paper proposes would require the following
 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}
-The following are the points to make in this section of the paper:
+\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 Talk about how Risk is defined differently depending on the point-of-view.  How will risk be examined for the purpose of this paper?
+	\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?
+	\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?)
+		\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 What are the ways one thinks up?
-		\item How to define that security in a meaningful and relatively deterministic manner?
-		\begin{itemize}
-			\item Why is `relatively' good enough? Why not fully deterministic? Why not have what VHDL has?!?!
-		\end{itemize}
-		\item Propose a method for combining security and risk in a measurable manner.
+		\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}
 
@@ -217,7 +203,7 @@ How to define `Risk'?
 		\item means that this value acts as a 0.00 - 1.00 scale weight.
 	\end{itemize}
 	\item Risk generally represented as: 
-	\begin{equation}
+	\begin{equation} \label{equ:riskDefinition}
 		Risk = Probability * Impact
 	\end{equation}
 	\item How to add `Security' to the risk calculation?
@@ -432,6 +418,7 @@ end sysreq.wireless_sensor_i;
 `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:
@@ -476,6 +463,11 @@ 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/}
@@ -548,11 +540,11 @@ Decision Support Systems, Volume 56 pages 11--26 (2013)
 %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 {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,