DoD 5200.28-STD
                                                                    Supersedes
                                                 CSC-STD-00l-83, dtd l5 Aug 83
                                                          Library No. S225,7ll









                        DEPARTMENT OF DEFENSE STANDARD




                                 DEPARTMENT OF

                                    DEFENSE

                               TRUSTED COMPUTER

                               SYSTEM EVALUATION

                                   CRITERIA




















                                 DECEMBER l985


                                                             December 26, l985 

                                   FOREWORD


This publication, DoD 5200.28-STD, "Department of Defense Trusted Computer
System Evaluation Criteria," is issued under the authority of an in accordance
with DoD Directive 5200.28, "Security Requirements for Automatic Data
Processing (ADP) Systems," and in furtherance of responsibilities assigned by
DoD Directive 52l5.l, "Computer Security Evaluation Center."  Its purpose is to
provide technical hardware/firmware/software security criteria and associated
technical evaluation methodologies in support of the overall ADP system
security policy, evaluation and approval/accreditation responsibilities
promulgated by DoD Directive 5200.28.

The provisions of this document apply to the Office of the Secretary of Defense
(ASD), the Military Departments, the Organization of the Joint Chiefs of Staff,
the Unified and Specified Commands, the Defense Agencies and activities
administratively supported by OSD (hereafter called "DoD Components").

This publication is effective immediately and is mandatory for use by all DoD
Components in carrying out ADP system technical security evaluation activities
applicable to the processing and storage of classified and other sensitive DoD
information and applications as set forth herein.

Recommendations for revisions to this publication are encouraged and will be
reviewed biannually by the National Computer Security Center through a formal
review process.  Address all proposals for revision through appropriate
channels to:  National Computer Security Center, Attention:  Chief, Computer
Security Standards.

DoD Components may obtain copies of this publication through their own
publications channels.  Other federal agencies and the public may obtain copies
from:  Office of Standards and Products, National Computer Security Center,
Fort Meade, MD  20755-6000, Attention:  Chief, Computer Security Standards.




_________________________________

Donald C. Latham
Assistant Secretary of Defense
(Command, Control, Communications, and Intelligence)


                               ACKNOWLEDGEMENTS


Special recognition is extended to Sheila L. Brand, National Computer Security
Center (NCSC), who integrated theory, policy, and practice into and directed
the production of this document.

Acknowledgment is also given for the contributions of: Grace Hammonds and
Peter S. Tasker, the MITRE Corp., Daniel J. Edwards, NCSC, Roger R. Schell,
former Deputy Director of NCSC, Marvin Schaefer, NCSC, and Theodore M. P. Lee,
Sperry Corp., who as original architects formulated and articulated the
technical issues and solutions presented in this document; Jeff Makey, formerly
NCSC, Warren F. Shadle, NCSC, and Carole S. Jordan, NCSC, who assisted in the
preparation of this document; James P. Anderson, James P. Anderson & Co.,
Steven B. Lipner, Digital Equipment Corp., Clark Weissman, System Development
Corp., LTC Lawrence A. Noble, formerly U.S. Air Force, Stephen T. Walker,
formerly DoD, Eugene V. Epperly, DoD, and James E. Studer, formerly Dept. of
the Army, who gave generously of their time and expertise in the review and
critique of this document; and finally, thanks are given to the computer
industry and others interested in trusted computing for their enthusiastic
advice and assistance throughout this effort.



                                   CONTENTS


          FOREWORD. . . . . . . . . . . . . . . . . . . . . . . . . . . .i

          ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . ii

          PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . .v

          INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . .1


                             PART I:  THE CRITERIA

          1.0  DIVISION D:  MINIMAL PROTECTION. . . . . . . . . . . . . .9

          2.0  DIVISION C:  DISCRETIONARY PROTECTION. . . . . . . . . . 11
               2.1   Class (C1):  Discretionary Security Protection . . 12
               2.2   Class (C2):  Controlled Access Protection. . . . . 15

          3.0  DIVISION B:  MANDATORY PROTECTION. . . . . . . . . . . . 19
               3.1   Class (B1):  Labeled Security Protection . . . . . 20
               3.2   Class (B2):  Structured Protection . . . . . . . . 26
               3.3   Class (B3):  Security Domains. . . . . . . . . . . 33

          4.0  DIVISION A:  VERIFIED PROTECTION . . . . . . . . . . . . 41
               4.1   Class (A1):  Verified Design . . . . . . . . . . . 42
               4.2   Beyond Class (A1). . . . . . . . . . . . . . . . . 51


                      PART II:  RATIONALE AND GUIDELINES

          5.0  CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS. . . . . 55
               5.1   A Need for Consensus . . . . . . . . . . . . . . . 56
               5.2   Definition and Usefulness. . . . . . . . . . . . . 56
               5.3   Criteria Control Objective . . . . . . . . . . . . 56

          6.0  RATIONALE BEHIND THE EVALUATION CLASSES. . . . . . . . . 63
               6.1   The Reference Monitor Concept. . . . . . . . . . . 64
               6.2   A Formal Security Policy Model . . . . . . . . . . 64
               6.3   The Trusted Computing Base . . . . . . . . . . . . 65
               6.4   Assurance. . . . . . . . . . . . . . . . . . . . . 65
               6.5   The Classes. . . . . . . . . . . . . . . . . . . . 66

          7.0  THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA . . . . 69
               7.1   Established Federal Policies . . . . . . . . . . . 70
               7.2   DoD Policies . . . . . . . . . . . . . . . . . . . 70
               7.3   Criteria Control Objective For Security Policy . . 71
               7.4   Criteria Control Objective for Accountability. . . 74
               7.5   Criteria Control Objective for Assurance . . . . . 76

          8.0  A GUIDELINE ON COVERT CHANNELS . . . . . . . . . . . . . 79


          9.0  A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL
               FEATURES . . . . . . . . . . . . . . . . . . . . . . . . 81

          10.0  A GUIDELINE ON SECURITY TESTING . . . . . . . . . . . . 83
                10.1 Testing for Division C . . . . . . . . . . . . . . 84
                10.2 Testing for Division B . . . . . . . . . . . . . . 84
                10.3 Testing for Division A . . . . . . . . . . . . . . 85


          APPENDIX A:  Commercial Product Evaluation Process. . . . . . 87

          APPENDIX B:  Summary of Evaluation Criteria Divisions . . . . 89
          
          APPENDIX C:  Sumary of Evaluation Criteria Classes. . . . . . 91

          APPENDIX D:  Requirement Directory. . . . . . . . . . . . . . 93

          GLOSSARY. . . . . . . . . . . . . . . . . . . . . . . . . . .109

          REFERENCES. . . . . . . . . . . . . . . . . . . . . . . . . .115



                                    PREFACE


The trusted computer system evaluation criteria defined in this document
classify systems into four broad hierarchical divisions of enhanced security
protection.  They provide a basis for the evaluation of effectiveness of
security controls built into automatic data processing system products.  The
criteria were developed with three objectives in mind: (a) to provide users
with a yardstick with which to assess the degree of trust that can be placed
in computer systems for the secure processing of classified or other sensitive
information; (b) to provide guidance to manufacturers as to what to build into
their new, widely-available trusted commercial products in order to satisfy
trust requirements for sensitive applications; and (c) to provide a basis for
specifying security requirements in acquisition specifications.  Two types of
requirements are delineated for secure processing: (a) specific security
feature requirements and (b) assurance requirements.  Some of the latter
requirements enable evaluation personnel to determine if the required features
are present and functioning as intended.  The scope of these criteria is to be
applied to the set of components comprising a trusted system, and is not
necessarily to be applied to each system component individually.  Hence, some
components of a system may be completely untrusted, while others may be
individually evaluated to a lower or higher evaluation class than the trusted
product considered as a whole system.  In trusted products at the high end of
the range, the strength of the reference monitor is such that most of the
components can be completely untrusted.  Though the criteria are intended to be
application-independent, the specific security feature requirements may have to
be interpreted when applying the criteria to specific systems with their own
functional requirements, applications or special environments (e.g.,
communications processors, process control computers, and embedded systems in
general).  The underlying assurance requirements can be applied across the
entire spectrum of ADP system or application processing environments without
special interpretation.


                                 INTRODUCTION

Historical Perspective

In October 1967, a task force was assembled under the auspices of the Defense
Science Board to address computer security safeguards that would protect
classified information in remote-access, resource-sharing computer systems.
The Task Force report, "Security Controls for Computer Systems," published in
February 1970, made a number of policy and technical recommendations on
actions to be taken to reduce the threat of compromise of classified
information processed on remote-access computer systems.[34]  Department of
Defense Directive 5200.28 and its accompanying manual DoD 5200.28-M, published
in 1972 and 1973 respectively, responded to one of these recommendations by
establishing uniform DoD policy, security requirements, administrative
controls, and technical measures to protect classified information processed
by DoD computer systems.[8;9]  Research and development work undertaken by the
Air Force, Advanced Research Projects Agency, and other defense agencies in
the early and mid 70's developed and demonstrated solution approaches for the
technical problems associated with controlling the flow of information in
resource and information sharing computer systems.[1]  The DoD Computer
Security Initiative was started in 1977 under the auspices of the Under
Secretary of Defense for Research and Engineering to focus DoD efforts
addressing computer security issues.[33]

Concurrent with DoD efforts to address computer security issues, work was
begun under the leadership of the National Bureau of Standards (NBS) to define
problems and solutions for building, evaluating, and auditing secure computer
systems.[17]  As part of this work NBS held two invitational workshops on the
subject of audit and evaluation of computer security.[20;28]  The first was
held in March 1977, and the second in November of 1978.  One of the products
of the second workshop was a definitive paper on the problems related to
providing criteria for the evaluation of technical computer security
effectiveness.[20]  As an outgrowth of recommendations from this report, and in
support of the DoD Computer Security Initiative, the MITRE Corporation began
work on a set of computer security evaluation criteria that could be used to
assess the degree of trust one could place in a computer system to protect
classified data.[24;25;31]  The preliminary concepts for computer security
evaluation were defined and expanded upon at invitational workshops and
symposia whose participants represented computer security expertise drawn from
industry and academia in addition to the government.  Their work has since
been subjected to much peer review and constructive technical criticism from
the DoD, industrial research and development organizations, universities, and
computer manufacturers.

The DoD Computer Security Center (the Center) was formed in January 1981 to
staff and expand on the work started by the DoD Computer Security
Initiative.[15]  A major goal of the Center as given in its DoD Charter is to
encourage the widespread availability of trusted computer systems for use by
those who process classified or other sensitive information.[10]  The criteria
presented in this document have evolved from the earlier NBS and MITRE
evaluation material.

Scope

