From ecfe4cf877f6003654304e14ce82941bd9757e10 Mon Sep 17 00:00:00 2001 From: Paul Wortman Date: Thu, 16 Jul 2015 17:07:30 -0400 Subject: [PATCH] More edits to the security section of the paper Signed-off-by: Paul Wortman --- PBDSecPaper.tex | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex index 856393c..cce9841 100644 --- a/PBDSecPaper.tex +++ b/PBDSecPaper.tex @@ -189,7 +189,7 @@ \section{Security} \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). - \item Service - processing or protection provided by a component to users or other components. E.g., communication service (TCP/IP), security service (encryption, firewall) + \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 security dependencies it supports. In other words, how much it is 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. @@ -211,14 +211,22 @@ \section{Security} \item Hierarchical Protections - 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. \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. To ensure correct system-wide level of confidence of correct policy enforcement, the security architecture of dsitributed 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 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. - \item Continuous Protection on Information - Information protection required by 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 continueity consistent with the security policy and the security architecture assumptions. Simpley stated, no guarentees about information integrity, configentiality 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 security policy, noting that every request must be validated, and the reference monitor must protect iteself. Ideally the reference monitor component would ``perfect'' in the sense of being absolutely trustworthy and not requiring an upgrade/modification path (thus limiting this element's chance of becoming compromised). + \item Continuous Protection on Information - Information protection required by 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 continueity consistent with the security policy and the security architecture assumptions. Simpley stated, no guarentees about information integrity, configentiality 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 security policy, noting that every request must be validated, and the reference monitor must protect iteself. Ideally the reference monitor component would ``perfect'' in the sense of being absolutely trustworthy and not requiring an upgrade/modification path (thus limiting this element's chance of becoming compromised). + \begin{itemize} + \item Any designer must ensure protection of the system by choosing interface parameters so that security critical values are provided by more trustworthy components. To eliminate time-of-check-to-time-of-use vulnerabilities the system's security-relevant operations should appear atmoic. + \item It could also be desirable to allow system security policies to be ``modifiable'' at runtime; in the case of needing to adjust to catastrophic external events. Any changes to security policies must not only be traceable but also verifiable; it must be possible to verify that changes do not violate security policies. Following this thread of thinking, a system architect/designer should understand the consequences of allowing modifiable policies within the system. Depending on the type of access control and actions that are allowed and controlled by policies, certain configuration changes may lead to inconsistent states of discontinuous protection due to the complex and undecidable nature of the problem of allowing runtime changes to the security policies of the system. + \end{itemize} + \item Secure System Modification - System modification procedures must maintain system security with respect to goals, objectives, and requirements of owners. Without proper planning and documentation, upgrades and modifications to systems can transform a secure system into an insecure one. \end{itemize} \end{itemize} \item Automation of security development \begin{itemize} - \item Security Mechanisms - system artifacts that are used to enforece system security policies. - \item Security Principles - guidelines or rules that when followed during system design will aid in making the system secure. - \item Security Policies - organizational security policies are ``the set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information.'' System Security Policies are rules that the information system enforces relative to the resources under its control to reflect the organizational security policy. + \item When automating the development of security systems there are three key elements of the system that need to be examined/accounted for in the virtualization stage: security mechanisms, security principles, and security policies. + \begin{itemize} + \item Security Mechanisms - system artifacts that are used to enforece system security policies. + \item Security Principles - guidelines or rules that when followed during system design will aid in making the system secure. + \item Security Policies - organizational security policies are ``the set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information.'' System Security Policies are rules that the information system enforces relative to the resources under its control to reflect the organizational security policy. + \end{itemize} \item Could have security elements that attempt to optimize themselves to the system they are in based on a few pivot points (power, time, efficiency, level of randomness). Another option for the automated tool could trade out specific security components as an easier way to increase security without requireing re-design/re-construction of the underlying element. There is always the requirement that the overall trustworthiness of a new system must meet the standards of the security policies that `rule' the system. \item Virtualization should be used for exploring the design space, as it is hoped that it is obvious as to why. Not only is the cost of prototyping incredably expensive, but redesign is equally costly. Virtualization aids by removing the need for a physical prototyping (less monitary costs) and allows for more rapid exploration of the full design space. While the design time for such powerful tools will be expensive (both in monitary and temporal costs), the rewards of developing, validating, and evaluating this virtualization tool will offset the early design phase costs of an automation of security component design. \end{itemize}