600.436 High-Assurance Systems
We are in the process of writing this as you watch, so check back tomorrow if you find something confusing here.
Lectures can be found here.
The course will be divided into three parts. The first segment will provide models for software development processes and security assurance processes, and discuss how the two relate to each other. The goal of this segment is to define terms and establish structure for the remainder of the course.
The second phase will divide into two tracks. In the first, Dr. Shapiro will describe and examine the methods that are being used during the EROS research and development process to arrive at an assurable result. The emphasis of this track is to describe what was done, which does not always match the nominal requirements of current assurance standards.
In the second track, David Chizmadia will describe and examine both the currently accepted assurance standards (the Common Criteria) and his experiences in practice with creating such standards and applying them to several projects in two countries. The goal of this track is to identify what are good and bad practical development practices and processes for achieving high-assurance systems, and to learn how well the Common Criteria process in particular functions.
The third phase of the course will bring these two tracks back together, performing a comparative and critical examination of the two processes and the strengths and weaknesses of each. It will also identify research questions and opportunities in the area of assurance.
Assignments, Preparation, and Grading
Assignments in this course will include various readings, including significant examination of the EROS operating system code base, which we will use as an example software artifact. Students will be expected to author portions of the assurance case for EROS based on their examination.
It is expected that this course will have a final exam. We may revise this plan depending on how the projects go.
Students are expected to read the material in advance of the associated class meeting, and to participate actively in discussion of the subject matter. Coming to class prepared is a requirement, and the instructors reserve the right to make in-class quizzes a substantial portion of the overall grade if this should prove necessary.
Details of grading will appear here shortly, and will be presented in the first session.
|Week of||Topic(s) and Papers|
|10 Sep 2001||
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.
|17 Sep 2001||
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.
|24 Sep 2001||
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.
|1 Oct 2001||
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.
|8 Oct 2001||
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.
|15 Oct 2001||Fall Break. Please try not to actually break anything.|
|16 Oct 2001||
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.
|22 Oct 2001||
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.
|29 Oct 2001||
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.
|5 Nov 2001||
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.
|12 Nov 2001||
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.''
|19 Nov 2001||
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.
|26 Nov 2001||
To be filled in jointly.
|3 Dec 2001||
To be filled in jointly.
|10 Dec 2001||
Open issues and research opportunities.