The trusted computer system evaluation criteria defined in this document apply
primarily to trusted commercially available automatic data processing (ADP)
systems.  They are also applicable, as amplified below, the the evaluation of
existing systems and to the specification of security requirements for ADP
systems acquisition.  Included are two distinct sets of requirements: 1)
specific security feature requirements; and 2) assurance requirements.  The
specific feature requirements encompass the capabilities typically found in
information processing systems employing general-purpose operating systems that
are distinct from the applications programs being supported.  However, specific
security feature requirements may also apply to specific systems with their own
functional requirements, applications or special environments (e.g.,
communications processors, process control computers, and embedded systems in
general).  The assurance requirements, on the other hand, apply to systems that
cover the full range of computing environments from dedicated controllers to
full range multilevel secure resource sharing systems.


Purpose

As outlined in the Preface, the criteria have been developedto serve a number
of intended purposes:

           * To provide a standard to manufacturers as to what security
           features to build into their new and planned, commercial 
           products in order to provide widely available systems that
           satisfy trust requirements (with particular emphasis on preventing
           the disclosure of data) for sensitive applications.

           * To provide DoD components with a metric with which to evaluate
           the degree of trust that can be placed in computer systems for
           the secure processing of classified and other sensitive
           information.

           * To provide a basis for specifying security requirements in
           acquisition specifications.

With respect to the second purpose for development of the criteria, i.e.,
providing DoD components with a security evaluation metric, evaluations can be
delineated into two types: (a) an evaluation can be performed on a computer
product from a perspective that excludes the application environment; or, (b)
it can be done to assess whether appropriate security measures have been taken
to permit the system to be used operationally in a specific environment.  The
former type of evaluation is done by the Computer Security Center through the
Commercial Product Evaluation Process.  That process is described in Appendix
A.

The latter type of evaluation, i.e., those done for the purpose of assessing a
system's security attributes with respect to a specific operational mission,
is known as a certification evaluation.  It must be understood that the
completion of a formal product evaluation does not constitute certification or
accreditation for the system to be used in any specific application
environment.  On the contrary, the evaluation report only provides a trusted
computer system's evaluation rating along with supporting data describing the
product system's strengths and weaknesses from a computer security point of
view.  The system security certification and the formal approval/accreditation
procedure, done in accordance with the applicable policies of the issuing
agencies, must still be followed-before a system can be approved for use in
processing or handling classified information.[8;9]  Designated Approving
Authorities (DAAs) remain ultimately responsible for specifying security of
systems they accredit.

The trusted computer system evaluation criteria will be used directly and
indirectly in the certification process.  Along with applicable policy, it
will be used directly as technical guidance for evaluation of the total system
and for specifying system security and certification requirements for new
acquisitions.  Where a system being evaluated for certification employs a
product that has undergone a Commercial Product Evaluation, reports from that
process will be used as input to the certification evaluation.  Technical data
will be furnished to designers, evaluators and the Designated Approving
Authorities to support their needs for making decisions.


Fundamental Computer Security Requirements

Any discussion of computer security necessarily starts from a statement of
requirements, i.e., what it really means to call a computer system "secure."
In general, secure systems will control, through use of specific security
features, access to information such that only properly authorized
individuals, or processes operating on their behalf, will have access to read,
write, create, or delete information.  Six fundamental requirements are
derived from this basic statement of objective: four deal with what needs to
be provided to control access to information; and two deal with how one can
obtain credible assurances that this is accomplished in a trusted computer
system.

                                    Policy

          Requirement 1 - SECURITY POLICY - There must be an explicit and
well-defined security policy enforced by the system.  Given identified subjects
and objects, there must be a set of rules that are used by the system to
determine whether a given subject can be permitted to gain access to a specific
object.  Computer systems of interest must enforce a mandatory security policy
that can effectively implement access rules for handling sensitive (e.g.,
classified) information.[7]  These rules include requirements such as: No
person lacking proper personnel security clearance shall obtain access to
classified
information.  In addition, discretionary security controls are required to
ensure that only selected users or groups of users may obtain access to data
(e.g., based on a need-to-know). 

          Requirement 2 - MARKING - Access control labels must be associated
with objects.  In order to control access to information stored in a computer,
according to the rules of a mandatory security policy, it must be possible to
mark every object with a label that reliably identifies the object's
sensitivity level (e.g., classification), and/or the modes of access accorded
those subjects who may potentially access the object.

                                Accountability

          Requirement 3 - IDENTIFICATION - Individual subjects must be
identified.  Each access to information must be mediated based on who is
accessing the information and what classes of information they are authorized
to deal with.  This identification and authorization information must be
securely maintained by the computer system and be associated with every active
element that performs some security-relevant action in the system.

          Requirement 4 - ACCOUNTABILITY - Audit information must be
selectively kept and protected so that actions affecting security can be traced
to the responsible party.  A trusted system must be able to record the
occurrences of security-relevant events in an audit log.  The capability to
select the audit events to be recorded is necessary to minimize the expense of
auditing and to allow efficient analysis.  Audit data must be protected from
modification and unauthorized destruction to permit detection and
after-the-fact investigations of security violations.

                                   Assurance

          Requirement 5 - ASSURANCE - The computer system must contain
hardware/software mechanisms that can be independently evaluated to provide
sufficient assurance that the system enforces requirements 1 through 4 above. 
In order to assure that the four requirements of Security Policy, Marking,
Identification, and Accountability are enforced by a computer system, there
must be some identified and unified collection of hardware and software
controls that perform those functions.  These mechanisms are typically embedded
in the operating system and are designed to carry out the assigned tasks in a
secure manner.  The basis for trusting such system mechanisms in their
operational setting must be clearly documented such that it is possible to
independently examine the evidence to evaluate their sufficiency.

          Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that
enforce these basic requirements must be continuously protected against
tampering and/or unauthorized changes.  No computer system can be considered
truly secure if the basic hardware and software mechanisms that enforce the
security policy are themselves subject to unauthorized modification or
subversion.  The continuous protection requirement has direct implications
throughout the computer system's life-cycle.

These fundamental requirements form the basis for the individual evaluation
criteria applicable for each evaluation division and class.  The interested
reader is referred to Section 5 of this document, "Control Objectives for
Trusted Computer Systems," for a more complete discussion and further
amplification of these fundamental requirements as they apply to
general-purpose information processing systems and to Section 7 for
amplification of the relationship between Policy and these requirements.


Structure of the Document

The remainder of this document is divided into two parts, four appendices, and
a glossary.  Part I (Sections 1 through 4) presents the detailed criteria
derived from the fundamental requirements described above and relevant to the
rationale and policy excerpts contained in Part II.

Part II (Sections 5 through 10) provides a discussion of basic objectives,
rationale, and national policy behind the development of the criteria, and
guidelines for developers pertaining to: mandatory access control rules
implementation, the covert channel problem, and security testing.  It is
divided into six sections.  Section 5 discusses the use of control objectives
in general and presents the three basic control objectives of the criteria.
Section 6 provides the theoretical basis behind the criteria.  Section 7 gives
excerpts from pertinent regulations, directives, OMB Circulars, and Executive
Orders which provide the basis for many trust requirements for processing
nationally sensitive and classified information with computer systems.
Section 8 provides guidance to system developers on expectations in dealing
with the covert channel problem.  Section 9 provides guidelines dealing with
mandatory security.  Section 10 provides guidelines for security testing.
There are four appendices, including a description of the Trusted Computer
System Commercial Products Evaluation Process (Appendix A), summaries of the
evaluation divisions (Appendix B) and classes (Appendix C), and finally a
directory of requirements ordered alphabetically.  In addition, there is a
glossary.


Structure of the Criteria

The criteria are divided into four divisions: D, C, B, and A ordered in a
hierarchical manner with the highest division (A) being reserved for systems
providing the most comprehensive security.  Each division represents a major
improvement in the overall confidence one can place in the system for the
protection of sensitive information.  Within divisions C and B there are a
number of subdivisions known as classes.  The classes are also ordered in a
hierarchical manner with systems representative of division C and lower
classes of division B being characterized by the set of computer security
mechanisms that they possess.  Assurance of correct and complete design and
implementation for these systems is gained mostly through testing of the
security- relevant portions of the system.  The security-relevant portions of
a system are referred to throughout this document as the Trusted Computing
Base (TCB).  Systems representative of higher classes in division B and
division A derive their security attributes more from their design and
implementation structure.  Increased assurance that the required features are
operative, correct, and tamperproof under all circumstances is gained through
progressively more rigorous analysis during the design process.

Within each class, four major sets of criteria are addressed.  The first three
represent features necessary to satisfy the broad control objectives of
Security Policy, Accountability, and Assurance that are discussed in Part II,
Section 5.  The fourth set, Documentation, describes the type of written
evidence in the form of user guides, manuals, and the test and design
documentation required for each class.

A reader using this publication for the first time may find it helpful to
first read Part II, before continuing on with Part I.



                             PART I:  THE CRITERIA


Highlighting (UPPERCASE) is used in Part I to indicate criteria not contained
in a lower class or changes and additions to already defined criteria.  Where
there is no highlighting, requirements have been carried over from lower
classes without addition or modification.
     


                     1.0  DIVISION D:  MINIMAL PROTECTION


This division contains only one class.  It is reserved for those systems that
have been evaluated but that fail to meet the requirements for a higher
evaluation class.



                   2.0 DIVISION C:  DISCRETIONARY PROTECTION


Classes in this division provide for discretionary (need-to-know) protection
and, through the inclusion of audit capabilities, for accountability of
subjects and the actions they initiate.

    

2.1  CLASS (C1):  DISCRETIONARY SECURITY PROTECTION

The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies
the discretionary security requirements by providing separation of users and
data.  It incorporates some form of credible controls capable of enforcing
access limitations on an individual basis, i.e., ostensibly suitable for
allowing users to be able to protect project or private information and to
keep other users from accidentally reading or destroying their data.  The
class (C1) environment is expected to be one of cooperating users processing
data at the same level(s) of sensitivity.  The following are minimal
requirements for systems assigned a class (C1) rating:

2.1.1  Security Policy

     2.1.1.1   Discretionary Access Control

               The TCB shall define and control access between named users and
               named objects (e.g., files and programs) in the ADP system.  The
               enforcement mechanism (e.g., self/group/public controls, access
               control lists) shall allow users to specify and control sharing
               of those objects by named individuals or defined groups or both.

2.1.2  Accountability

     2.1.2.1   Identification and Authentication

               The TCB shall require users to identify themselves to it before
               beginning to perform any other actions that the TCB is expected
               to mediate.  Furthermore, the TCB shall use a protected 
               mechanism (e.g., passwords) to authenticate the user's identity.
               The TCB shall protect authentication data so that it cannot be
               accessed by any unauthorized user.

