  Orange Book Appendices
  NCSC/DOD/NIST (SGML by Andrew G. Morgan)
  December 1985 (translation 1996/12/31)

  HHiigghhlliigghhttiinngg is used for emphasis





























































  AA..  CCOOMMMMEERRCCIIAALL PPRROODDUUCCEE EEVVAALLUUAATTIIOONN PPRROOCCEESSSS

  "Department of Defense Trusted Computer System Evaluation Criteria"
  forms the basis upon which the Computer Security Center will carry out
  the commercial computer security evaluation process.  This process is
  focused on commercially produced and supported general-purpose
  operating system products that meet the needs of government
  departments and agencies.  The formal evaluation is aimed at "off-the-
  shelf" commercially supported products and is completely divorced from
  any consideration of overall system performance, potential
  applications, or particular processing environments.  The evaluation
  provides a key input to a computer system security
  approval/accreditation.  However, it does not constitute a complete
  computer system security evaluation.  A complete study (e.g., as in
  reference 18) must consider additional factors dealing with the system
  in its unique environment, such as it's proposed security mode of
  operation, specific users, applications, data sensitivity, physical
  and personnel security, administrative and procedural security,
  TEMPEST, and communications security.


  The product evaluation process carried out by the Computer Security
  Center has three distinct elements:



  +o  Preliminary Product Evaluation - An informal dialogue between a
     vendor and the Center in which technical information is exchanged
     to create a common understanding of the vendor's product, the
     criteria, and the rating that may be expected to result from a
     formal product evaluation.

  +o  Formal Product Evaluation - A formal evaluation, by the Center, of
     a product that is available to the DoD, and that results in that
     product and its assigned rating being placed on the Evaluated
     Products List.

  +o  Evaluated Products List - A list of products that have been
     subjected to formal product evaluation and their assigned ratings.


  AA..11..  PPrreelliimmiinnaarryy PPrroodduucctt EEvvaalluuaattiioonn

  Since it is generally very difficult to add effective security
  measures late in a product's life cycle, the Center is interested in
  working with system vendors in the early stages of product design.  A
  preliminary product evaluation allows the Center to consult with
  computer vendors on computer security issues found in products that
  have not yet been formally announced.


  A preliminary evaluation is typically initiated by computer system
  vendors who are planning new computer products that feature security
  or major security-related upgrades to existing products.  After an
  initial meeting between the vendor and the Center, appropriate non-
  disclosure agreements are executed that require the Center to maintain
  the confidentiality of any proprietary information disclosed to it.
  Technical exchange meetings follow in which the vendor provides
  details about the proposed product (particularly its internal designs
  and goals) and the Center provides expert feedback to the vendor on
  potential computer security strengths and weaknesses of the vendor's
  design choices, as well as relevant interpretation of the criteria.
  The preliminary evaluation is typically terminated when the product is
  completed and ready for field release by the vendor.  Upon
  termination, the Center prepares a wrap-up report for the vendor and
  for internal distribution within the Center.  Those reports containing
  proprietary information are not available to the public.


  During preliminary evaluation, the vendor is under no obligation to
  actually complete or market the potential product.  The Center is,
  likewise, not committed to conduct a formal product evaluation.  A
  preliminary evaluation may be terminated by either the Center or the
  vendor when one notifies the other, in writing, that it is no longer
  advantageous to continue the evaluation.



  AA..22..  FFoorrmmaall PPrroodduucctt EEvvaalluuaattiioonn

  The formal product evaluation provides a key input to certification of
  a computer system for use in National Security Establishment
  applications and is the sole basis for a product being placed on the
  Evaluated Products List.


  A formal product evaluation begins with a request by a vendor for the
  Center to evaluate a product for which the product itself and
  accompanying documentation needed to meet the requirements defined by
  this publication are complete.  Non-disclosure agreements are executed
  and a formal product evaluation team is formed by the Center.  An
  initial meeting is then held with the vendor to work out the schedule
  for the formal evaluation.  Since testing of the implemented product
  forms an important part of the evaluation process, access by the
  evaluation team to a working version of the system is negotiated with
  the vendor.  Additional support required from the vendor includes
  complete design documentation, source code, and access to vendor
  personnel who can answer detailed questions about specific portions of
  the product.  The evaluation team tests the product against each
  requirement, making any necessary interpretations of the criteria with
  respect to the product being evaluated.


  The evaluation team writes a final report on their findings about the
  system.  The report is publicly available (containing no proprietary
  or sensitive information) and contains the overall class rating
  assigned to the system and the details of the evalution team's
  findings when comparing the product against the evaluation criteria.
  Detailed information concerning vulnerabilities found by the
  evaluation team is furnished to the system developers and designers as
  each is found so that the vendor has a chance to eliminate as many of
  them as possible prior to the completion of the Formal Product
  Evaluation.  Vulnerability analyses and other proprietary or sensitive
  information are controlled within the Center through the Vulnerability
  Reporting Program and are distributed only within the U.S. Government
  on a strict need-to-know and non-disclosure basis, and to the vendor.
















  BB..  SSUUMMMMAARRYY OOFF EEVVAALLUUAATTIIOONN CCRRIITTEERRIIAA DDIIVVIISSIIOONNSS

  The divisions of systems recognized under the trusted computer system
  evaluation criteria are as follows.  Each division represents a major
  improvement in the overall confidence one can place in the system to
  protect classified and other sensitive information.


  BB..11..  DDiivviissiioonn ((DD))::  MMiinniimmaall PPrrootteeccttiioonn

  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.


  BB..22..  DDiivviissiioonn ((CC))::  DDiissccrreettiioonnaarryy PPrrootteeccttiioonn

  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.


  BB..33..  DDiivviissiioonn ((BB))::  MMaannddaattoorryy PPrrootteeccttiioonn

  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.


  BB..44..  DDiivviissiioonn ((AA))::  VVeerriiffiieedd PPrrootteeccttiioonn

  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.























  CC..  SSUUMMMMAARRYY OOFF EEVVAALLUUAATTIIOONN CCRRIITTEERRIIAA CCLLAASSSSEESS

  The classes of systems recognized under the trusted computer system
  evaluation criteria are as follows.  They are presented in the order
  of increasing desirablity from a computer security point of view.


  CC..11..  CCllaassss ((DD))::  MMiinniimmaall PPrrootteeccttiioonn

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


  CC..22..  CCllaassss ((CC11))::  DDiissccrreettiioonnaarryy SSeeccuurriittyy PPrrootteeccttiioonn

  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.


  CC..33..  CCllaassss ((CC22))::  CCoonnttrroolllleedd AAcccceessss PPrrootteeccttiioonn

  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.


  CC..44..  CCllaassss ((BB11))::  LLaabbeelleedd SSeeccuurriittyy PPrrootteeccttiioonn

  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.


  CC..55..  CCllaassss ((BB22))::  SSttrruuccttuurreedd PPrrootteeccttiioonn

  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.


  CC..66..  CCllaassss ((BB33))::  SSeeccuurriittyy DDoommaaiinnss

  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.


  CC..77..  CCllaassss ((AA11))::  VVeerriiffiieedd DDeessiiggnn

  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.  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.











































  DD..  RREEQQUUIIRREEMMEENNTT DDIIRREECCTTOORRYY

  This appendix lists requirements defined in "Department of Defense
  Trusted Computer System Evaluation Criteria" alphabetically rather
  than by class.  It is provided to assist in following the evolution of
  a requirement through the classes.  For each requirement, three types
  of criteria may be present.  Each will be preceded by the word: NEW,
  CHANGE, or ADD to indicate the following:




     _N_E_W::
        Any criteria appearing in a lower class are superseded by the
        criteria that follow.


     _C_H_A_N_G_E::
        The criteria that follow have appeared in a lower class but are
        changed for this class.  Highlighting is used to indicate the
        specific changes to previously stated criteria.


     _A_D_D::
        The criteria that follow have not been required for any lower
        class, and are added in this class to the previously stated
        criteria for this requirement.



  Abbreviations are used as follows:


     _N_R::
        (No Requirement) This requirement is not included in this class.


     _N_A_R::
        (No Additional Requirements) This requirement does not change
        from the previous class.


  The reader is referred to Part I of this document when placing new
  criteria for a requirement into the complete context for that class.


  Figure 1 provides a pictorial summary of the evolution of requirements
  through the classes. (AGM - the figure is not included at this time)


  DD..11..  AAuuddiitt



     CC11::
        _N_R.


     CC22::
        _N_E_W: 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.  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.


     BB11::
        _C_H_A_N_G_E: 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.

        _A_D_D: The TCB shall also be able to audit any override of human-
        readable output markings.


     BB22::
        _A_D_D: The TCB shall be able to audit the identified events that
        may be used in the exploitation of covert storage channels.


     BB33::
        _A_D_D: 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 lease disruptive action to
        terminate the event.


     AA11::
        _N_A_R.


  DD..22..  CCoonnffiigguurraattiioonn MMaannaaggeemmeenntt


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_R.


     BB22::
        _N_E_W: 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.


     BB33::
        _N_A_R.


     AA11::
        _C_H_A_N_G_E: During the entire life-cycle, i.e., during the design,
        development, and maintenance of the TCB, a configuration
        management system shall be in place for all security-relevant
        hardware, firmware, and software that maintains control of
        changes to the formal model, the descriptive and formal top-
        level specifications, other design data, implementation
        documentation, source code, the running version of the object
        code, and test fixtures and documentation.  Also available shall
        be tools, maintained under strict configuration control, 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.

        _A_D_D: A combination of technical, physical, and procedural
        safeguards shall be used to protect from unauthorized
        modification or destruction the master copy or copies of all
        material used to generate the TCB.


  DD..33..  CCoovveerrtt CChhaannnneell AAnnaallyyssiiss


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_R.


     BB22::
        _N_E_W: 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.)


     BB33::
        _C_H_A_N_G_E: 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.

     AA11::
        _A_D_D: Formal methods shall be used in the analysis.


  DD..44..  DDeessiiggnn DDooccuummeennttaattiioonn



     CC11::
        _N_E_W: 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.


     CC22::
        _N_A_R.


     BB11::
        _A_D_D: 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.


     BB22::
        _C_H_A_N_G_E: 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.

        _A_D_D: 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.)


     BB33::
        _A_D_D: 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.


     AA11::
        _C_H_A_N_G_E: The TCB implementation (i.e., in hardware, firmware, and
        software) shall be informally shown to be consistent with the
        formal top-level specification (FTLS).  The elements of the FTLS
        shall be shown, using informal techniques, to correspond to the
        elements of the TCB.

        _A_D_D: Hardware, firmware, and software mechanisms not dealt with
        in the FTLS but strictly internal to the TCB (e.g., mapping
        registers, direct memory access I/O) shall be clearly described.


  DD..55..  DDeessiiggnn SSppeecciiffiiccaattiioonn aanndd VVeerriiffiiccaattiioonn


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_E_W: An informal or formal model of the security policy
        supported by the TCB shall be maintained over the life cycle of
        the ADP system that is shown to be consistent with its axioms.


     BB22::
        _C_H_A_N_G_E: 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_D_D: 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.


     BB33::
        _A_D_D: A convincing argument shall be given that the DTLS is
        consistent with the model.


     AA11::
        _C_H_A_N_G_E: The FTLS 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 and a combination of
        formal and informal techniques shall be used to show that the
        FTLS is consistent with the model.

        _A_D_D: 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 their properties are visible at
        the TCB interface.  This verification evidence shall be
        consistent with that provided within the state-of-the-art of the
        particular Computer Security Center- endorsed formal
        specification and verification system used.  Manual or other
        mapping of the FTLS to the TCB source code shall be performed to
        provide evidence of correct implementation.


  DD..66..  DDeevviiccee LLaabbeellss


     CC11::
        _N_R.



     CC22::
        _N_R.


     BB11::
        _N_R.


     BB22::
        _N_E_W: 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.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..77..  DDiissccrreettiioonnaarryy AAcccceessss CCoonnttrrooll


     CC11::
        _N_E_W: 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.


     CC22::
        _C_H_A_N_G_E: 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.

        _A_D_D: 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.


     BB11::
        _N_A_R.


     BB22::
        _N_A_R.


     BB33::
        _C_H_A_N_G_E: 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.  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.

        _A_D_D: 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.


     AA11::
        _N_A_R.


  DD..88..  EExxppoorrttaattiioonn ooff LLaabbeelleedd IInnffoorrmmaattiioonn


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_E_W: 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.


     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..99..  EExxppoorrttaattiioonn ttoo MMuullttiilleevveell DDeevviicceess


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_E_W: 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.
     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1100..  EExxppoorrttaattiioonn ttoo SSiinnggllee--LLeevveell DDeevviicceess


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_E_W: 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.


     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1111..  IIddeennttiiffiiccaattiioonn aanndd AAuutthheennttiiccaattiioonn


     CC11::
        _N_E_W: 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.


     CC22::
        _A_D_D: 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.



     BB11::
        _C_H_A_N_G_E: 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.



     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1122..  LLaabbeell IInntteeggrriittyy


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_E_W: 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.


     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1133..  LLaabbeelliinngg HHuummaann--RReeaaddaabbllee OOuuttppuutt


     CC11::
        _N_R.


     CC22::
        _N_R.

     BB11::
        _N_E_W: 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 ``(see footnote below)''
        represent the sensitivity of the output.  Any override of these
        marking defaults shall be auditable by the TCB.


     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.



  DD..1133..11..  FFoooottnnoottee ccoonncceerrnniinngg ""pprrooppeerrllyy""

  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.


  DD..1144..  LLaabbeellss


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_E_W: 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.


     BB22::
        _C_H_A_N_G_E: 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.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1155..  MMaannddaattoorryy AAcccceessss CCoonnttrrooll


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_E_W: 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 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.


     BB22::
        _C_H_A_N_G_E: 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.  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:


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1166..  OObbjjeecctt RReeuussee


     CC11::
        _N_R.


     CC22::
        _N_E_W: 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.


     BB11::
        _N_A_R.


     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1177..  SSeeccuurriittyy FFeeaattuurreess UUsseerr''ss GGuuiiddee


     CC11::
        _N_E_W: 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.


     CC22::
        _N_A_R.


     BB11::
        _N_A_R.


     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..1188..  SSeeccuurriittyy TTeessttiinngg


     CC11::
        _N_E_W: 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.)


     CC22::
        _A_D_D: 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.


     BB11::
        _N_E_W: 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.)


     BB22::
        _C_H_A_N_G_E: 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.


        _A_D_D: The TCB shall be found relatively resistant to penetration.
        Testing shall demonstrate that the TCB implementation is
        consistent with the descriptive top-level specification.


     BB33::
        _C_H_A_N_G_E: The TCB shall be found resistant to penetration.

        _A_D_D: 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.


     AA11::
        _C_H_A_N_G_E: Testing shall demonstrate that the TCB implementation is
        consistent with the formal top-level specification.


        _A_D_D: Manual or other mapping of the FTLS to the source code may
        form a basis for penetration testing.



  DD..1199..  SSuubbjjeecctt SSeennssiittiivviittyy LLaabbeellss



     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_R.


     BB22::
        _N_E_W: 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.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..2200..  SSyysstteemm AArrcchhiitteeccttuurree


     CC11::
        _N_E_W: 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.


     CC22::
        _A_D_D: The TCB shall isolate the resources to be protected so that
        they are subject to the access control and auditing
        requirements.


     BB11::
        _A_D_D: The TCB shall maintain process isolation through the
        provision of distinct address spaces under its control.


     BB22::
        _N_E_W: 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.


     BB33::
        _A_D_D: 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.


     AA11::
        _N_A_R.


  DD..2211..  SSyysstteemm IInntteeggrriittyy


     CC11::
        _N_E_W: 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.


     CC22::
        _N_A_R.


     BB11::
        _N_A_R.


     BB22::
        _N_A_R.


     BB33::
        _N_A_R.


     AA11::
        _N_A_R.


  DD..2222..  TTeesstt DDooccuummeennttaattiioonn



     CC11::
        _N_E_W: 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.


     CC22::
        _N_A_R.



     BB11::
        _N_A_R.


     BB22::
        _A_D_D: It shall include results of testing the effectiveness of
        the methods used to reduce covert channel bandwidths.


     BB33::
        _N_A_R.


     AA11::
        _A_D_D: The results of the mapping between the formal top-level
        specification and the TCB source code shall be given.


  DD..2233..  TTrruusstteedd DDiissttrriibbuuttiioonn


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_R.


     BB22::
        _N_R.


     BB33::
        _N_R.


     AA11::
        _N_E_W: A trusted ADP system control and distribution facility
        shall be provided for maintaining the integrity of the mapping
        between the master data describing the current version of the
        TCB and the on-site master copy of the code for the current
        version.  Procedures (e.g., site security acceptance testing)
        shall exist for assuring that the TCB software, firmware, and
        hardware updates distributed to a customer are exactly as
        specified by the master copies.


  DD..2244..  TTrruusstteedd FFaacciilliittyy MMaannaaggeemmeenntt


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_R.

     BB22::
        _N_E_W: The TCB shall support separate operator and administrator
        functions.


     BB33::
        _A_D_D: 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.


     AA11::
        _N_A_R.


  DD..2255..  TTrruusstteedd FFaacciilliittyy MMaannuuaall



     CC11::
        _N_E_W: A manual addressed to the ADP system administrator shall
        present cautions about functions and privileges that should be
        controlled when running a secure facility.


     CC22::
        _A_D_D: 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.


     BB11::
        _A_D_D: The manual shall describe the operator and administrator
        functions related to security, to include changing the
        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.


     BB22::
        _A_D_D: 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.


     BB33::
        _A_D_D: 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.


     AA11::
        _N_A_R.



  DD..2266..  TTrruusstteedd PPaatthh



     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_R.


     BB22::
        _N_E_W: 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.


     BB33::
        _C_H_A_N_G_E: 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.


     AA11::
        _N_A_R.


  DD..2277..  TTrruusstteedd RReeccoovveerryy


     CC11::
        _N_R.


     CC22::
        _N_R.


     BB11::
        _N_R.


     BB22::
        _N_R.


     BB33::
        _N_E_W: 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.


     AA11::
        _N_A_R.



  (this page is reserved for Figure 1 - not included AGM)

































































                            TTaabbllee ooff CCoonntteennttss


  A. COMMERCIAL PRODUCE EVALUATION PROCESS . . . . . . . . . . . . .   2
  A.1. Preliminary Product Evaluation  . . . . . . . . . . . . . . .   2
  A.2. Formal Product Evaluation . . . . . . . . . . . . . . . . . .   3
  B. SUMMARY OF EVALUATION CRITERIA DIVISIONS  . . . . . . . . . . .   4
  B.1. Division (D):  Minimal Protection . . . . . . . . . . . . . .   4
  B.2. Division (C):  Discretionary Protection . . . . . . . . . . .   4
  B.3. Division (B):  Mandatory Protection . . . . . . . . . . . . .   4
  B.4. Division (A):  Verified Protection  . . . . . . . . . . . . .   4
  C. SUMMARY OF EVALUATION CRITERIA CLASSES  . . . . . . . . . . . .   5
  C.1. Class (D):  Minimal Protection  . . . . . . . . . . . . . . .   5
  C.2. Class (C1):  Discretionary Security Protection  . . . . . . .   5
  C.3. Class (C2):  Controlled Access Protection . . . . . . . . . .   5
  C.4. Class (B1):  Labeled Security Protection  . . . . . . . . . .   5
  C.5. Class (B2):  Structured Protection  . . . . . . . . . . . . .   5
  C.6. Class (B3):  Security Domains . . . . . . . . . . . . . . . .   5
  C.7. Class (A1):  Verified Design  . . . . . . . . . . . . . . . .   6
  D. REQUIREMENT DIRECTORY . . . . . . . . . . . . . . . . . . . . .   7
  D.1. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
  D.2. Configuration Management  . . . . . . . . . . . . . . . . . .   8
  D.3. Covert Channel Analysis . . . . . . . . . . . . . . . . . . .   9
  D.4. Design Documentation  . . . . . . . . . . . . . . . . . . . .  10
  D.5. Design Specification and Verification . . . . . . . . . . . .  11
  D.6. Device Labels . . . . . . . . . . . . . . . . . . . . . . . .  11
  D.7. Discretionary Access Control  . . . . . . . . . . . . . . . .  12
  D.8. Exportation of Labeled Information  . . . . . . . . . . . . .  13
  D.9. Exportation to Multilevel Devices . . . . . . . . . . . . . .  13
  D.10. Exportation to Single-Level Devices  . . . . . . . . . . . .  14
  D.11. Identification and Authentication  . . . . . . . . . . . . .  14
  D.12. Label Integrity  . . . . . . . . . . . . . . . . . . . . . .  15
  D.13. Labeling Human-Readable Output . . . . . . . . . . . . . . .  15
  D.13.1. Footnote concerning "properly" . . . . . . . . . . . . . .  16
  D.14. Labels . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
  D.15. Mandatory Access Control . . . . . . . . . . . . . . . . . .  17
  D.16. Object Reuse . . . . . . . . . . . . . . . . . . . . . . . .  18
  D.17. Security Features User's Guide . . . . . . . . . . . . . . .  18
  D.18. Security Testing . . . . . . . . . . . . . . . . . . . . . .  19
  D.19. Subject Sensitivity Labels . . . . . . . . . . . . . . . . .  20
  D.20. System Architecture  . . . . . . . . . . . . . . . . . . . .  20
  D.21. System Integrity . . . . . . . . . . . . . . . . . . . . . .  21
  D.22. Test Documentation . . . . . . . . . . . . . . . . . . . . .  21
  D.23. Trusted Distribution . . . . . . . . . . . . . . . . . . . .  22
  D.24. Trusted Facility Management  . . . . . . . . . . . . . . . .  22
  D.25. Trusted Facility Manual  . . . . . . . . . . . . . . . . . .  23
  D.26. Trusted Path . . . . . . . . . . . . . . . . . . . . . . . .  24
  D.27. Trusted Recovery . . . . . . . . . . . . . . . . . . . . . .  24


















