Push of changes to PBDSec paper (finish edits over weekend for new dr…

…aft)

Signed-off-by: Paul Wortman <paul.mauddib28@gmail.com>

PBDSecPaper.tex

@@ -196,7 +196,7 @@ The issue of platform-based design is not so much an over-engineering of design/
 		\item Service - processing or protection provided by a component to users or other components. E.g., communication service (TCP/IP), security service (encryption, firewall).  These services represent the communication that occurs between different elements in a secure system.  Each service should be documented to rigorously define the input, and output, nets for each component and the method used for communication (buses, encrpytion, multiplexing).  Since these services, and their actions, are central to the operation/behavior of a secure system, there are a series of considerations, principles, and policies that a system architect/designer must acknowledge when deciding on the layout of security components within a network.
 		\item Principle of Secure Communication Channels - when composing a system where there is a threat to communication between components, each communications channel must be trustworthy to a level commensurate with the security dependencies it supports.  In other words, how much is the component trusted to perform its security functions by other components.
 			\begin{itemize}
-			\item Several techniques can be used to mititgate threats to the communication channels in use.  Use of a channel may be restricted by protecting access to it with suitable access control mechanism (e.g. reference monitor located beneath or within each component). \textit{\textbf{NOTE: MAKE SURE TO MENTION REFERENCE MONITOR BY THIS POINT}}  End-to-end communications technologies (e.g. encryption) may be used to eliminate security threats in the communication channel's physical environment.  Once again, the intrinsic characteristices assumed for and provided by the channel must be specified with such documentation that it is posisble for system designers to understand the nature of the channel as initially consturcted and to assess the impact of any subseruqnet changes to the system.  Without this rigorous documentation and standardization, the trustworthiness of the communications between security elements can not be assured.
+			\item Several techniques can be used to mititgate threats to the communication channels in use.  Use of a channel may be restricted by protecting access to it with suitable access control mechanism (e.g. reference monitor located beneath or within each component).  End-to-end communications technologies (e.g. encryption) may be used to eliminate security threats in the communication channel's physical environment.  Once again, the intrinsic characteristices assumed for and provided by the channel must be specified with such documentation that it is posisble for system designers to understand the nature of the channel as initially consturcted and to assess the impact of any subseruqnet changes to the system.  Without this rigorous documentation and standardization, the trustworthiness of the communications between security elements can not be assured.
 			\end{itemize}
 		\item Self-Reliant Trustworthiness - Systems should minimize their reliance on external components for system trustworthiness.  A corollary to this relates to the ability of a component to operate in isolation and then resynchronize with other components when it is rejoined with them.  In other words, if a system were required to maintain a connection with another external entity in order to maintain its trustworthiness, then that very system would be vulnerable to drop in connection/communication channels.  Thus from a network standpoint a system should be trustworthy by default with the external connection being used as a supplement to the component's function.
 			\begin{itemize}
@@ -217,7 +217,7 @@ The issue of platform-based design is not so much an over-engineering of design/
 		\item Having tackled the network communication considerations for modeling a secure and trustworthy component, this paper moves toward examining these security element behvaiors and functions with respect to their existence within a larger distributed system.
 		\item Trust (degree to which the user or a componenet depends on the trustworthiness of another component).
 		\item Hierarchical Trust for Components - Security dependencies in a system will form a partial ordering if they preserve the principle of trusted components.  This is essential to eliminate circular dependencies with regard to trustworthiness.  Trust chains have various manifestations but this should not prohibit the use of overly trustworthy components.