2.1.3  Assurance

     2.1.3.1   Operational Assurance

          2.1.3.1.1  System Architecture

                     The TCB shall maintain a domain for its own execution
                     protects it from external interference or tampering
                     (e.g., by modification of its code or data strucutres).
                     Resources controlled by the TCB may be a defined subset
                     of the subjects and objects in the ADP system.

          2.1.3.1.2  System Integrity

                     Hardware and/or software features shall be provided that
                     can be used to periodically validate the correct operation
                     of the on-site hardware and firmware elements of the TCB.

     2.1.3.2   Life-Cycle Assurance

          2.1.3.2.1  Security Testing

                     The security mechanisms of the ADP system shall be tested
                     and found to work as claimed in the system documentation.
                     Testing shall be done to assure that there are no obvious
                     ways for an unauthorized user to bypass or otherwise
                     defeat the security protection mechanisms of the TCB.
                     (See the Security Testing Guidelines.)

2.1.4  Documentation

     2.1.4.1   Security Features User's Guide

               A single summary, chapter, or manual in user documentation
               shall describe the protection mechanisms provided by the TCB,
               guidelines on their use, and how they interact with one another.

     2.1.4.2   Trusted Facility Manual

               A manual addressed to the ADP System Administrator shall
               present cautions about functions and privileges that should be
               controlled when running a secure facility.

     2.1.4.3   Test Documentation

               The system developer shall provide to the evaluators a document
               that describes the test plan, test procedures that show how the
               the security mechanisms were tested, and results of the
               security mechanisms' functional testing.

     2.1.4.4   Design Documentation

               Documentation shall be available that provides a description of
               the manufacturer's philosophy of protection and an explanation
               of how this philosophy is translated into the TCB.  If the TCB
               is composed of distinct modules, the interfaces between these
               modules shall be described.




2.2  CLASS (C2):  CONTROLLED ACCESS PROTECTION

Systems in this class enforce a more finely grained discretionary access
control than (C1) systems, making users individually accountable for their
actions through login procedures, auditing of security-relevant events, and
resource isolation.  The following are minimal requirements for systems
assigned a class (C2) rating:

2.2.1  Security Policy

     2.2.1.1   Discretionary Access Control

               The TCB shall define and control access between named users and
               named objects (e.g., files and programs) in the ADP system.  The
               enforcement mechanism (e.g., self/group/public controls, access
               control lists) shall allow users to specify and control sharing
               of those objects by named individuals, or defined groups of 
               individuals, or by both, and shall provide controls to limit
               propagation of access rights.  The discretionary access control
               mechanism shall, either by explicit user action or by default,
               provide that objects are protected from unauthorized access.
               These access controls shall be capable of including or excluding
               access to the granularity of a single user.  Access permission
               to an object by users not already possessing access permission
               shall only be assigned by authorized users.

     2.2.1.2   Object Reuse

               All authorizations to the information contained within a
               storage object shall be revoked prior to initial assignment,
               allocation or reallocation to a subject from the TCB's pool
               of unused storage objects.  No information, including encrypted
               representations of information, produced by a prior subject's
               actions is to be available to any subject that obtains access
               to an object that has been released back to the system.

2.2.2  Accountability

     2.2.2.1   Identification and Authentication

               The TCB shall require users to identify themselves to it before
               beginning to perform any other actions that the TCB is expected
               to mediate.  Furthermore, the TCB shall use a protected 
               mechanism (e.g., passwords) to authenticate the user's identity.
               The TCB shall protect authentication data so that it cannot be
               accessed by any unauthorized user.  The TCB shall be able to
               enforce individual accountability by providing the capability to
               uniquely identify each individual ADP system user.  The TCB
               shall also provide the capability of associating this identity
               with all auditable actions taken by that individual.

     2.2.2.2   Audit

               The TCB shall be able to create, maintain, and protect from
               modification or unauthorized access or destruction an audit
               trail of accesses to the objects it protects.  The audit data
               shall be protected by the TCB so that read access to it is
               limited to those who are authorized for audit data.  The TCB
               shall be able to record the following types of events:  use of
               identification and authentication mechanisms, introduction or
               objects into a user's address space (e.g., file open, program
               initiation), deletion of objects, and actions taken by 
               computer operators and system administrators and/or system
               security officers, and other security relevant events.  For
               each recorded event, the audit record shall identify:  date and
               time of the event, user, type of event, and success or failure
               of the event.  For identification/authentication events the
               origin of request (e.g., terminal ID) shall be included in the
               audit record.  For events that introduce an object into a user's
               address space and  for object deletion events the audit record
               shall include the name of the object.  The ADP system
               administrator shall be able to selectively audit the actions of
               any one or more users based on individual identity.

2.2.3  Assurance

     2.2.3.1   Operational Assurance

          2.2.3.1.1  System Architecture

                     The TCB shall maintain a domain for its own execution
                     that protects it from external interference or tampering
                     (e.g., by modification of its code or data structures). 
                     Resources controlled by the TCB may be a defined subset
                     of the subjects and objects in the ADP system.  The TCB
                     shall isolate the resources to be protected so that they
                     are subject to the access control and auditing
                     requirements.

          2.2.3.1.2  System Integrity

                     Hardware and/or software features shall be provided that
                     can be used to periodically validate the correct operation
                     of the on-site hardware and firmware elements of the TCB.

     2.2.3.2   Life-Cycle Assurance

          2.2.3.2.1  Security Testing

                     The security mechanisms of the ADP system shall be tested
                     and found to work as claimed in the system documentation.
                     Testing shall be done to assure that there are no obvious
                     ways for an unauthorized user to bypass or otherwise
                     defeat the security protection mechanisms of the TCB.
                     Testing shall also include a search for obvious flaws that
                     would allow violation of resource isolation, or that would
                     permit unauthorized access to the audit or authentication
                     data.  (See the Security Testing guidelines.)

2.2.4  Documentation

     2.2.4.1   Security Features User's Guide

               A single summary, chapter, or manual in user documentation
               shall describe the protection mechanisms provided by the TCB, 
               guidelines on their use, and how they interact with one another.

     2.2.4.2   Trusted Facility Manual

               A manual addressed to the ADP system administrator shall
               present cautions about functions and privileges that should be
               controlled when running a secure facility.  The procedures for
               examining and maintaining the audit files as well as the 
               detailed audit record structure for each type of audit event
               shall be given.


     2.2.4.3   Test Documentation

               The system developer shall provide to the evaluators a document
               that describes the test plan, test procedures that show how the
               security mechanisms were tested, and results of the security 
               mechanisms' functional testing.

     2.2.4.4   Design Documentation

               Documentation shall be available that provides a description of
               the manufacturer's philosophy of protection and an explanation
               of how this philosophy is translated into the TCB.  If the TCB
               is composed of distinct modules, the interfaces between these
               modules shall be described.

    

                    3.0  DIVISION B:  MANDATORY PROTECTION


The notion of a TCB that preserves the integrity of sensitivity labels and
uses them to enforce a set of mandatory access control rules is a major
requirement in this division.  Systems in this division must carry the
sensitivity labels with major data structures in the system.  The system
developer also provides the security policy model on which the TCB is based
and furnishes a specification of the TCB.  Evidence must be provided to
demonstrate that the reference monitor concept has been implemented.



3.1  CLASS (B1):  LABELED SECURITY PROTECTION

Class (B1) systems require all the features required for class (C2).  In
addition, an informal statement of the security policy model, data labeling,
and mandatory access control over named subjects and objects must be present.
The capability must exist for accurately labeling exported information.  Any
flaws identified by testing must be removed.  The following are minimal
requirements for systems assigned a class (B1) rating:

3.1.1  Security Policy

     3.1.1.1   Discretionary Access Control

               The TCB shall define and control access between named users and
               named objects (e.g., files and programs) in the ADP system.  
               The enforcement mechanism (e.g., self/group/public controls, 
               access control lists) shall allow users to specify and control
               sharing of those objects by named individuals, or defined groups
               of individuals, or by both, and shall provide controls to limit
               propagation of access rights.  The discretionary access control
               mechanism shall, either by explicit user action or by default,
               provide that objects are protected from unauthorized access. 
               These access controls shall be capable of including or excluding
               access to the granularity of a single user.  Access permission
               to an object by users not already possessing access permission
               shall only be assigned by authorized users.

     3.1.1.2   Object Reuse

               All authorizations to the information contained within a
               storage object shall be revoked prior to initial assignment,
               allocation or reallocation to a subject from the TCB's pool
               of unused storage objects.  No information, including encrypted
               representations of information, produced by a prior subject's
               actions is to be available to any subject that obtains access
               to an object that has been released back to the system.

     3.1.1.3   Labels

               Sensitivity labels associated with each subject and storage
               object under its control (e.g., process, file, segment, device)
               shall be maintained by the TCB.  These labels shall be used as
               the basis for mandatory access control decisions.  In order to
               import non-labeled data, the TCB shall request and receive from
               an authorized user the security level of the data, and all such
               actions shall be auditable by the TCB.

          3.1.1.3.1  Label Integrity

                     Sensitivity labels shall accurately represent security
                     levels of the specific subjects or objects with which they
                     are associated.  When exported by the TCB, sensitivity
                     labels shall accurately and unambiguously represent the
                     internal labels and shall be associated with the
                     information being exported.

          3.1.1.3.2  Exportation of Labeled Information

                     The TCB shall designate each communication channel and
                     I/O device as either single-level or miltilevel.  Any
                     change in this designation shall be done manually and
                     shall be auditable by the TCB.  The TCB shall maintain
                     and be able to audit any change in the security level
                     or levels associated with a communication channel or 
                     I/O device.

               3.1.1.3.2.1  Exportation to Multilevel Devices

                          When the TCB exports an object to a multilevel I/O
                          device, the sensitivity label associated with that
                          object shall also be exported and shall reside on
                          the same physical medium as the exported
                          information and shall be in the same form
                          (i.e., machine-readable or human-readable form).
                          When the TCB exports or imports an object over a 
                          multilevel communication channel, the protocol
                          used on that channel shall provide for the
                          unambiguous pairing between the sensitivity labels
                          and the associated information that is sent or
                          received.

               3.1.1.3.2.2  Exportation to Single-Level Devices

                          Single-level I/O devices and single-level
                          communication channels are not required to
                          maintain the sensitivity labels of the information
                          they process.  However, the TCB shall include a
                          mechanism by which the TCb and an authorized user 
                          reliably communicate to designate the single
                          security level of information imported or exported
                          via single-level communication channels or I/O
                          devices.

               3.1.1.3.2.3  Labeling Human-Readable Output

                          The ADP system administrator shall be able to
                          specify the printable label names associated with
                          exported sensitivity labels.  The TCB shall mark
                          the beginning and end of all human-readable, paged,
                          hardcopy output (e.g., line printer output) with
                          human-readable sensitivity labels that properly*
                          represent the sensitivity of the output.  The TCB
                          shall, be default, mark the top and bottom of each
                          page of human-readable, paged, hardcopy output
                          (e.g., line printer output) with human-readable
                          sensitivity labels that properly* represent the
                          overall sensitivity of the output or that properly*
                          represent the sensitivity of the information on the
                          page.  The TCB shall, by default and in an
                          appropriate manner, mark other forms of human-
                          readable output (e.g., maps, graphics) with human-
                          readable sensitivity labels that properly*
                          represent the sensitivity of the touput.  Any
                          override of these marking defaults shall be
                          auditable by the TCB.

     3.1.1.4  Mandatory Access Control

               The TCB shall enforce a mandatory access control policy over
               all subjects and storage objects under its control (e.g.,
               processes, files, segments, devices).  These subjects and
               objects shall be assigned sensitivity labels that are a
               combination of hierarchical classification levels and
               non-hierarchical categories, and the labels shall be used as
               the basis for mandatory access control decisions.  The TCB
               shall be able to support two or more such security levels.
               (See the Mandatory Access Control Guidelines.)  The following
               requirements shall hold for all accesses between subjects and
               objects controlled by the TCB:  a subject can read an object
               only if the hierarchical classification in the subject's
               security level is greater than or equal to the hierarchical
               classification in the object's security level and the non-
               hierarchical categories in the subject's security level include
               all the non-hierarchical categories in the object's security
               level.  A subject can write an object only if the hierarchical
               classification in the subject's security level is less than or
               equal to the hierarchical classification in the object's 
               security level and all the non-hierarchical categories in the
               subject's security level are included in the non-hierarchical
               categories in the object's security level.  Identification 
               and authentication data shall be used by the TCB to authenti-
               cate the user's identity and to ensure that the security level
               and authorization of subjects external to the TCB that may be
               created to act on behalf of the individual user are dominated
               by the clearance and authorization of that user.

