Additions to PBDSec paper

Signed-off-by: Paul Wortman <paw10003@engr.uconn.edu>

PBDSecPaper.tex

@@ -185,13 +185,13 @@ Security design, development, verification, and evaluation is still a relatively
 
 \section{Conclusion}
 \label{Conclusion}
-There is a need for development of platform-based design for security elements of all types, across all platforms.  The mechanisms and procedures required are already in use, but this does not mean platform-based design for security already here.  For platform-based design of security there is an absolute need for standardization, or `contracts', for all elements that compose a larger distributed systems.  The reason being that without these `contracts' to clearly state the expectations of various inputs, and outputs, then there is no guarentee that any designs/developments will be able to harmonize with the rest of a complex system.  Additionally this is important for determining the trustworthiness of not only different elements, but of the entire distributed system as a whole.  Advantages of security mapped to PBD include swapping out old security modules with newer ones (re-use of base system), degree of system customization to meet system hardware/software needs, ease of development (and costs).  The most glaring disadvantages are those that come with the shifting of any paradigm.  As with any new shift in design methodoloy the largest cost in this new system would be the need for rigorous documentation and standardization of the process, components, and communication elements of said components.  This is why the development of groundwork for PBD-Security designs will be a slow and arduous process, but the resulting `paydirt' will be a new set of virtualization tools at abstraction levels with design spaces yet not truly explored at regualr levels.  The hope of this paper is to begin designing a frame work that pushes for not only better system design and development (PBD) but also for proper incorporation and planning of system security in an intelligent, rigorous and documented/standardized way.  As with the design of any tool there are concerns during the development, evaluations and valdiation processes~\cite{Pinto2006}.  Common pitfalls of development are mishandling corner cases and inadvertently misinterpreting changes in the communication semantics.  Problems arise because of poor understanding and the lack of precise, rigorous, definitions of the abstraction and refinement maps used in the design flow.  Abstraction and refinement should be designed to preserve, whenever possible, the properties of the design that have already been established (e.g. the 'contract' of the design).  With time will come rigorous standards and useful virtualaztion tools for thorough exploration of design spaces for both hardware and software elements.
+There is a need for development of platform-based design for security elements of all types, across all platforms.  The mechanisms and procedures required are already in use, but this does not mean platform-based design for security is already here.  For platform-based design of security there is an absolute need for standardization, or `contracts', for all elements that compose a larger distributed systems.  The reason being that without these `contracts' to clearly state the expectations of various inputs, and outputs, then there is no guarentee that any designs/developments will be able to harmonize with the rest of a complex system.  Additionally this is important for determining the trustworthiness of not only different elements, but of the entire distributed system as a whole.  Advantages of security mapped to PBD include swapping out old security modules with newer ones (re-use of base system), degree of system customization to meet system hardware/software needs, ease of development (and costs).  The most glaring disadvantages are those that come with the shifting of any paradigm.  As with any new shift in design methodoloy the largest cost in this new system would be the need for rigorous documentation and standardization of the process, components, and communication elements of said components.  This is why the development of groundwork for PBD-Security designs will be a slow and arduous process, but the resulting `paydirt' will be a new set of virtualization tools at abstraction levels with design spaces yet not truly explored at regualr levels.  The hope of this paper is to begin designing a frame work that pushes for not only better system design and development (PBD) but also for proper incorporation and planning of system security in an intelligent, rigorous and documented/standardized way.  As with the design of any tool there are concerns during the development, evaluations and valdiation processes~\cite{Pinto2006}.  Common pitfalls of development are mishandling corner cases and inadvertently misinterpreting changes in the communication semantics.  Problems arise because of poor understanding and the lack of precise, rigorous, definitions of the abstraction and refinement maps used in the design flow.  Abstraction and refinement should be designed to preserve, whenever possible, the properties of the design that have already been established (e.g. the 'contract' of the design).  With time will come rigorous standards and useful virtualaztion tools for thorough exploration of design spaces for both hardware and software elements.
 
 With these concepts in-mind, it should be obvious that security design \textbf{must} occur from the start!  Unless security design is incorporated apriori, a developer can only hope to spend the rest of the development processes, and beyond, attempting to secure a system that took security as optional.  Simply put, data \textbf{must} be kept safe.  In addition, performing security planning from the start allows for disaster planning and any other possible 'unforeseen' complications.
 
 Others are incorporating platform-based design in everything from image processing to implementing security across different domains~\cite{Lin2015}.  People are seeing the use and effectiveness of this sort of design methodology and it is the belief of this paper that more focus should be placed on this topic.  Platform-based design should be the basis for security design and development.
 
-The reference monitor seems a favorable choice as this sort of model is already used in distributed systems, but there is an extremely important need to maintain the security/trust/trustworthiness of this reference monitor (abstraction for necessary and sufficient features of component that enforces access controll in secure systems).  It is the belief of this paper that an initial starting point for PBD-Security design development is to use this existing reference monitor concept, along with other developed tools (e.g. CBSE, TPM), and piece together the initial framework and early phase development for this new methodology, so that future efforts can be spent developing and perfecting this technique.
+This paper can not be concluded without proposing a framework that is believed to be the jumping point for a security model to begin the adaptation of platform-based design into security development.  The reference monitor seems a favorable choice as this sort of model is already used in distributed systems, but there is an extremely important need to maintain the security/trust/trustworthiness of this reference monitor (abstraction for necessary and sufficient features of component that enforces access controll in secure systems).  While it should be immediately seen that there are faults with this design (e.g. single point of failure), do not allow these shortcomings to run your doubt. It is the belief of this paper that an initial starting point for PBD-Security design development is to use this existing reference monitor concept, along with other developed tools (e.g. CBSE, TPM), and piece together the initial framework and early phase development for this new methodology, so that future efforts can be spent developing and perfecting this technique.
 
 %references section
 %\bibliographystyle{plain}