Use-Cases for Security Assurance

Overview of key ideas/goals in security: confidentiality, availability, integrity. Definition of ``assurance.'' Security as a process (and not a technology). Role of context in establishing/understanding secure systems. Threat modeling and risk analysis. Role and limits of (computer) security policies. Identification of key open issues in assurance.

Process Model for Software Construction

Phases of the software development process, and relationship of these phases to security assurance. Role and limitations of formal models, architecture, validation, conventional Q/A. Differences between the alleged process and the actual practice. Timing tradeoffs: cost and benefits of post-hoc process. Social dynamics of successful complex system development teams, and relevance of this dynamic to software integrity. Non-scalability of human communication, and implications for high-assurance system development.

Process Model for Assurance Evaluation

Goals of an evaluation. Relationship to social/legal context. Model of evaluation: role of protection profiles (PPs), targets of evaluation (TOEs), and evidentiary artifacts. The idea of the protection profile as a ``currency'' system for security. Consequential importance of a normative lexicon. The importance of reproducibility in a fundamentally subjective process, and its implications. Phases of an assurance evaluation and the relationship of these phases to phases of software development. Issues in preserving assurance levels over the lifecycle maintainance of the TOE.

David to fill this in.

Security objectives for EROS. Usage and environmental assumptions. High-level threat model. Assumptions concerning operator intervention. Trust relationships between user, developer, administrator and how this differs from conventional systems. Respective roles of mandatory and discretionary policies, and intentional limitations on the authority of operators and administrators. Expected development model.

The Common Criteria has an implicit expectation that higher assurance systems are designed rather than grown. This assumption is reflected in the assurance requirements for various levels of design documentation. The most abstract levels in the CC are the Security Policy Model and the High-Level Security Architecture. The goal of these documents is to push the developer to understand and document how, exactly, the TOE provides useful mission function while meeting the constraints of the Security Target. For the evaluator, these documents show how the TOE as seen at its external interfaces exposes the required functions.

EROS: Overview of the EROS system architecture. Divisions of security responsibilities among the system components. Identification of the Universal Trusted Computing Base and the EROS security kernel. Basic argument for why this security kernel supports the security objectives for the system. Component basis for system structure and argument for why this design basis facilitates an appropriate tradeoff between system flexibility and assurance.

Having described the TOE from the outside at its external interfaces, the next logical step in the documentation trail is to explain how the functions at those interfaces are provided. This is the role of the high-level design, which explains the operation of the security mechanisms that provide the security functions. These mechanisms are described both in terms of the interfaces that use them, the algorithms and data structures that are used, and the parameters to those algorithms.

EROS: Design, documentation and testing practices for EROS development. Discussion of an example component's documentation. Description of what portions of the software this description drives, and to what degree the derivation from the documentation is automated. Testing practices, both current and anticipated. Argument for why these testing practices are adequate for security assurance. Weaknesses in testing performed to date. Identification of key tools, the limits these have imposed on the development process, and what we are doing about it.

While it would be easiest if each mechanism were implemented once, performance and reliability considerations require that most systems replicate, specialize, and sometimes consolidate mechanisms for specific mission functions. This gives rise to a final stage in the documentation trail that traces each mechanism to all of the places where it is implemented. From an assurance perspective, this allows the consistency of the implementations with both each other and with the planned design to be checked by an evaluator.

EROS: Mechanisms for information and performance isolation. Degree of current implementation and anticipated results of in-progress work. Specific discussion of storage allocator and the realization of the confinement mechanism. Approach to building reference monitors. Use of confinement as a universal tool for hierarchically composable security policies. Implications of fault isolation and protected components for system testing and evolution. Testing metrics and the failure of black box methods in the field.

While the previous set of documents are largely internal to the development team, the CC also recognizes that documentation describing the secure operation of the system is also necessary if there is to be any real system security beyond the controlled evaluation environment. Thus, the CC also has specific requirements for the existence of operational documentation that is consistent with the internal documentation from the system design.

EROS: Sessions, authentication, and bootstrap. Object namespaces and (limitations on) authority propagation. Tensions and contradictions between security and audit; EROS policy and rationale concerning audit.

To provide an empirical check that the system described in the developer documentation actual works, the CC also requires that the developer conduct extensive test of the system at its interfaces and make the results of the tests available for inspection. The CEM also requires that the evaluators be able to regenerate the TOE from its sources and run some or all of the developer tests - as well as any of their own.

EROS: Kernel design. Normative specification approach, modeling, kernel control flow structure. Architectural layering of the kernel implementation as seen (a) from the perspective of the specification and (b) from the perspective of the actual implementation. The notion of atomic units of operation. Bounds on per-invocation resource use and recursion. Assertion checking and (limits on) decomposability of correctness analysis. Argument for why this or comparable system structure is essential to reduce analytic and implementation complexity.

In addition to the basic functional testing, there is also a CC notion that - especially at higher levels of assurance - the TOE should be subjected to unconstrained stress to validate that the full collection of functions is able to withstand attacks that are only partially expected but eventually possible. This includes penetration testing and (for multi-compartment system) covert channel analysis and testing.

EROS: The impact and relevance of open source on EROS assurance. Costs and benefits of publicly exposed development. Implications for the ``balance of power'' between user and developer w.r.t. assurance and confidence. Risks of open source w.r.t. assurance. The truth and falsehood of Eric Raymond's assertion that ``with enough eyeballs, all bugs are shallow.''

The development and maintenance processes are also subject to review and inspection, so a developer must also document and then follow a well defined process for managing the design, construction and evolution of the system.

EROS: Where the development process is going, why, and expected impact on assurance. Critical holes in the process as we perceived them prior to the start of the course.

To be filled in jointly.

To be filled in jointly.

Open issues and research opportunities.