3.1.2  Accountability

     3.1.2.1  Identification and Authentication

               The TCB shall require users to identify themselves to it before
               beginning to perform any other actions that the TCB is expected
               to mediate.  Furthermore, the TCB shall maintain authentication
               data that includes information for verifying the identity of
               individual users (e.g., passwords) as well as information for
               determining the clearance and authorizations or individual
_____________________________
* The hierarchical classification component in human-readable sensitivity
labels shall be equal to the greatest hierarchical classification or any of the
information in the output that the labels refer to; the non-hierarchical
category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical
categories.

               users.  This data shall be used by the TCB to authenticate the
               user's identity and to ensure that the security level and
               authorizations of subjects external to the TCB that may be
               created to act on behalf of the individual user are dominated
               by the clearance and authorization of that user.  The TCB shall
               protect authentication data so that it cannot be accessed by any
               unauthorized user.  The TCB shall be able to enforce individual
               accountability by providing the capability to uniquely identify
               each individual ADP system user.  The TCB shall also provide the
               capability of associating this identity with all auditable
               actions taken by that individual.

     3.1.2.2   Audit

               The TCB shall be able to create, maintain, and protect from
               modification or unauthorized access or destruction an audit
               trail of accesses to the objects it protects.  The audit data
               shall be protected by the TCB so that read access to it is
               limited to those who are authorized for audit data.  The TCB
               shall be able to record the following types of events: use of
               identification and authentication mechanisms, introduction of
               objects into a user's address space (e.g., file open, program
               initiation), deletion of objects, and actions taken by computer
               operators and system administrators and/or system security
               officers and other security relevant events.  The TCB shall also
               be able to audit any override of human-readable output markings.
               For each recorded event, the audit record shall identify: date
               and time of the event, user, type of event, and success or
               failure of the event.  For identification/authentication events
               the origin of request (e.g., terminal ID) shall be included in
               the audit record.  For events that introduce an object into a
               user's address space and for object deletion events the audit
               record shall include the name of the object and the object's
               security level.  The ADP system administrator shall be able to
               selectively audit the actions of any one or more users based on
               individual identity and/or object security level.

3.1.3  Assurance

     3.1.3.1   Operational Assurance

          3.1.3.1.1  System Architecture

                     The TCB shall maintain a domain for its own execution
                     that protects it from external interference or tampering
                     (e.g., by modification of its code or data structures). 
                     Resources controlled by the TCB may be a defined subset
                     of the subjects and objects in the ADP system.  The TCB
                     shall maintain process isolation through the provision of
                     distinct address spaces under its control.  The TCB shall
                     isolate the resources to be protected so that they are
                     subject to the access control and auditing requirements.

          3.1.3.1.2  System Integrity

                     Hardware and/or software features shall be provided that
                     can be used to periodically validate the correct operation
                     of the on-site hardware and firmware elements of the TCB.

     3.1.3.2   Life-Cycle Assurance

          3.1.3.2.1  Security Testing

                     The security mechanisms of the ADP system shall be tested
                     and found to work as claimed in the system documentation.
                     A team of individuals who thoroughly understand the
                     specific implementation of the TCB shall subject its
                     design documentation, source code, and object code to
                     thorough analysis and testing.  Their objectives shall be:
                     to uncover all design and implementation flaws that would
                     permit a subject external to the TCB to read, change, or
                     delete data normally denied under the mandatory or
                     discretionary security policy enforced by the TCB; as well
                     as to assure that no subject (without authorization to do
                     so) is able to cause the TCB to enter a state such that
                     it is unable to respond to communications initiated by
                     other users.  All discovered flaws shall be removed or
                     neutralized and the TCB retested to demonstrate that they
                     have been eliminated and that new flaws have not been
                     introduced.  (See the Security Testing Guidelines.)

          3.1.3.2.2  Design Specification and Verification

                     An informal or formal model of the security policy
                     supported by the TCB shall be maintained over the life
                     cycle of the ADP system and demonstrated to be consistent
                     with its axioms.

3.1.4  Documentation

     3.1.4.1   Security Features User's Guide

               A single summary, chapter, or manual in user documentation
               shall describe the protection mechanisms provided by the TCB,
               guidelines on their use, and how they interact with one another.

     3.1.4.2   Trusted Facility Manual

               A manual addressed to the ADP system administrator shall
               present cautions about functions and privileges that should be
               controlled when running a secure facility.  The procedures for
               examining and maintaining the audit files as well as the
               detailed audit record structure for each type of audit event
               shall be given.  The manual shall describe the operator and
               administrator functions related to security, to include changing
               the security characteristics of a user.  It shall provide
               guidelines on the consistent and effective use of the protection
               features of the system, how they interact, how to securely
               generate a new TCB, and facility procedures, warnings, and
               privileges that need to be controlled in order to operate the
               facility in a secure manner.

     3.1.4.3   Test Documentation

               The system developer shall provide to the evaluators a document
               that describes the test plan, test procedures that show how the
               security mechanisms were tested, and results of the security 
               mechanisms' functional testing.

     3.1.4.4   Design Documentation

               Documentation shall be available that provides a description of
               the manufacturer's philosophy of protection and an explanation
               of how this philosophy is translated into the TCB.  If the TCB
               is composed of distinct modules, the interfaces between these
               modules shall be described.  An informal or formal description
               of the security policy model enforced by the TCB shall be
               available and an explanation provided to show that it is
               sufficient to enforce the security policy.  The specific TCB
               protection mechanisms shall be identified and an explanation
               given to show that they satisfy the model.


3.2  CLASS (B2):  STRUCTURED PROTECTION

In class (B2) systems, the TCB is based on a clearly defined and documented
formal security policy model that requires the discretionary and mandatory
access control enforcement found in class (B1) systems be extended to all
subjects and objects in the ADP system.  In addition, covert channels are
addressed.  The TCB must be carefully structured into protection-critical and
non- protection-critical elements.  The TCB interface is well-defined and the
TCB design and implementation enable it to be subjected to more thorough
testing and more complete review.  Authentication mechanisms are strengthened,
trusted facility management is provided in the form of support for system
administrator and operator functions, and stringent configuration management
controls are imposed.  The system is relatively resistant to penetration.  The
following are minimal requirements for systems assigned a class (B2) rating:

