diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex
index c342b54..5e20446 100644
--- a/PBDSecPaper.tex
+++ b/PBDSecPaper.tex
@@ -186,32 +186,24 @@ The first principle is that of `Least Common Mechanisms'.  If multiple component
 	\item In the same manner that these various security aspects (e.g. mechanisms, principles, policies) must be considered during development automation, the software and hardware aspects must also come under consideration based on the desired behavior/functionality of the system under design.  One could have security elements that attempt to optimize themselves to the system they are in based on a few pivot points (power, time, efficiency, level of randomness).  Another option for the automated tool could trade out specific security components as an easier way to increase security without requiring re-design/re-construction of the underlying element (e.g. modularity).  There is always the requirement that the overall trustworthiness of a new system must meet the standards of the security policies that `rule' the system.  For these reasons a user would desire rigorous documentation that would lay out the requirements of each component, so that in the case of trying to replace faulty or damaged components there would be no loss to the overall trustworthiness of the system; while also not introducing any vulnerabilities due to the inclusion of new system components.
 	\item Virtualization should be used for exploring the design space; it is hoped that it is obvious as to why.  Not only is the cost of prototyping incredably expensive, but redesign is equally costly.  Virtualization aids by removing the need for physical prototyping (less monitary costs) and allows for more rapid exploration of the full design space.  While the design time for such powerful tools will be expensive (both in monitary and temporal costs), the rewards of developing, validating, and evaluating this virtualization tool will offset the early design phase costs of automated security component design.
 	\end{itemize}
