Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Additions to the conclusion section
	- Needs to finalize conclusion
		- Restate purpose of paper at the start of the conclusion section

Signed-off-by: Paul Wortman <paul.mauddib28@gmail.com>
  • Loading branch information
paw10003 committed Aug 27, 2015
1 parent 011b2cb commit 0dfbfde
Showing 1 changed file with 6 additions and 13 deletions.
19 changes: 6 additions & 13 deletions PBDSecPaper.tex
Expand Up @@ -185,19 +185,12 @@ Security design, development, verification, and evaluation is still a relatively

\section{Conclusion}
\label{Conclusion}
\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!}
\item Need for development of platform-based design for security elements of all types
\begin{itemize}
\item Need for standardization, or `contracts', for all elements that compose a larger distributed systems. Reason being: 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.
\end{itemize}
\item Advantages of security mapped to PBD: swap 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).
\item 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.
\item This is why the development of groundwork for PBD-Security designs will be a slow and arduous work, 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.
\item 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).
\item 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.
\item 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.
\end{itemize}
\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!}

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 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. 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.


%references section
%\bibliographystyle{plain}
Expand Down

0 comments on commit 0dfbfde

Please sign in to comment.