3.2.1  Security Policy

     3.2.1.1   Discretionary Access Control

               The TCB shall define and control access between named users and
               named objects (e.g., files and programs) in the ADP system.
               The enforcement mechanism (e.g., self/group/public controls,
               access control lists) shall allow users to specify and control
               sharing of those objects by named individuals, or defined
               groups of individuals, or by both, and shall provide controls 
               to limit propagation of access rights.  The discretionary access
               control mechanism shall, either by explicit user action or by
               default, provide that objects are protected from unauthorized
               access.  These access controls shall be capable of including
               or excluding access to the granularity of a single user.
               Access permission to an object by users not already possessing
               access permission shall only be assigned by authorized users.

     3.2.1.2   Object Reuse

               All authorizations to the information contained within a
               storage object shall be revoked prior to initial assignment,
               allocation or reallocation to a subject from the TCB's pool of 
               unused storage objects.  No information, including encrypted
               representations of information, produced by a prior subject's
               actions is to be available to any subject that obtains access
               to an object that has been released back to the system.

     3.2.1.3   Labels

               Sensitivity labels associated with each ADP system resource
               (e.g., subject, storage object, ROM) that is directly or
               indirectly accessible by subjects external to the TCB shall be
               maintained by the TCB.  These labels shall be used as the basis
               for mandatory access control decisions.  In order to import 
               non-labeled data, the TCB shall request and receive from an
               authorized user the security level of the data, and all such
               actions shall be auditable by the TCB.

          3.2.1.3.1  Label Integrity

                     Sensitivity labels shall accurately represent security
                     levels of the specific subjects or objects with which
                     they are associated.  When exported by the TCB,
                     sensitivity labels shall accurately and unambiguously
                     represent the internal labels and shall be associated
                     with the information being exported.

          3.2.1.3.2  Exportation of Labeled Information

                     The TCB shall designate each communication channel and
                     I/O device as either single-level or multilevel.  Any
                     change in this designation shall be done manually and
                     shall be auditable by the TCB.  The TCB shall maintain
                     and be able to audit any change in the security level
                     or levels associated with a communication channel or 
                     I/O device.

               3.2.1.3.2.1  Exportation to Multilevel Devices

                          When the TCB exports an object to a multilevel I/O
                          device, the sensitivity label associated with that
                          object shall also be exported and shall reside on
                          the same physical medium as the exported 
                          information and shall be in the same form (i.e., 
                          machine-readable or human-readable form).  When
                          the TCB exports or imports an object over a
                          multilevel communication channel, the protocol
                          used on that channel shall provide for the
                          unambiguous pairing between the sensitivity labels
                          and the associated information that is sent or
                          received.

               3.2.1.3.2.2  Exportation to Single-Level Devices

                          Single-level I/O devices and single-level
                          communication channels are not required to 
                          maintain the sensitivity labels of the
                          information they process.  However, the TCB shall
                          include a mechanism by which the TCB and an
                          authorized user reliably communicate to designate
                          the single security level of information imported
                          or exported via single-level communication 
                          channels or I/O devices.

               3.2.1.3.2.3  Labeling Human-Readable Output

                          The ADP system administrator shall be able to
                          specify the printable label names associated with
                          exported sensitivity labels.  The TCB shall mark
                          the beginning and end of all human-readable, paged,
                          hardcopy output (e.g., line printer output) with
                          human-readable sensitivity labels that properly*
                          represent the sensitivity of the output.  The TCB
                          shall, by default, mark the top and bottom of each
                          page of human-readable, paged, hardcopy output
                          (e.g., line printer output) with human-readable
                          sensitivity labels that properly* represent the
                          overall sensitivity of the output or that 
                          properly* represent the sensitivity of the
                          information on the page.  The TCB shall, by
                          default and in an appropriate manner, mark other
                          forms of human-readable output (e.g., maps,
                          graphics) with human-readable sensitivity labels
                          that properly* represent the sensitivity of the
                          output.  Any override of these marking defaults
                          shall be auditable by the TCB.

          3.2.1.3.3  Subject Sensitivity Labels

                     The TCB shall immediately notify a terminal user of each
                     change in the security level associated with that user
                     during an interactive session.  A terminal user shall be
                     able to query the TCB as desired for a display of the
                     subject's complete sensitivity label.

          3.2.1.3.4  Device Labels

                     The TCB shall support the assignment of minimum and
                     maximum security levels to all attached physical devices.
                     These security levels shall be used by the TCB to enforce
                     constraints imposed by the physical environments in which
                     the devices are located.

     3.2.1.4   Mandatory Access Control

               The TCB shall enforce a mandatory access control policy over
               all resources (i.e., subjects, storage objects, and I/O devices
               that are directly or indirectly accessible by subjects external
               to the TCB.  These subjects and objects shall be assigned
               sensitivity labels that are a combination of hierarchical
               classification levels and non-hierarchical categories, and the
               labels shall be used as the basis for mandatory access control
               decisions.  The TCB shall be able to support two or more such
               security levels.  (See the Mandatory Access Control guidelines.)
               The following requirements shall hold for all accesses between
               All subjects external to the TCB and all objects directly or
               indirectly accessible by these subjects:  A subject can read an
               object only if the hierarchical classification in the subject's
               security level is greater than or equal to the hierarchical
               classification in the object's security level and the non-
               hierarchical categories in the subject's security level include
               all the non-hierarchical categories in the object's security
               level.  A subject can write an object only if the hierarchical
               classification in the subject's security level is less than or
               equal to the hierarchical classification in the object's
               security level and all the non-hierarchical categories in the
               subject's security level are included in the non-hierarchical
               categories in the object's security level.  Identification and
               authentication data shall be used by the TCB to authenticate
               the user's identity and to ensure that the security level and
               authorization of subjects external to the TCB that may be
               created to act on behalf of the individual user are dominated
               by the clearance and authorization of that user.

3.2.2  Accountability

     3.2.2.1   Identification and Authentication

               The TCB shall require users to identify themselves to it before
               beginning to perform any other actions that the TCB is expected
               to mediate.  Furthermore, the TCB shall maintain authentication
               data that includes information for verifying the identity of
               individual users (e.g., passwords) as well as information for
               determining the clearance and authorizations of individual
               users.  This data shall be used by the TCB to authenticate the
               user's identity and to ensure that the security level and
               authorizations of subjects external to the TCB that may be
               created to act on behalf of the individual user are dominated by
               the clearance and authorization of that user.  The TCB shall
               protect authentication data so that it cannot be accessed by any
               unauthorized user.  The TCB shall be able to enforce individual
               accountability by providing the capability to uniquely identify
               each individual ADP system user.  The TCB shall also provide the
               capability of associating this identity with all auditable
               actions taken by that individual.

          3.2.2.1.1  Trusted Path

                     The TCB shall support a trusted communication path
                     between itself and user for initial login and
                     authentication.  Communications via this path shall be
                     initiated exclusively by a user.

     3.2.2.2   Audit

               The TCB shall be able to create, maintain, and protect from
               modification or unauthorized access or destruction an audit
               trail of accesses to the objects it protects.  The audit data
               shall be protected by the TCB so that read access to it is
               limited to those who are authorized for audit data.  The TCB
               shall be able to record the following types of events: use of
               identification and authentication mechanisms, introduction of
               objects into a user's address space (e.g., file open, program
               initiation), deletion of objects, and actions taken by computer
               operators and system administrators and/or system security
               officers, and other security relevant events.  The TCB shall
               also be able to audit any override of human-readable output
               markings.  For each recorded event, the audit record shall
               identify:  date and time of the event, user, type of event, and
               success or failure of the event.  For identification/
               authentication events the origin of request (e.g., terminal ID)
               shall be included in the audit record.  For events that
               introduce an object into a user's address space and for object
               deletion events the audit record shall include the name of the
               object and the object's security level.  The ADP system
               administrator shall be able to selectively audit the actions of
               any one or more users based on individual identity and/or object
               security level.  The TCB shall be able to audit the identified
               events that may be used in the exploitation of covert storage
               channels.

3.2.3  Assurance

     3.2.3.1   Operational Assurance

          3.2.3.1.1  System Architecture

                     The TCB shall maintain a domain for its own execution
                     that protects it from external interference or tampering
                     (e.g., by modification of its code or data structures).
                     The TCB shall maintain process isolation through the
                     provision of distinct address spaces under its control.
                     The TCB shall be internally structured into well-defined
                     largely independent modules.  It shall make effective use
                     of available hardware to separate those elements that are
                     protection-critical from those that are not.  The TCB
                     modules shall be designed such that the principle of least
                     privilege is enforced.  Features in hardware, such as
                     segmentation, shall be used to support logically distinct
                     storage objects with separate attributes (namely:
                     readable, writeable).  The user interface to the TCB
                     shall be completely defined and all elements of the TCB
                     identified.

          3.2.3.1.2  System Integrity

                     Hardware and/or software features shall be provided that
                     can be used to periodically validate the correct 
                     operation of the on-site hardware and firmware elements 
                     of the TCB.

          3.2.3.1.3  Covert Channel Analysis

                     The system developer shall conduct a thorough search for
                     covert storage channels and make a determination (either
                     by actual measurement or by engineering estimation) of
                     the maximum bandwidth of each identified channel.  (See
                     the covert channels guideline section.)

          3.2.3.1.4  Trusted Facility Management

                     The TCB shall support separate operator and administrator
                     functions.

     3.2.3.2   Life-Cycle Assurance

          3.2.3.2.1  Security Testing

                     The security mechanisms of the ADP system shall be tested
                     and found to work as claimed in the system documentation. 
                     A team of individuals who thoroughly understand the
                     specific implementation of the TCB shall subject its
                     design documentation, source code, and object code to
                     thorough analysis and testing.  Their objectives shall be:
                     to uncover all design and implementation flaws that would
                     permit a subject external to the TCB to read, change, or
                     delete data normally denied under the mandatory or
                     discretionary security policy enforced by the TCB; as well
                     as to assure that no subject (without authorization to do
                     so) is able to cause the TCB to enter a state such that it
                     is unable to respond to communications initiated by other
                     users.  The TCB shall be found relatively resistant to
                     penetration.  All discovered flaws shall be corrected and
                     the TCB retested to demonstrate that they have been
                     eliminated and that new flaws have not been introduced.
                     Testing shall demonstrate that the TCB implementation is
                     consistent with the descriptive top-level specification.
                     (See the Security Testing Guidelines.)

          3.2.3.2.2  Design Specification and Verification

                     A formal model of the security policy supported by the
                     TCB shall be maintained over the life cycle of the ADP
                     system that is proven consistent with its axioms.  A
                     descriptive top-level specification (DTLS) of the TCB
                     shall be maintained that completely and accurately
                     describes the TCB in terms of exceptions, error messages,
                     and effects.  It shall be shown to be an accurate
                     description of the TCB interface.

          3.2.3.2.3  Configuration Management

                     During development and maintenance of the TCB, a
                     configuration management system shall be in place that
                     maintains control of changes to the descriptive top-level
                     specification, other design data, implementation
                     documentation, source code, the running versionof the
                     object code, and test fixtures and documentation.  The
                     configuration management system shall assure a consistent
                     mapping among all documentation and code associated with 
                     the current version of the TCB.  Tools shall be provided
                     for generation of a new version of the TCB from source
                     code.  Also available shall be tools for comparing a
                     newly generated version with the previous TCB version in
                     order to ascertain that only the intended changes have
                     been made in the code that will actually be used as the
                     new version of the TCB.

3.2.4  Documentation

     3.2.4.1   Security Features User's Guide

               A single summary, chapter, or manual in user documentation
               shall describe the protection mechanisms provided by the TCB,
               guidelines on their use, and how they interact with one another.

     3.2.4.2   Trusted Facility Manual

               A manual addressed to the ADP system administrator shall
               present cautions about functions and privileges that should be
               controlled when running a secure facility.  The procedures for
               examining and maintaining the audit files as well as the
               detailed audit record structure for each type of audit event
               shall be given.  The manual shall describe the operator and
               administrator functions related to security, to include 
               changing the security characteristics of a user.  It shall
               provide guidelines on the consistent and effective use of the
               protection features of the system, how they interact, how to
               securely generate a new TCB, and facility procedures, warnings,
               and privileges that need to be controlled in order to operate
               the facility in a secure manner.  The TCB modules that contain
               the reference validation mechanism shall be identified.  The
               procedures for secure generation of a new TCB from source after
               modification of any modules in the TCB shall be described.

     3.2.4.3   Test Documentation

               The system developer shall provide to the evaluators a document
               that describes the test plan, test procedures that show how the
               security mechanisms were tested, and results of the security
               mechanisms' functional testing.  It shall include results of
               testing the effectiveness of the methods used to reduce covert
               channel bandwidths.

     3.2.4.4   Design Documentation

               Documentation shall be available that provides a description of
               the manufacturer's philosophy of protection and an explanation
               of how this philosophy is translated into the TCB.  The
               interfaces between the TCB modules shall be described.  A
               formal description of the security policy model enforced by the
               TCB shall be available and proven that it is sufficient to
               enforce the security policy.  The specific TCB protection 
               mechanisms shall be identified and an explanation given to show
               that they satisfy the model.  The descriptive top-level
               specification (DTLS) shall be shown to be an accurate
               description of the TCB interface.  Documentation shall describe
               how the TCB implements the reference monitor concept and give
               an explanation why it is tamper resistant, cannot be bypassed,
               and is correctly implemented.  Documentation shall describe how
               the TCB is structured to facilitate testing and to enforce least
               privilege.  This documentation shall also present the results
               of the covert channel analysis and the tradeoffs involved in
               restricting the channels.  All auditable events that may be
               used in the exploitation of known covert storage channels shall
               be identified.  The bandwidths of known covert storage channels
               the use of which is not detectable by the auditing mechanisms,
               shall be provided.  (See the Covert Channel Guideline section.)