-\item Mapping of Security onto PBD structure.  At this point, it is the hope of the author that the reader can see how the needs and benefits of platform-based design and security development are closely aligned along the same concepts of rigorous design, virtualization/automation of tools, and the needs for meticulous documentation.  The reasoning for using platform-based design is that PBD functions as a form of `architecural base' upon which security development can be mapped over.  PBD can be used for development of hardware elements, security centric SoCs, or even as a set of abstract blocks that can be used to design higher level applications (e.g. virtualization development of larger security systems).  But as with the development of any tool, and more so when expecting said tools to be more publically used, there is a deep need for meticulous documentation and rigorous use/distribution  of standards.  without this, there is no guarentee that anyone will benefits from use of this new model.  Much like with security inovation and implementation, without proper outlining of behavior and function there is greater possiblity for erroneous use thus leading to greater vulnerability of the overall system.
-	\begin{itemize}
-	\item ``Despite occasional cryptology-related attacks, most security vulnerabilities result from poor software design and implementation, such as the ever-lasting buffer overrun bugs.  Thus approaches to designing secure software, not just from a traditional cryptology viewpoint, but with a software engineering perspective, are needed to counter the current unsatisfactory situation.''~\cite{Ren2006}
-	\item Focusing efforts on rigorous design documentation allows security concerns to be recognized early in the development process and these aspects can be given sufficient attention in subsequent stages of the device's life cycle.  ``By controlling system security during architectural refinement, we can decrease software production costs and speed up the time to market~\cite{ZhouFoss2006}.''  This approach also enchances the role of the software architects by requiring that their decisions be not only for functional decomposition, but also for non-functional requirements fulfillment.  Hence, virtualization/automation of security development is not only effective but also enticing.
-	\item Sufficient User Documentation - Users should be provided with adequate documentation and other information such that they contribute to, rather than detract from, a system's security.  The availability of documentation and training can help to ensure a knowledgable cadre of users, developers, and administrators.  If any level of user does not know how to use a component properly, does not know the standard security procedures, or does not know the proper behavior to prevent social engineering attacks, then said user can easily introduce new system vulnerabilities.
-		\begin{itemize}
-		\item Complexity must be minimized
-		\item If on-line documentation is inadequate, then it should be obvious that written documentation and appropriate training are needed.
-		\end{itemize}
-	\item Procedural Rigor - The rigor of the system's life cycle process should be commensurate with its intended trustworthiness.  Procedural rigor defines the depth and detail of a system's lifecycle procedures.  These rigors contribute to the assurance that a system is correct and free of unintended functionality in two ways:
-		\begin{itemize}
-		\item Imposing a set of checks and balances on the life cycle process such that the introduction of unspecified functionality is thwarted.
-		\item Applying rigorous procedures to specifications and other design documents contribute to the ability of users to understand a system as it has been built, rather than being misled by inaccurate system representation, thus helping ensure that security and functional objectives of the system have been met.  Highly rigorous development procedures supporting high trustworthiness are costly to follow.  However, the lowered cost of ownership resulting from fewer flaws and security breaches during the product maintenance phase can help to mitigate the higher initial development costs associated with a rigorous life cycle process.
-		\end{itemize}
-	\item Repeatable, Documented Procedures - Techniques used to construct a component should permit the same component to be completely and correctly reconstructed at a later time.  Repeatable and documented procedures support the creation of components that are identical to a component created earlier that may be in widespread use.
-		\begin{itemize}
-		\item The Common Criteria standard~\cite{CommonCriteria} provides a framework for the derivation of system requirements that is comprised of the following steps: definition of system goals and its concept of operation; identification of threats to the defined system; identification of assumptions regarding the system and its environment; identification of organizational policies external to the system; identification of security objectives for the system and its environment based on previous steps; and specification of requirements that will meet the objectives.
-		\end{itemize}
-	\item \textbf{DRAW CONNECTIONS TO SECURITY DEVELOPMENT AND PBD TO SHOW HOW THESE TWO CAN BE MAPPED TOGETHER.  BE SURE TO STATE THE OBVIOUS!!! MAKE THE POINT OF THIS PAPER!}
-	\end{itemize}
-\item The last, and by no means least, important topic that must be tackled in this section is the question of what exactly are the research challenges.  There has been a lot of information, ideas, and principles presented over the course of this writing along with parallels to existing research and methodologies that can be almost directly applied to the concept of mapping security development to platform-based design.  The primary cost of developing security, and running a secure system, is time.  There are the monitary and hardware costs of security developement and implementation, but even those aspects all have a time cost coupled with them.  Time, while being the most expensive part of security design is also the aspect that can be tackled and minimized with rigorous planning and documentation.  Taking into account that even the development of documentation and standards also has its own time cost associated with it, this early phase development can also diminsh the time-cost impact for later steps in the system's development/implementation life-cycle.  Security must be paramount in design from the very beginning of any design and developemtn cycle.
-	\begin{itemize}
-	\item How to put cost on security? How to make models? What is high vs. low? (Are there models that exist?).  While this paper proposes one model for security design and development this, by no means, is the only model for implementing security in a system.  ``Defense in depth''~\cite{DoD2002} is a model in which security is derived from the application of multiple mechanisms; to create a series of barriers against attack by an adversary.  Unfortunately, for the model, without any sound security architecutre and supporting theory, the non-constructive basis of this approach equivicates this model to a temporary patch; putting barriers in places does not equate to levels of trustworthiness.  The ``Balanced assurance''~\cite{Lunt1988}  model centers around a hierarchy of security policies, where different policies are allocated to different components of a system.  The concept is that the trustworthiness of a given component must be consistent with the importance of that component's policy; the greater the trustworthiness the greater the importance of that component.  The fault here is that a system can only be considered as secure as it's least secure component.  While a interesting model and shows promise with respect to specific scenarios, this is not an overarching model that will function in all cases.
-	\item While there are multiple models for performing/implementing security, a significant part of the cost of building a secure system is that of evaluating, and subsequently proving, trustworthiness through a third party's efforts.  A method for minimizing the costs of performing this evaluation is to make use of components that have already had their trustworthiness evaluated and verified, thereby minimizing the need to evaluate the system itself; as it is made of already trustworthy components.  This model would allow for ``evaluation by pieces'' whereby one acknowledges previously evaluated components and does not require their examiniation in the greater evaluation of the composite system.  Unfortunately, this model has only been made available to ``low assurance'' systems as it lacks a well-formed theory of correctness~\cite{Benzel2005}.
-	\end{itemize}
-\item Security design, development, verification, and evaluation is still a relatively new and unexplored space.  Because of this there is a constant growth and evolution of security protocols and standards, which requires a thorough exploration of the security design space.  It is the belief of this paper that the best model for focusing effort and development towards is a platform-based design for security development.  The levels of abstraction aid in virtualization design, the overarching concept of mapping platforms to instances (and vica-versa) aids in early developemtn stages, and the need for rigorous documentation and meticulous following of standards are concepts that not only stem from platform-based design but greatly lend to the needs of security design and development.
+\end{itemize}
+
+At this point, it is the hope of the author that the reader can see how the needs and benefits of platform-based design and security development are closely aligned along the same concepts of rigorous design, virtualization/automation of tools, and the needs for meticulous documentation.  The reasoning for using platform-based design is that PBD functions as a form of `architecural base' upon which security development can be mapped over.  PBD can be used for development of hardware elements, security centric SoCs, or even as a set of abstract blocks that can be used to design higher level applications (e.g. virtualization development of larger security systems).  But as with the development of any tool, and more so when expecting said tools to be more publically used, there is a deep need for meticulous documentation and rigorous use/distribution  of standards.  without this, there is no guarentee that anyone will benefits from use of this new model.  Much like with security inovation and implementation, without proper outlining of behavior and function there is greater possiblity for erroneous use thus leading to greater vulnerability of the overall system.
+\begin{quotation}
+``Despite occasional cryptology-related attacks, most security vulnerabilities result from poor software design and implementation, such as the ever-lasting buffer overrun bugs.  Thus approaches to designing secure software, not just from a traditional cryptology viewpoint, but with a software engineering perspective, are needed to counter the current unsatisfactory situation.''~\cite{Ren2006}
+\end{quotation}
+Focusing efforts on rigorous design documentation allows security concerns to be recognized early in the development process and these aspects can be given sufficient attention in subsequent stages of the device's life cycle.  ``By controlling system security during architectural refinement, we can decrease software production costs and speed up the time to market~\cite{ZhouFoss2006}.''  This approach also enchances the role of the software architects by requiring that their decisions be not only for functional decomposition, but also for non-functional requirements fulfillment.  Hence, virtualization/automation of security development is not only effective but also enticing.
+As with any new system there should be `sufficient user documentation'.  Users should be provided with adequate documentation and other information such that they contribute to, rather than detract from, a system's security.  The availability of documentation and training can help to ensure a knowledgable cadre of users, developers, and administrators.  If any level of user does not know how to use a component properly, does not know the standard security procedures, or does not know the proper behavior to prevent social engineering attacks, then said user can easily introduce new system vulnerabilities.  Complexity must be minimized.  This point was touched upon earlier, but is just as valid from a documentation standpoint.  User documentation should also be kept as simple as possible to ensure adoptability by a larger group of new users.  Having complex user documention is problematic because if users are unable to understand how to implement/use a system they will refuse to use it, thus leading to the death of said system.  If on-line documentation is inadequate, then it should be obvious that written documentation and appropriate training are needed.
+Just as there is a reuirement for adequate documentation there is also the need for `procedural rigor'.  The rigor of the system's life cycle process should be commensurate with its intended trustworthiness.  Procedural rigor defines the depth and detail of a system's lifecycle procedures.  These rigors contribute to the assurance that a system is correct and free of unintended functionality in two ways.  Firstly, imposing a set of checks and balances on the life cycle process such that the introduction of unspecified functionality is thwarted.  Secondly, applying rigorous procedures to specifications and other design documents contribute to the ability of users to understand a system as it has been built, rather than being misled by inaccurate system representation, thus helping ensure that security and functional objectives of the system have been met.  Highly rigorous development procedures supporting high trustworthiness are costly to follow.  However, the lowered cost of ownership resulting from fewer flaws and security breaches during the product maintenance phase can help to mitigate the higher initial development costs associated with a rigorous life cycle process.  
+The reasoning for having procedural rigor and sufficient user documentation is to allow for `repeatable, documented procedures'.  Techniques used to construct a component should permit the same component to be completely and correctly reconstructed at a later time.  Repeatable and documented procedures support the creation of components that are identical to a component created earlier that may be in widespread use.  The Common Criteria standard~\cite{CommonCriteria} provides a framework for the derivation of system requirements that is comprised of the following steps: definition of system goals and its concept of operation; identification of threats to the defined system; identification of assumptions regarding the system and its environment; identification of organizational policies external to the system; identification of security objectives for the system and its environment based on previous steps; and specification of requirements that will meet the objectives.
+
+The last, and by no means least, important topic that must be tackled in this section is the question of what exactly are the research challenges.  There has been a lot of information, ideas, and principles presented over the course of this writing along with parallels to existing research and methodologies that can be almost directly applied to the concept of mapping security development to platform-based design.  The primary cost of developing security, and running a secure system, is time.  There are the monitary and hardware costs of security developement and implementation, but even those aspects all have a time cost coupled with them.  Time, while being the most expensive part of security design is also the aspect that can be tackled and minimized with rigorous planning and documentation.  Taking into account that even the development of documentation and standards also has its own time cost associated with it, this early phase development can also diminsh the time-cost impact for later steps in the system's development/implementation life-cycle.  Security must be paramount in design from the very beginning of any design and development cycle.
+
+While this paper proposes one model for security design and development this, by no means, is the only model for implementing security in a system.  ``Defense in depth''~\cite{DoD2002} is a model in which security is derived from the application of multiple mechanisms; to create a series of barriers against attack by an adversary.  Unfortunately, for the model, without any sound security architecutre and supporting theory, the non-constructive basis of this approach equivicates this model to a temporary patch; putting barriers in places does not equate to levels of trustworthiness.  The ``Balanced assurance''~\cite{Lunt1988}  model centers around a hierarchy of security policies, where different policies are allocated to different components of a system.  The concept is that the trustworthiness of a given component must be consistent with the importance of that component's policy; the greater the trustworthiness the greater the importance of that component.  The fault here is that a system can only be considered as secure as it's least secure component.  While an interesting model and shows promise with respect to specific scenarios, this is not an overarching model that will function in all cases.  There are multiple models for performing/implementing security, but a significant part of the cost of building a secure system is that of evaluating, and subsequently proving, trustworthiness through a third party's efforts.  A method for minimizing the costs of performing this evaluation is to make use of components that have already had their trustworthiness evaluated and verified, thereby minimizing the need to evaluate the system itself; as it is made of already trustworthy components.  This model would allow for ``evaluation by pieces'' whereby one acknowledges previously evaluated components and does not require their examiniation in the greater evaluation of the composite system.  Unfortunately, this model has only been made available to ``low assurance'' systems as it lacks a well-formed theory of correctness~\cite{Benzel2005}.
+
+Security design, development, verification, and evaluation is still a relatively new and unexplored space.  Because of this there is a constant growth and evolution of security protocols and standards, which requires a thorough exploration of the security design space.  It is the belief of this paper that the best model for focusing effort and development towards is a platform-based design for security development.  The levels of abstraction aid in virtualization design, the overarching concept of mapping platforms to instances (and vica-versa) aids in early developemtn stages, and the need for rigorous documentation and meticulous following of standards are concepts that not only stem from platform-based design but greatly lend to the needs of security design and development.
+\begin{itemize}
+\item \textbf{DRAW CONNECTIONS TO SECURITY DEVELOPMENT AND PBD TO SHOW HOW THESE TWO CAN BE MAPPED TOGETHER.  BE SURE TO STATE THE OBVIOUS!!! MAKE THE POINT OF THIS PAPER!}
 \end{itemize}
 
 \section{Conclusion}