Finished fleshing out outline. Next need to combine seciton ramblins …

…into outline to create first draft. Should be able to complete by end of the day tomorrow (Wednesday).

AADLSecPaper.tex

@@ -320,12 +320,12 @@ This paper now moves to showing a simple implementation of the security framewor
 	\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.).
+		\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?
-			\item How can they be represented?
-			\item How does this effect the metric?
+			\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.
@@ -387,9 +387,9 @@ What other additional expansions can be made to the simple wireless transmitter
 
 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)
-	\item Methodologies, algorithms, implementations
-	\item Requirements met, requirements not met, additional features due to architectural components used
+	\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.
 
@@ -434,9 +434,9 @@ Examination of encryption and authentication processes through the lens of the n
 
 The purpose of this section is to touch on the following topics:
 \begin{itemize}
-	\item The different considerations of attackers and defenders.
-	\item What aspects are the same or similar enough to take into account.
-	\item How to begin developing the required information.
+	\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).
@@ -446,7 +446,7 @@ Expand further on additional details and variables that can affect the modeling
 
 The purpose of this section is to talk about the topics:
 \begin{itemize}
-	\item Additional concerns of attackers/defenders that can be considered.
+	\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}
@@ -455,11 +455,14 @@ 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 ----
 %