3.3  CLASS (B3):  SECURITY DOMAINS

The class (B3) TCB must satisfy the reference monitor requirements that it
mediate all accesses of subjects to objects, be tamperproof, and be small
enough to be subjected to analysis and tests.  To this end, the TCB is
structured to exclude code not essential to security policy enforcement, with
significant system engineering during TCB design and implementation directed
toward minimizing its complexity.  A security administrator is supported,
audit mechanisms are expanded to signal security- relevant events, and system
recovery procedures are required.  The system is highly resistant to
penetration.  The following are minimal requirements for systems assigned a
class (B3) rating:

3.1.1  Security Policy

     3.3.1.1   Discretionary Access Control

               The TCB shall define and control access between named users and
               named objects (e.g., files and programs) in the ADP system.
               The enforcement mechanism (e.g., access control lists) shall
               allow users to specify and control sharing of those objects,
               and shall provide controls to limit propagation of access
               rights.  The discretionary access control mechanism shall,
               either by explicit user action or by default, provide that
               objects are protected from unauthorized access.  These access
               controls shall be capable of specifying, for each named object,
               a list of named individuals and a list of groups of named
               individuals with their respective modes of access to that
               object.  Furthermore, for each such named object, it shall be
               possible to specify a list of named individuals and a list of
               groups of named individuals for which no access to the object is
               to be given.  Access permission to an object by users not
               already possessing access permission shall only be assigned by
               authorized users.

     3.3.1.2   Object Reuse

               All authorizations to the information contained within a
               storage object shall be revoked prior to initial assignment,
               allocation or reallocation to a subject from the TCB's pool
               of unused storage objects.  No information, including 
               encrypted representations of information, produced by a prior
               subjects actions is to be available to any subject that obtains
               access to an object that has been released back to the system.

     3.3.1.3   Labels

               Sensitivity labels associated with each ADP system resource
               (e.g., subject, storage object, ROM) that is directly or
               indirectly accessible by subjects external to the TCB shall be
               maintained by the TCB.  These labels shall be used as the basis
               for mandatory access control decisions.  In order to import 
               non-labeled data, the TCB shall request and receive from an
               authorized user the security level of the data, and all such
               actions shall be auditable by the TCB.

          3.3.1.3.1  Label Integrity

                     Sensitivity labels shall accurately represent security
                     levels of the specific subjects or objects with which
                     they are associated.  When exported by the TCB,
                     sensitivity labels shall accurately and unambiguously
                     represent the internal labels and shall be associated
                     with the information being exported.

          3.3.1.3.2  Exportation of Labeled Information

                     The TCB shall designate each communication channel and
                     I/O device as either single-level or multilevel.  Any
                     change in this designation shall be done manually and
                     shall be auditable by the TCB.  The TCB shall maintain
                     and be able to audit any change in the security level
                     or levels associated with a communication channel or
                     I/O device.

               3.3.1.3.2.1  Exportation to Multilevel Devices

                            When the TCB exports an object to a multilevel I/O
                            device, the sensitivity label associated with that
                            object shall also be exported and shall reside on
                            the same physical medium as the exported 
                            information and shall be in the same form (i.e., 
                            machine-readable or human-readable form).  When
                            the TCB exports or imports an object over a
                            multilevel communication channel, the protocol 
                            used on that channel shall provide for the
                            unambiguous pairing between the sensitivity labels
                            and the associated information that is sent or
                            received.

               3.3.1.3.2.2  Exportation to Single-Level Devices

                            Single-level I/O devices and single-level
                            communication channels are not required to 
                            maintain the sensitivity labels of the information
                            they process.  However, the TCB shall include a 
                            mechanism by which the TCB and an authorized user
                            reliably communicate to designate the single
                            security level of information imported or exported
                            via single-level communication channels or I/O
                            devices.

               3.3.1.3.2.3  Labeling Human-Readable Output

                            The ADP system administrator shall be able to
                            specify the printable label names associated with
                            exported sensitivity labels.  The TCB shall mark
                            the beginning and end of all human-readable, paged,
                            hardcopy output (e.g., line printer output) with
                            human-readable sensitivity labels that properly*
                            represent the sensitivity of the output.  The TCB
                            shall, by default, mark the top and bottom of each
                            page of human-readable, paged, hardcopy output
                            (e.g., line printer output) with human-readable
                            sensitivity labels that properly* represent the
                            overall sensitivity of the output or that
                            properly* represent the sensitivity of the 
                            information on the page.  The TCB shall, by
                            default and in an appropriate manner, mark other
                            forms of human-readable output (e.g., maps,
                            graphics) with human-readable sensitivity labels
                            that properly* represent the sensitivity of the 
                            output.  Any override of these marking defaults
                            shall be auditable by the TCB.

          3.3.1.3.3  Subject Sensitivity Labels

                     The TCB shall immediately notify a terminal user of each
                     change in the security level associated with that user
                     during an interactive session.  A terminal user shall be
                     able to query the TCB as desired for a display of the
                     subject's complete sensitivity label.

          3.3.1.3.4  Device Labels

                     The TCB shall support the assignment of minimum and
                     maximum security levels to all attached physical devices.
                     These security levels shall be used by the TCB to enforce
                     constraints imposed by the physical environments in which
                     the devices are located.

     3.3.1.4   Mandatory Access Control

               The TCB shall enforce a mandatory access control policy over
               all resources (i.e., subjects, storage objects, and I/O 
               devices) that are directly or indirectly accessible by subjects
               external to the TCB.  These subjects and objects shall be
               assigned sensitivity labels that are a combination of
               hierarchical classification levels and non-hierarchical
               categories, and the labels shall be used as the basis for 
               mandatory access control decisions.  The TCB shall be able to
               support two or more such security levels.  (See the Mandatory
______________________________
* The hierarchical classification component in human-readable sensitivity
labels shall be equal to the greatest hierarchical classification of any of the
information in the output that the labels refer to; the non-hierarchical
category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical
categories.

               Access Control guidelines.)  The following requirements shall
               hold for all accesses between all subjects external to the TCB
               and all objects directly or indirectly accessible by these 
               subjects: A subject can read an object only if the hierarchical
               classification in the subject's security level is greater than
               or equal to the hierarchical classification in the object's
               security level and the non-hierarchical categories in the
               subject's security level include all the non-hierarchical
               categories in the object's security level.  A subject can write
               an object only if the hierarchical classification in the 
               subject's security level is less than or equal to the
               hierarchical classification in the object's security level and
               all the non-hierarchical categories in the subject's security 
               level are included in the non- hierarchical categories in the 
               object's security level.  Identification and authentication 
               data shall be used by the TCB to authenticate the user's
               identity and to ensure that the security level and authori-
               zation of subjects external to the TCB that may be created 
               to act on behalf of the individual user are dominated by the
               clearance and authorization of that user.

3.3.2  Accountability

     3.3.2.1   Identification and Authentication

               The TCB shall require users to identify themselves to it before
               beginning to perform any other actions that the TCB is expected
               to mediate.  Furthermore, the TCB shall maintain authentication
               data that includes information for verifying the identity of
               individual users (e.g., passwords) as well as information for
               determining the clearance and authorizations of individual
               users.  This data shall be used by the TCB to authenticate the
               user's identity and to ensure that the security level and 
               authorizations of subjectsexternal to the TCB that may be
               created to act on behalf of the individual user are dominated
               by the clearance and authorization of that user.  The TCB shall
               protect authentication data so that it cannot be accessed by any
               unauthorized user.  The TCB shall be able to enforce individual
               accountability by providing the capability to uniquely identify
               each individual ADP system user.  The TCB shall also provide the
               capability of associating this identity with all auditable
               actions taken by that individual.

          3.3.2.1.1  Trusted Path

                     The TCB shall support a trusted communication path
                     between itself and users for use when a positive TCB-to-
                     user connection is required (e.g., login, change subject
                     security level).  Communications via this trusted path
                     shall be activated exclusively by a user of the TCB and
                     shall be logically isolated and unmistakably
                     distinguishable from other paths.

     3.3.2.2   Audit

               The TCB shall be able to create, maintain, and protect from
               modification or unauthorized access or destruction an audit 
               trail of accesses to the objects it protects.  The audit data
               shall be protected by the TCB so that read access to it is
               limited to those who are authorized for audit data.  The TCB
               shall be able to record the following types of events: use of
               identification and authentication mechanisms, introduction of
               objects into a user's address space (e.g., file open, program
               initiation), deletion of objects, and actions taken by computer
               operators and system administrators and/or system security
               officers and other security relevant events.  The TCB shall also
               be able to audit any override of human-readable output markings.
               For each recorded event, the audit record shall identify:  date
               and time of the event, user, type of event, and success or
               failure of the event.  For identification/authentication events
               the origin of request (e.g., terminal ID) shall be included in
               the audit record.  For events that introduce an object into a
               user's address space and for object deletion events the audit
               record shall include the name of the object and the object's
               security level.  The ADP system administrator shall be able to
               selectively audit the actions of any one or more users based on
               individual identity and/or object security level.  The TCB shall
               be able to audit the identified events that may be used in the
               exploitation of covert storage channels.  The TCB shall contain
               a mechanism that is able to monitor the occurrence or
               accumulation of security auditable events that may indicate an
               imminent violation of security policy.  This mechanism shall be
               able to immediately notify the security administrator when
               thresholds are exceeded, and if the occurrence or accumulation
               of these security relevant events continues, the system shall
               take the least disruptive action to terminate the event.