-		\item Hierarchical Protections - A component need not be protected from more trustworthy components.  In the most degenerate case of most trusted component, the component must protect itself from all other components.  One should note that a trusted computer system need not protect itself from an equally trustworthy user.  The main challenge here is that there needs to be a clear and documented way by which one can determine trustworthiness and protection for a system.  This is the same challenge that occurs at all levels and requires rigorous documentation to alleviate the constraint.  Hierarchical protections is the precept that regulates the following concept of `secure distributed composition'.
+		\item Hierarchical Protections - A component need not be protected from more trustworthy components.  In the most degenerate case of most trusted component, the component must protect itself from all other components.  One should note that a trusted computer system need not protect itself from an equally trustworthy user.  The main challenge here is that there needs to be a clear and documented way by which one can determine trustworthiness and protection for a system, along with outlining the hierarchy of trust that is inherent to the system.  This is the same challenge that occurs at all levels and requires rigorous documentation to alleviate the constraint.  Hierarchical protections is the precept that regulates the following concept of `secure distributed composition'.
 		\item Secure Distributed Composition - Composition of distributed components that enforce the same security policy should result in a system that enforces that policy at least as well as individualy components do.  If components are composed into a distributed system that supports the same policy, and information contained in objects is transmitted between components, then the transmitted information must be at least as well protected in the receiving component as it was in the sending component.  This is similar behavior to how SSL/TLS are used in current day implementations; data may be secure in transit, but if the end points are not secure then the data is not secure either.  To ensure correct system-wide level of confidence of correct policy enforcement, the security architecture of distributed composite system must be thoroughly analyzed.
 		\item Accountability and Traceability - Actions that are security-relevant must be traceable to the entity on whose behalf the action is being taken.  This requires the designer to put into place a trustworthy infrastructure that can record details about actions that affect system security (e.g., audit subsystem).  This system must not only be able to uniquely identify the entity on whose behalf the action is being carried out, but also record the relevant sequence of actions that are carried out.  An accountability policy ought to require the audit trail itself to be protected from unauthorized access and modifications.  Associating actions with system entities, and ultimately with users, and making the audit trail secure against unauthorized access and modifications provide nonrepudiation, as once some action is recorded, it is not possible to change the audit trail.  Any designer should note that if a violation occurs, analysis of the audit log may provide additional infomraiton that may be helpful in determinging the path or component that allowed the violation of the security policy.  Just as this audit trail would be invaluable to a debugging developer, an attacker could also use this information to illuminate the actions/behavior of the system; therefore this data absolutely must remain protected.
 		\item Continuous Protection on Information - Information protection required by a security policy (e.g., access control to user-domain objects) or for system self-protection (e.g., maintining integrity of kernel code and data) must be protected to a level of continuity consistent with the security policy and the security architecture assumptions.  Simpley stated, no guarentees about information integrity, confidentiality or privacy can be made if data is left unprotected while under control of the system (i.e., during creation, storages, processing or communication of information and during system initialization, execution, failure, interruption, and shutdown); one cannot claim to have a secure system without remaining secure for all aspects of said system.  For maintaining a trustworthy system, and network of distributed truthworhty components, a designer should not only prepare for expected inputs but also for possible invalid requests or malicious mutations that could occur in the future.  Invalid requests should not result in a system state in which the system cannot properly enforce the security policy.  The earlier mentioned concept of secure failure applies in that a roll back mechanism can return the system to a secure state or at least fail the component in a safe and secure manner that maintains the required level of trustworhiness (does not lower the overall trustworthiness of the entire distributed system).  Furthermore, a designer can use the precepts of a reference monitor to provide continuous enforcement of a security policy, noting that every request must be validated, and the reference monitor must protect iteself.  Ideally the reference monitor component would be ``perfect'' in the sense of being absolutely trustworthy and not requiring an upgrade/modification path (thus limiting this element's chance of becoming compromised). 
@@ -241,7 +241,7 @@ The issue of platform-based design is not so much an over-engineering of design/
 \item Mapping of Security onto PBD structure
 	\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 ``...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 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.''~\cite{ZhouFoss2006}
+	\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
@@ -257,6 +257,7 @@ The issue of platform-based design is not so much an over-engineering of design/
 		\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.
 	\begin{itemize}