SPARTA ISSO

Finished Projects

Secure Execution Environments

Access Control For Distributed Systems

Presentation for Panel on High Assurance Systems

ARPA Joint PI Meeting
Ft. Lauderdale, Florida
July 13, 1995

Strategies, Principles, and Observations

INTRODUCTION

  • Summarize Key Ideas Underlying High Assurance Secure Systems
  • Provide Perspective Regarding Potential Use for Other Kinds of Systems
    • Ideas Couched in General Terms with Secure Systems as Examples
    • Observations and Caveats

1. IDENTIFY/DEFINE "MOST CRITICAL" OVERALL OBJECTIVES

  • If You Can't Define What "Security" Means, You Won't Get it (Landwehr)
    • Principle of Separation of Concerns (Dijkstra), i.e., Segregate Security from Other Requirements
    • Develop Precise Statement of Critical Objectives, e.g., "Security Policy"
    • Augment via Mathematical Model(s), but…
      • A Model Is Necessarily Incomplete
      • A Model Should Be a "Means" Not an "End"
  • Prioritize Conflicting Critical Requirements, i.e.
    • Multilevel Security vs Information Consistency, Reliable Delivery
    • Privacy/Anonymity vs Accountability

2. KNOW WHICH SOFTWARE COMPONENTS YOU RELY ON; SEGREGATE AND PROTECT THEM

  • Define Assurance Boundary (Security Perimeter)
    • Trusted Computing Base (TCB)
  • Trusted Components Must Not Depend on Untrusted Components
  • Trusted Components Must Reside in Separate Address Space and Be Protected from Tampering

3. MINIMIZE COMPLEXITY AND SIZE OF TRUSTED SOFTWARE

  • Potential Assurance Inversely Proportional to Component Size and Complexity, e.g., Security Kernel
  • Issue: Not All Important System Behavior Cannot Be Localized; May Need Multiple Assurance Boundaries
  • Analyze and Simplify "Trust" Dependencies among Trusted Components
    • Utilize Hierarchical Layering
    • Most Critical Components at Bottom
    • Ensure That Critical Components Cannot Be Bypassed

4. DESIGN DEFENSIVELY

  • There Will Be Bugs and User/Administrator Errors!
  • Organize Trusted Components into Multiple Address Spaces, e.g., TMach TCB
  • Principle of Least Privilege (Saltzer, Schroeder)
  • Use Multiple (Possibly Redundant) Layers of Protection, e.g., Internet Firewall
  • Defensive Human Engineering
    • Establish Fail-Safe Defaults
    • Users Will Undermine Security Mechanisms If They Are Onerous

5. FOCUS OTHER ASSURANCE EFFORTS ON MOST CRITICAL COMPONENTS

  • Principle of Balanced Assurance (Lunt, Schell, et al) - Degree of Assurance Needed Is Proportionate to Component Risk/Criticality
    • Need Traceability of Critical Requirements
    • Concentrate Analysis, Reviews, Testing on Most Critical Requirements, Components
  • Challenge: Prioritizing and Localizing Critical System Behavior

6. ADOPT A DISCIPLINED DEVELOPMENT METHODOLOGY

  • Disciplined Software Engineering Is the Foundation
  • Special Practices for High Assurance Must Be:
    • Integrated with Ordinary Development Practices
    • Comprehensible and Relevant to Implementers
  • Issue: "Secure Enough" Is a Judgement. Better Assurance Metrics Are Needed

CLOSING REMARKS

  • There Is No "Silver Bullet", but the Secure Systems Approach Offers Useful Strategy and Principles for Other High Assurance Realms
    1. Define/Prioritize Critical Objectives
    2. Know What Software You must Trust
    3. Minimize its Size and Complexity
    4. Design Defensively
    5. Focus Assurance Efforts on Critical Components
    6. Adopt a Disciplined Methodology
  • High Assurance Takes Longer, Costs More Initially
  • Will High-Assurance General-Purpose COTS Products Emerge?