3.3.3  Assurance

     3.3.3.1   Operational Assurance

          3.3.3.1.1  System Architecture

                     The TCB shall maintain a domain for its own execution
                     that protects it from external interference or tampering
                     (e.g., by modification of its code or data structures).
                     The TCB shall maintain process isolation through the
                     provision of distinct address spaces under its control.
                     The TCB shall be internally structured into well-defined
                     largely independent modules.  It shall make effective use
                     of available hardware to separate those elements that are
                     protection-critical from those that are not.  The TCB
                     modules shall be designed such that the principle of 
                     least privilege is enforced.  Features in hardware, such
                     as segmentation, shall be used to support logically
                     distinct storage objects with separate attributes (namely:
                     readable, writeable).  The user interface to the TCB shall
                     be completely defined and all elements of the TCB
                     identified.  The TCB shall be designed and structured to
                     use a complete, conceptually simple protection mechanism
                     with precisely defined semantics.  This mechanism shall
                     play a central role in enforcing the internal structuring
                     of the TCB and the system.  The TCB shall incorporate
                     significant use of layering, abstraction and data hiding.
                     Significant system engineering shall be directed toward
                     minimizing the complexity of the TCB and excluding from 
                     the TCB modules that are not protection-critical.

          3.3.3.1.2  System Integrity

                     Hardware and/or software features shall be provided that
                     can be used to periodically validate the correct 
                     operation of the on-site hardware and firmware elements 
                     of the TCB.

          3.3.3.1.3  Covert Channel Analysis

                     The system developer shall conduct a thorough search for
                     covert channels and make a determination (either by 
                     actual measurement or by engineering estimation) of the
                     maximum bandwidth of each identified channel.  (See the
                     Covert Channels Guideline section.)

          3.3.3.1.4  Trusted Facility Management

                     The TCB shall support separate operator and administrator
                     functions.  The functions performed in the role of a
                     security administrator shall be identified.  The ADP
                     system administrative personnel shall only be able to
                     perform security administrator functions after taking a
                     distinct auditable action to assume the security
                     administrator role on the ADP system.  Non-security
                     functions that can be performed in the security
                     administration role shall be limited strictly to those
                     essential to performing the security role effectively.

          3.3.3.1.5  Trusted Recovery

                     Procedures and/or mechanisms shall be provided to assure
                     that, after an ADP system failure or other discontinuity,
                     recovery without a protection compromise is obtained.

     3.3.3.2   Life-Cycle Assurance

          3.3.3.2.1  Security Testing

                     The security mechanisms of the ADP system shall be tested
                     and found to work as claimed in the system documentation.
                     A team of individuals who thoroughly understand the
                     specific implementation of the TCB shall subject its
                     design documentation, source code, and object code to
                     thorough analysis and testing.  Their objectives shall 
                     be: to uncover all design and implementation flaws that
                     would permit a subject external to the TCB to read,
                     change, or delete data normally denied under the 
                     mandatory or discretionary security policy enforced by
                     the TCB; as well as to assure that no subject (without
                     authorization to do so) is able to cause the TCB to enter
                     a state such that it is unable to respond to 
                     communications initiated by other users.  The TCB shall
                     be found resistant to penetration.  All discovered flaws
                     shall be corrected and the TCB retested to demonstrate 
                     that they have been eliminated and that new flaws have
                     not been introduced.  Testing shall demonstrate that the
                     TCB implementation is consistent with the descriptive
                     top-level specification.  (See the Security Testing 
                     Guidelines.)  No design flaws and no more than a few
                     correctable implementation flaws may be found during 
                     testing and there shall be reasonable confidence that
                     few remain.

          3.3.3.2.2  Design Specification and Verification

                     A formal model of the security policy supported by the
                     TCB shall be maintained over the life cycle of the ADP
                     system that is proven consistent with its axioms.  A
                     descriptive top-level specification (DTLS) of the TCB
                     shall be maintained that completely and accurately
                     describes the TCB in terms of exceptions, error messages,
                     and effects.  It shall be shown to be an accurate
                     description of the TCB interface.  A convincing argument
                     shall be given that the DTLS is consistent with the model.

          3.3.3.2.3  Configuration Management

                     During development and maintenance of the TCB, a
                     configuration management system shall be in place that 
                     maintains control of changes to the descriptive top-level
                     specification, other design data, implementation
                     documentation, source code, the running version of the
                     object code, and test fixtures and documentation.  The
                     configuration management system shall assure a consistent
                     mapping among all documentation and code associated with
                     the current version of the TCB.  Tools shall be provided
                     for generation of a new version of the TCB from source 
                     code.  Also available shall be tools for comparing a
                     newly generated version with the previous TCB version in
                     order to ascertain that only the intended changes have 
                     been made in the code that will actually be used as the
                     new version of the TCB.

3.3.4  Documentation

     3.3.4.1   Security Features User's Guide

               A single summary, chapter, or manual in user documentation
               shall describe the protection mechanisms provided by the TCB,
               guidelines on their use, and how they interact with one another.

     3.3.4.2   Trusted Facility Manual

               A manual addressed to the ADP system administrator shall
               present cautions about functions and privileges that should be
               controlled when running a secure facility.  The procedures for
               examining and maintaining the audit files as well as the
               detailed audit record structure for each type of audit event
               shall be given.  The manual shall describe the operator and
               administrator functions related to security, to include 
               changing the security characteristics of a user.  It shall
               provide guidelines on the consistent and effective use of the
               protection features of the system, how they interact, how to
               securely generate a new TCB, and facility procedures, warnings,
               and privileges that need to be controlled in order to operate
               the facility in a secure manner.  The TCB modules that contain
               the reference validation mechanism shall be identified.  The
               procedures for secure generation of a new TCB from source after
               modification of any modules in the TCB shall be described.  It
               shall include the procedures to ensure that the system is
               initially started in a secure manner.  Procedures shall also be
               included to resume secure system operation after any lapse in
               system operation.

     3.3.4.3   Test Documentation

               The system developer shall provide to the evaluators a document
               that describes the test plan, test procedures that show how the
               security mechanisms were tested, and results of the security 
               mechanisms' functional testing.  It shall include results of
               testing the effectiveness of the methods used to reduce covert
               channel bandwidths.

     3.3.4.4   Design Documentation

               Documentation shall be available that provides a description of
               the manufacturer's philosophy of protection and an explanation
               of how this philosophy is translated into the TCB.  The
               interfaces between the TCB modules shall be described.  A
               formal description of the security policy model enforced by the
               TCB shall be available and proven that it is sufficient to
               enforce the security policy.  The specific TCB protection 
               mechanisms shall be identified and an explanation given to show
               that they satisfy the model.  The descriptive top-level
               specification (DTLS) shall be shown to be an accurate 
               description of the TCB interface.  Documentation shall describe
               how the TCB implements the reference monitor concept and give 
               an explanation why it is tamper resistant, cannot be bypassed,
               and is correctly implemented.  The TCB implementation (i.e., in
               hardware, firmware, and software) shall be informally shown to
               be consistent with the DTLS.  The elements of the DTLS shall be
               shown, using informal techniques, to correspond to the elements
               of the TCB.  Documentation shall describe how the TCB is
               structured to facilitate testing and to enforce least privilege.
               This documentation shall also present the results of the covert
               channel analysis and the tradeoffs involved in restricting the
               channels.  All auditable events that may be used in the 
               exploitation of known covert storage channels shall be 
               identified.  The bandwidths of known covert storage channels,
               the use of which is not detectable by the auditing mechanisms,
               shall be provided.  (See the Covert Channel Guideline section.)


                     4.0  DIVISION A:  VERIFIED PROTECTION

This division is characterized by the use of formal security verification
methods to assure that the mandatory and discretionary security controls
employed in the system can effectively protect classified or other sensitive
information stored or processed by the system.  Extensive documentation is
required to demonstrate that the TCB meets the security requirements in all
aspects of design, development and implementation.



4.1  CLASS (A1):  VERIFIED DESIGN

Systems in class (A1) are functionally equivalent to those in class (B3) in
that no additional architectural features or policy requirements are added.
The distinguishing feature of systems in this class is the analysis derived
from formal design specification and verification techniques and the resulting
high degree of assurance that the TCB is correctly implemented.  This
assurance is developmental in nature, starting with a formal model of the
security policy and a formal top-level specification (FTLS) of the design.
Independent of the particular specification language or verification system
used, there are five important criteria for class (A1) design verification:

          * A formal model of the security policy must be clearly
          identified and documented, including a mathematical proof
          that the model is consistent with its axioms and is
          sufficient to support the security policy.

          * An FTLS must be produced that includes abstract definitions
          of the functions the TCB performs and of the hardware and/or
          firmware mechanisms that are used to support separate
          execution domains.

          * The FTLS of the TCB must be shown to be consistent with the
          model by formal techniques where possible (i.e., where
          verification tools exist) and informal ones otherwise.

          * The TCB implementation (i.e., in hardware, firmware, and
          software) must be informally shown to be consistent with the
          FTLS.  The elements of the FTLS must be shown, using
          informal techniques, to correspond to the elements of the
          TCB.  The FTLS must express the unified protection mechanism
          required to satisfy the security policy, and it is the
          elements of this protection mechanism that are mapped to the
          elements of the TCB.

          * Formal analysis techniques must be used to identify and
          analyze covert channels.  Informal techniques may be used to
          identify covert timing channels.  The continued existence of
          identified covert channels in the system must be justified.

In keeping with the extensive design and development analysis of the TCB
required of systems in class (A1), more stringent configuration management is
required and procedures are established for securely distributing the system
to sites.  A system security administrator is supported.

The following are minimal requirements for systems assigned a class (A1)
rating:

