diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex index bba6160..30d63bf 100644 --- a/PBDSecPaper.tex +++ b/PBDSecPaper.tex @@ -89,10 +89,10 @@ \end{itemize} \end{abstract} -\section{Previous Work} -\label{Previous Work} +\section{Motivation} +\label{Motivation} \begin{itemize} -\item As systems move towards more and more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic changes to these designs becomes exponentially more difficult. For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development. +\item As systems move towards more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic changes to these designs becomes exponentially more difficult. For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development. \begin{itemize} \item Use of system-on-chip (SoC) to replace multi-chip solutions. \begin{itemize} @@ -104,8 +104,6 @@ \section{Previous Work} \item \textbf{\textit{Add something about previous security work; taxonomy?}} \end{itemize} -\section{Considerations} -\label{Considerations} \begin{itemize} \item What standardization is important, why is it important? \begin{itemize} @@ -116,6 +114,9 @@ \section{Considerations} \item Fully spcified set of buses (ISA, USB, PCI) - use same xplansion boards of IC's for different products \item Full specification of a set of IO devices - keyboard, mouse, audio and video devices \item Software can also be developed independently of the new hardware availability, thus offering a real hardware-software codesign approach + \begin{itemize} + \item \textbf{Note:} ``If the instruction set architecture (ISA) is kept constant, then software porting is much easier.''~\cite{Vincentelli2002} + \end{itemize} \end{itemize} \item System Domain: Aspect of the capabilities a platform offeres to develop quickly new applications \begin{itemize} @@ -123,9 +124,6 @@ \section{Considerations} \end{itemize} \item So why is standardization useful? Standardization allows for manufacturers, system developers, and software designers to all work around a single, accepted, platform. It is understood what the capabilities of the hardware are, what the limitations of system IO will be, along with what the methods/protocols of communication will be. Even these preset aspects of the `standard' have their own `contractual obligations' of how they will function, what their respective `net-lists' are, and where the limtations of such standards lie. While the act of creating a standard takes time, not only due to time of development but due to speed of adoption of wide use, it is a necessary step. Without it, it becomes far more difficult to create universally used complex systems, let alone validate their correctness and trustworthiness. \item ``Indeed, market data indicate that more than 80\% of system development efforts are now in software versus hardware. This implies that an effective platform has to offer a powerful design environment for software to cope with development cost.''~\cite{Vincentelli2002} - \begin{itemize} - \item \textbf{Note:} ``If the instruction set architecture (ISA) is kept constant, then software porting is much easier.''~\cite{Vincentelli2002} - \end{itemize} \end{itemize} \item Where do we gain/lose on shifting the method of design. Development of these tools implies that there is a need to change the focus and methods of design/development\textbf{[Add Quo Vadis paper citation here]}. \begin{itemize} @@ -210,19 +208,14 @@ \section{Security} \begin{itemize} \item Evolving with time and understanding as knowledge of encryption and other security encapsulation techniques. There are considerations that are accounted from a software standpoint: capabilities of the software, speed of the algorthims/actions that take place, and how unique (level of uniqueness) a given solution is. Similarly there are hardware considerations as well: tolerance of the chip elements in use, their capabilities, power distribution over the entire hardware design, signal lag between different elements, and cross-talk caused by communication channels. \item Trusted Computing Group (TCG) created Trusted Platform Modules (TPM) which are able to validate their own functionality and if they have been tampered with. This is, in essence, a method of `self-analysis'; thus the ground work for a `self-analyzing' security component is already in place. This self checking can be used as a method for allowing the larger system of security components to locate damaged/error-prone componenets so that they can be replaced/fixed thus raising the overall trustworthiness of the system of components. -\item The definition of ``trustworthiness'' that is chosen to help color this perspective on security is as defined in the Benzel et.~al.~paper. \begin{quotation} +\item The definition of ``trustworthiness'' that is chosen to help color this perspective on security is as defined in the Benzel et.~al.~paper. +\begin{quotation} ``\textit{Trustworthy} (noun): the degree to which the security behavior of the component is demonstrably compliant with its stated functionality (\textit{e.g., trustworthy component}). \\ \textit{Trust}: (verb) the degree to which the user or a component depends on the trustworthiness of another component. For example, component A \textit{trusts} component B, or component B is \textit{trusted} by component A. Trust and trustworthiness are assumed to be measured on the same scale.''~\cite{Benzel2005} \end{quotation} \begin{itemize} \item Dependability is a measure of a system's availability, reliability, and its maintainability. Furthermore, Avizienis et.~al.~extends this to also encompass mechanisms designs to increase and maintain the dependability of a system~\cite{Avizienis2004}. For the purpose of this paper, the interpretation is that trustworthiness requires inherrent dependability; i.e. a user should be able to trust that trustworthy components will dependably perform the desired actions and alert said user should an error/failure occur. - \item How does one measure trust? - \begin{itemize} - \item Unfortunately the measurement of trust(worthiness) is measured by the same, abstract scale~\cite{Benzel2005}. Thus, in turn, there is a void for the design and development of an understandable and standardized scale of trust(worthiness). Which could then lead to a change of paradigm in the methods by which security policies, mechanisms, and principles are implemented and evolve. - \end{itemize} - \item ``In order to develop a component-based trustworthy system, the development process must be reuse-oriented, component-oriented, and must integrate formal languages and rigorous methods in all phases of system life-cycle.''~\cite{Mohammed2009} - \begin{itemize} - \item Component-Based Software Engineering (CBSE) is widely adopted in the software industry as the mainstream approach to software engineering~\cite{Mohammed2009}. - \end{itemize} + \item Unfortunately the measurement of trust(worthiness) is measured by the same, abstract scale~\cite{Benzel2005}. Thus, in turn, there is a void for the design and development of an understandable and standardized scale of trust(worthiness). Which could then lead to a change of paradigm in the methods by which security policies, mechanisms, and principles are implemented and evolve. + \item ``In order to develop a component-based trustworthy system, the development process must be reuse-oriented, component-oriented, and must integrate formal languages and rigorous methods in all phases of system life-cycle.''~\cite{Mohammed2009} Component-Based Software Engineering (CBSE) is widely adopted in the software industry as the mainstream approach to software engineering~\cite{Mohammed2009}. CBSE is a reuse-based approach of defining, implementing and composing loosely coupled independent components into systems and emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. Thus it can be seen that the ideals being outlined in this paper are already in use, all that is needed is their re-application to a new design methodology. \item ``Most prevalent trust models only focus on assessing trustworthiness of systems at runtime, and do not provide necessary predictions of the trust of systems before they are built. This makes imporving trustworthiness of the composed system to be costly and time-consuming. Therefore it is important to consider trust of the composed software system at the development time itself.''~\cite{Gamage} \end{itemize} \item Scopes of security/trustworthiness @@ -253,6 +246,10 @@ \section{Security} \item ``...allows security concerns to be recognized early in the development process and can be given sufficient attention in subsequent stages. By controlling system security during architectural refinement, we can decrease software production costs and speed up the time to market. This approach aslo 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.''~\cite{ZhouFoss2006} \item Apply here ideas of Sufficient User Documentation, Procedural Rigor, Repeatable, Documented Procedures. \end{itemize} +\item What are the research challeneges? + \begin{itemize} + \item How to put cost on security? How to make models? What is high vs. low? (Are there models that exist?) + \end{itemize} \end{itemize} \section{Conclusion} @@ -265,16 +262,9 @@ \section{Conclusion} \item Advantages: swap out old security modules with newer ones (re-use of base system), degree of system customization to meet system hardware/software needs \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 true 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 Concerns during development:~\cite{Pinto2006} - \begin{itemize} - \item Common pitfalls are mishandling corner cases and inadvertently misinterpreting changes in the communication semantics - \item Problems arise because of poor understanding and the lack of precise definitions of the abstraction and refinement maps used in the flow - \begin{itemize} - \item Abstraction and refinement should be designed to preserve, whenever possible, the properties of the design that have already been established - \end{itemize} - \end{itemize} -\item Include Security Design from the Start!!! -\item 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). +\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. +\item 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. \end{itemize} %references section