From 05b5ef0f9e6b1ff7e7c6aaa004877abb04aa386b Mon Sep 17 00:00:00 2001 From: Paul Wortman Date: Mon, 6 Jul 2015 21:53:19 -0400 Subject: [PATCH] More edits --- PBDSecPaper.tex | 62 +++++++++++++++++++++++++++++++++++++------------ 1 file changed, 47 insertions(+), 15 deletions(-) diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex index d52dc7b..11dd3eb 100644 --- a/PBDSecPaper.tex +++ b/PBDSecPaper.tex @@ -100,6 +100,7 @@ \section{Previous Work} \item Use of SoC to handle encryption/security in a secure and removed manner. \end{itemize} \end{itemize} +\item ``However, even though current silicon technology is closely following the growing demands; the effort needed in modeling, simulating, and validating such designs is adversely affected. This is because current modeling tools and frameworks, hardware and software co-design environments, and validation and verification frameworks do not scale with the rising demands.''`\cite{Patel2007} \end{itemize} \section{Considerations} @@ -206,20 +207,16 @@ \section{Platford-based design} \section{Security} \label{Security} \begin{itemize} -\item Software: capabilities, speed, uniqueness +\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} +``\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 - \end{itemize} -\item Hardware: tolerance, capabilities, power distribution, signal lag, cross-talk - \begin{itemize} - \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. - \end{itemize} -\item How to define ``trustworthiness''? - \begin{itemize} - \item Differentiate between trustworthy and dependable + \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 Arbitrary scale of trust; needs to be understandable/standardized + \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} @@ -230,8 +227,17 @@ \section{Security} \item Scopes of security/trustworthiness \begin{itemize} \item Local (self) + \begin{itemize} + \item The local scope encompasses a security elements own abilities, trustworthiness, and the dependencies of that element (e.g. least common mechanisms, partially ordered dependencies, reduced complexity, minimized sharing (and the conflict between this as least common mechanisms). + \end{itemize} \item Network (communication) + \begin{itemize} + \item How to elements communicate? Rigorous definition of input/output nets for componenets and the methods for communication (buses, encryption, multiplexing). Self-Reliant Trustworthiness, Trusted Communication Channels, Secure System Evolution. Dealing with Failure, Secure Failure. + \end{itemize} \item Within distributed system + \begin{itemize} + \item Trust (degree to which the user or a componenet depends on the trustworthiness of another component). Hiearchical Trust for components, hierarchical protections, Secure Distributed Composition. Accountability and Traceability, Continuous Protection on Information, Secure System Modification. + \end{itemize} \end{itemize} \item Automation of security development \begin{itemize} @@ -243,7 +249,8 @@ \section{Security} \item Mapping of Security onto PBD structure \begin{itemize} \item ``Despite occasional cryptology-related attacks, most seucirty 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 ``...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 ``...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} \end{itemize} @@ -251,9 +258,22 @@ \section{Conclusion} \label{Conclusion} \begin{itemize} \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: 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, 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 developemtn (PBD) but alos 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). \end{itemize} %references section @@ -271,11 +291,11 @@ \section{Conclusion} \bibitem{Lang2003} Ulrich Lang, \emph{Access policies for middleware}, University of Cambridge (May 2003) -\bibitem{Vincentelli2002} Alberto Sangiovanni-Vincentelli, -\emph{Defining platform-based design}, http://www.eetimes.com/document.asp?doc\_id=1204965 +\bibitem{Vincentelli2002} Alberto Sangiovanni-Vincentelli, \emph{ +Defining platform-based design}, http://www.eetimes.com/document.asp?doc\_id=1204965 \bibitem{Keutzer2000} Kurt Keutzer, Sharad Malik, A.~Richard Newton, Jan M.~Rabaey, and A.~Sangiovanni-Vincentelli, -\emph{System-Level Design: Orthogonalization of Concerns and Platform-Based Design}, Computer-Aided Design of Integrated Circuits and Systems (Dec 2000) +\emph{System-Level Design: Orthogonalization of Concerns and Platform-Based Design}, Computer-Aided Design of Integrated Circuits and Systems (December 2000) \bibitem{Mohammed2009} Mubarak Sami Mohammad, \emph{A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems}, Doctoral Dissertation (April 2009) @@ -289,6 +309,18 @@ \section{Conclusion} \bibitem{Gamage} Dimuthu U.~Gamage, Lahiru S.~Gallege, James H.~Hill, and Rajeev R.~Raje, \emph{Trust of Composition of System Properties} +\bibitem{Patel2007} Hiren D.~Patel, \emph{ +Ingredients for Successful System Level Automation \& Design Methodology}, Dissertation (April 2007) + +\bibitem{Pinto2006} Alessandro Pinto, Alvise Bonivento, Alberto L.~Sangiovanni-Vincentelli, Roberto Passerone, Marco Sgroi, \emph{ +System Level Design Paradigms: Platform-Based Design and Communication Synthesis}, ACM TODAES (July 2006) + +\bibitem{Benzel2005} Terry V.~Benzel, Cynthia E.~Irvine, Timothy E.~Levin, Ganesha Bhaskara, Thuy D.~Nguyen, and Paul C.~Clark, \emph{ +Design Principles for Security}, SecureCore Technical Report (September 2005) + +\bibitem{Avizienis2004} Algirdas Avi\v{z}ienis, Jean-Claude Laprie, Brian Randell, and Carl Landwehr, \emph{ +Basic Concepts and Taxonomy of Dependable and Secure Computing}, IEEE Transactions on Dependable and Secure Computing (October 2004) + \end{thebibliography} \end{document}