4.1.1  Security Policy

     4.1.1.1   Discretionary Access Control

               The TCB shall define and control access between named users and
               named objects (e.g., files and programs) in the ADP system.  
               The enforcement mechanism (e.g., access control lists) shall 
               allow users to specify and control sharing of those objects,
               and shall provide controls to limit propagation of access
               rights.  The discretionary access control mechanism shall,
               either by explicit user action or by default, provide that
               objects are protected from unauthorized access.  These access
               controls shall be capable of specifying, for each named object,
               a list of named individuals and a list of groups of named
               individuals with their respective modes of access to that
               object.  Furthermore, for each such named object, it shall be
               possible to specify a list of named individuals and a list of
               groups of named individuals for which no access to the object is
               to be given.  Access permission to an object by users not
               already possessing access permission shall only be assigned by
               authorized users.

     4.1.1.2   Object Reuse

               All authorizations to the information contained within a
               storage object shall be revoked prior to initial assignment,
               allocation or reallocation to a subject from the TCB's pool
               of unused storage objects.  No information, including encrypted
               representations of information, produced by a prior subject's
               actions is to be available to any subject that obtains access
               to an object that has been released back to the system.

     4.1.1.3   Labels

               Sensitivity labels associated with each ADP system resource
               (e.g., subject, storage object, ROM) that is directly or
               indirectly accessible by subjects external to the TCB shall be
               maintained by the TCB.  These labels shall be used as the basis
               for mandatory access control decisions.  In order to import 
               non-labeled data, the TCB shall request and receive from an 
               authorized user the security level of the data, and all such
               actions shall be auditable by the TCB.

          4.1.1.3.1  Label Integrity

                     Sensitivity labels shall accurately represent security
                     levels of the specific subjects or objects with which 
                     they are associated.  When exported by the TCB,
                     sensitivity labels shall accurately and unambiguously
                     represent the internal labels and shall be associated 
                     with the information being exported.

          4.1.1.3.2  Exportation of Labeled Information

                     The TCB shall designate each communication channel and
                     I/O device as either single-level or multilevel.  Any 
                     change in this designation shall be done manually and
                     shall be auditable by the TCB.  The TCB shall maintain
                     and be able to audit any change in the security level
                     or levels associated with a communication channel or 
                     I/O device.

               4.1.1.3.2.1  Exportation to Multilevel Devices

                            When the TCB exports an object to a multilevel I/O
                            device, the sensitivity label associated with that
                            object shall also be exported and shall reside on
                            the same physical medium as the exported 
                            information and shall be in the same form (i.e., 
                            machine-readable or human-readable form).  When
                            the TCB exports or imports an object over a
                            multilevel communication channel, the protocol 
                            used on that channel shall provide for the
                            unambiguous pairing between the sensitivity labels
                            and the associated information that is sent or 
                            received.

               4.1.1.3.2.2  Exportation to Single-Level Devices

                            Single-level I/O devices and single-level
                            communication channels are not required to 
                            maintain the sensitivity labels of the information
                            they process.  However, the TCB shall include a 
                            mechanism by which the TCB and an authorized user
                            reliably communicate to designate the single
                            security level of information imported or exported
                            via single-level communication channels or I/O 
                            devices.

               4.1.1.3.2.3  Labeling Human-Readable Output

                            The ADP system administrator shall be able to
                            specify the printable label names associated with
                            exported sensitivity labels.  The TCB shall mark
                            the beginning and end of all human-readable, paged,
                            hardcopy output (e.g., line printer output) with 
                            human-readable sensitivity labels that properly*
                            represent the sensitivity of the output.  The TCB
                            shall, by default, mark the top and bottom of each
                            page of human-readable, paged, hardcopy output
                            (e.g., line printer output) with human-readable 
                            sensitivity labels that properly* represent the
                            overall sensitivity of the output or that 
                            properly* represent the sensitivity of the 
                            information on the page.  The TCB shall, by
                            default and in an appropriate manner, mark other
                            forms of human-readable output (e.g., maps,
                            graphics) with human-readable sensitivity labels
                            that properly* represent the sensitivity of the 
                            output.  Any override of these marking defaults
                            shall be auditable by the TCB.

          4.1.1.3.3  Subject Sensitivity Labels

                     The TCB shall immediately notify a terminal user of each
                     change in the security level associated with that user 
                     during an interactive session.  A terminal user shall be
                     able to query the TCB as desired for a display of the
                     subject's complete sensitivity label.

          4.1.1.3.4  Device Labels

                     The TCB shall support the assignment of minimum and
                     maximum security levels to all attached physical devices.
                     These security levels shall be used by the TCB to enforce
                     constraints imposed by the physical environments in which
                     the devices are located.

     4.1.1.4   Mandatory Access Control

               The TCB shall enforce a mandatory access control policy over
               all resources (i.e., subjects, storage objects, and I/O 
               devices) that are directly or indirectly accessible by subjects
               external to the TCB.  These subjects and objects shall be
               assigned sensitivity labels that are a combination of
               hierarchical classification levels and non-hierarchical
               categories, and the labels shall be used as the basis for 
               mandatory access control decisions.  The TCB shall be able to
               support two or more such security levels.  (See the Mandatory
               Access Control guidelines.) The following requirements shall
               hold for all accesses between all subjects external to the TCB
               and all objects directly or indirectly accessible by these 
               subjects: A subject can read an object only if the hierarchical
               classification in the subject's security level is greater than
               or equal to the hierarchical classification in the object's
               security level and the non-hierarchical categories in the
               subject's security level include all the non-hierarchical
               categories in the object's security level.  A subject can write
______________________________
* The hierarchical classification component in human-readable sensitivity
labels shall be equal to the greatest hierarchical classification of any of the
information in the output that the labels refer to; the non-hierarchical
category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical
categories.

               an object only if the hierarchical classification in the 
               subject's security level is less than or equal to the
               hierarchical classification in the object's security level and
               all the non-hierarchical categories in the subject's security 
               level are included in the non- hierarchical categories in the 
               object's security level.  Identification and authentication 
               data shall be used by the TCB to authenticate the user's
               identity and to ensure that the security level and authoriza-
               tion of subjects external to the TCB that may be created to
               act on behalf of the individual user are dominated by the
               clearance and authorization of that user.

4.1.2  Accountability

     4.1.2.1   Identification and Authentication

               The TCB shall require users to identify themselves to it before
               beginning to perform any other actions that the TCB is expected
               to mediate.  Furthermore, the TCB shall maintain authentication
               data that includes information for verifying the identity of
               individual users (e.g., passwords) as well as information for
               determining the clearance and authorizations of individual
               users.  This data shall be used by the TCB to authenticate the
               user's identity and to ensure that the security level and 
               authorizations of subjects external to the TCB that may be
               created to act on behalf of the individual user are dominated by
               the clearance and authorization of that user.  The TCB shall
               protect authentication data so that it cannot be accessed by any
               unauthorized user.  The TCB shall be able to enforce individual
               accountability by providing the capability to uniquely identify
               each individual ADP system user.  The TCB shall also provide the
               capability of associating this identity with all auditable
               actions taken by that individual.

          4.1.2.1.1  Trusted Path

                     The TCB shall support a trusted communication path
                     between itself and users for use when a positive TCB-to-
                     user connection is required (e.g., login, change subject
                     security level).  Communications via this trusted path
                     shall be activated exclusively by a user or the TCB and
                     shall be logically isolated and unmistakably 
                     distinguishable from other paths.

     4.1.2.2   Audit

               The TCB shall be able to create, maintain, and protect from
               modification or unauthorized access or destruction an audit 
               trail of accesses to the objects it protects.  The audit data
               shall be protected by the TCB so that read access to it is
               limited to those who are authorized for audit data.  The TCB
               shall be able to record the following types of events: use of
               identification and authentication mechanisms, introduction of
               objects into a user's address space (e.g., file open, program
               initiation), deletion of objects, and actions taken by computer
               operators and system administrators and/or system security
               officers, and other security relevant events.  The TCB shall
               also be able to audit any override of human-readable output
               markings.  For each recorded event, the audit record shall
               identify: date and time of the event, user, type of event, and
               success or failure of the event.  For identification/
               authentication events the origin of request (e.g., terminal ID)
               shall be included in the audit record.  For events that
               introduce an object into a user's address space and for object
               deletion events the audit record shall include the name of the
               object and the object's security level.  The ADP system
               administrator shall be able to selectively audit the actions of
               any one or more users based on individual identity and/or object
               security level.  The TCB shall be able to audit the identified
               events that may be used in the exploitation of covert storage
               channels.  The TCB shall contain a mechanism that is able to
               monitor the occurrence or accumulation of security auditable
               events that may indicate an imminent violation of security
               policy.  This mechanism shall be able to immediately notify the
               security administrator when thresholds are exceeded, and, if
               the occurrence or accumulation of these security relevant
               events continues, the system shall take the least disruptive
               action to terminate the event.
     
4.1.3  Assurance

     4.1.3.1   Operational Assurance

          4.1.3.1.1  System Architecture
     
                     The TCB shall maintain a domain for its own execution
                     that protects it from external interference or tampering
                     (e.g., by modification of its code or data structures).
                     The TCB shall maintain process isolation through the
                     provision of distinct address spaces under its control.
                     The TCB shall be internally structured into well-defined
                     largely independent modules.  It shall make effective use
                     of available hardware to separate those elements that are
                     protection-critical from those that are not.  The TCB
                     modules shall be designed such that the principle of 
                     least privilege is enforced.  Features in hardware, such
                     as segmentation, shall be used to support logically 
                     distinct storage objects with separate attributes (namely:
                     readable, writeable).  The user interface to the TCB 
                     shall be completely defined and all elements of the TCB 
                     identified.  The TCB shall be designed and structured to
                     use a complete, conceptually simple protection mechanism
                     with precisely defined semantics.  This mechanism shall 
                     play a central role in enforcing the internal structuring
                     of the TCB and the system.  The TCB shall incorporate
                     significant use of layering, abstraction and data hiding.
                     Significant system engineering shall be directed toward 
                     minimizing the complexity of the TCB and excluding from
                     the TCB modules that are not protection-critical.

          4.1.3.1.2  System Integrity

                     Hardware and/or software features shall be provided that
                     can be used to periodically validate the correct 
                     operation of the on-site hardware and firmware elements
                     of the TCB.

          4.1.3.1.3  Covert Channel Analysis

                     The system developer shall conduct a thorough search for
                     covert channels and make a determination (either by 
                     actual measurement or by engineering estimation) of the
                     maximum bandwidth of each identified channel.  (See the
                     Covert Channels Guideline section.)  Formal methods shall
                     be used in the analysis.

          4.1.3.1.4  Trusted Facility Management

                     The TCB shall support separate operator and administrator
                     functions.  The functions performed in the role of a 
                     security administrator shall be identified.  The ADP
                     system administrative personnel shall only be able to
                     perform security administrator functions after taking a 
                     distinct auditable action to assume the security
                     administrator role on the ADP system.  Non-security
                     functions that can be performed in the security 
                     administration role shall be limited strictly to those
                     essential to performing the security role effectively.

          4.1.3.1.5  Trusted Recovery

                     Procedures and/or mechanisms shall be provided to assure
                     that, after an ADP system failure or other discontinuity,
                     recovery without a protection compromise is obtained.

     4.1.3.2   Life-Cycle Assurance

          4.1.3.2.1  Security Testing

                     The security mechanisms of the ADP system shall be tested
                     and found to work as claimed in the system documentation.
                     A team of individuals who thoroughly understand the
                     specific implementation of the TCB shall subject its
                     design documentation, source code, and object code to
                     thorough analysis and testing.  Their objectives shall 
                     be: to uncover all design and implementation flaws that
                     would permit a subject external to the TCB to read,
                     change, or delete data normally denied under the 
                     mandatory or discretionary security policy enforced by 
                     the TCB; as well as to assure that no subject (without
                     authorization to do so) is able to cause the TCB to enter
                     a state such that it is unable to respond to 
                     communications initiated by other users.  The TCB shall 
                     be found resistant to penetration.  All discovered flaws
                     shall be corrected and the TCB retested to demonstrate 
                     that they have been eliminated and that new flaws have
                     not been introduced.  Testing shall demonstrate that the
                     TCB implementation is consistent with the formal top-
                     level specification.  (See the Security Testing 
                     Guidelines.)  No design flaws and no more than a few
                     correctable implementation flaws may be found during
                     testing and there shall be reasonable confidence that few
                     remain.  Manual or other mapping of the FTLS to the
                     source code may form a basis for penetration testing.

          4.1.3.2.2  Design Specification and Verification

                     A formal model of the security policy supported by the
                     TCB shall be maintained over the life-cycle of the ADP
                     system that is proven consistent with its axioms.  A
                     descriptive top-level specification (DTLS) of the TCB
                     shall be maintained that completely and accurately
                     describes the TCB in terms of exceptions, error messages,
                     and effects. A formal top-level specification (FTLS) of
                     the TCB shall be maintained that accurately describes the
                     TCB in terms of exceptions, error messages, and effects. 
                     The DTLS and FTLS shall include those components of the
                     TCB that are implemented as hardware and/or firmware if