Department of Defense Trusted Computer System Evaluation Criteria

June-15-08

Department of Defense Trusted Computer System Evaluation Criteria

admin under Government and Police Information

CSC-STD-001-83
Library No. S225,711

DEPARTMENT OF DEFENSE

TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA

15 August 1983

CSC-STD-001-83

FOREWORD

This publication, "Department of Defense Trusted Computer System Evaluation
Criteria," is being issued by the DoD Computer Security Center under the
authority of and in accordance with DoD Directive 5215.1, "Computer Security
Evaluation Center." The criteria defined in this document constitute a uniform
set of basic requirements and evaluation classes for assessing the
effectiveness of security controls built into Automatic Data Processing (ADP)
systems. These criteria are intended for use in the evaluation and selection
of ADP systems being considered for the processing and/or storage and
retrieval of sensitive or classified information by the Department of Defense.
Point of contact concerning this publication is the Office of Standards and
Products, Attention: Chief, Computer Security Standards.

____________________________ 15 August 1983
Melville H. Klein
Director
DoD Computer Security Center

ACKNOWLEDGMENTS

Special recognition is extended to Sheila L. Brand, DoD Computer Security
Center (DoDCSC), 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, Col. Roger R. Schell,
Marvin Schaefer, DoDCSC, and Theodore M. P. Lee, Sperry UNIVAC, who as
original architects formulated and articulated the technical issues and
solutions presented in this document; Jeff Makey and Warren F. Shadle,
DoDCSC, 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.

TABLE OF CONTENTS

FOREWORD. . . . . . . . . . . . . . . . . . . . . . . . . . . .i
ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . ii
PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . .1

PART I: THE CRITERIA
Section
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. Though the criteria are
application-independent, it is recognized that the specific security feature
requirements may have to be interpreted when applying the criteria to specific
applications or other special processing environments. 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 respectivley, 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
to both trusted general-purpose and trusted embedded (e.g., those dedicated to
a specific application) automatic data processing (ADP) systems. 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. 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 developed for a number of
reasons:

* To provide users 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 guidance 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 for sensitive applications.

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

With respect to the first purpose for development of the criteria, i.e.,
providing users 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]

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

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

WHEN A STORAGE OBJECT IS INITIALLY ASSIGNED, ALLOCATED, OR
REALLOCATED TO A SUBJECT
FROM THE TCB’S POOL OF UNUSED STORAGE
OBJECTS, THE TCB SHALL ASSURE THAT THE OBJECT CONTAINS
NO DATA
FOR WHICH THE SUBJECT IS NOT AUTHORIZED.

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 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. 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 and results of the security
mechanisms’ functional testing.

2.2.4.4 Design Documentation

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

When a storage object is initially assigned, allocated, or
reallocated to a subject
from the TCB’s pool of unused storage
objects, the TCB shall assure that the object contains
no data
for which the subject is not authorized.

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 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
CURRENT SECURITY
LEVEL ASSOCIATED WITH A SINGLE-LEVEL 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, 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.

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

_____________________________________________________________

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.

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 OF INDIVIDUAL
USERS. THIS DATA SHALL BE USED BY THE TCB TO AUTHENTICATE the /> user’s identity AND TO DETERMINE THE SECURITY LEVEL AND
AUTHORIZATIONS OF SUBJECTS THAT
MAY BE CREATED TO ACT ON BEHALF
OF THE INDIVIDUAL 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. 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 THAT IS SHOWN 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

3.1.4.3 Test Documentation

The system developer shall provide to the evaluators a document
that describes the test
plan 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. 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

3.2.1.3 Labels

Sensitivity labels associated with each ADP SYSTEM RESOURCE
(E.G., SUBJECT, STORAGE
OBJECT) 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
current security
level associated with a single-level 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.

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

_____________________________________________________________

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.

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 determine the security level and
authorizations of subjects that may
be created to act on behalf
of the individual 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. 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 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
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.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 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 TAMPERPROOF, 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.3.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.
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

3.3.1.3 Labels

Sensitivity labels associated with each ADP system resource
(e.g., subject, storage
object) 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

3.3.1.3.2 Exportation of Labeled Information

3.3.1.3.2.1 Exportation to Multilevel Devices

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

_____________________________________________________________

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

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.

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 determine the security level and
authorizations of subjects that
may be created to act on behalf
of the individual 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
OR 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. 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.

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

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

4.1.1.3 Labels

4.1.1.3.1 Label Integrity

4.1.1.3.2 Exportation of Labeled Information

4.1.1.3.2.1 Exportation to Multilevel Devices

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

____________________________________________________________________

4.1.1.3.3 Subject Sensitivity Labels

4.1.1.3.4 Device Labels

4.1.1.4 Mandatory Access Control

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 determine the security level and
authorizations of subjects that
may be created to act on behalf
of the individual 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. 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.

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

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 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 THEIR PROPERTIES ARE VISIBLE AT THE
TCB
INTERFACE. 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. 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.

4.1.3.2.3 Configuration Management

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

4.1.3.2.4 Trusted Distribution

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.

4.1.4 DOCUMENTATION

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

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

4.1.4.3 Test Documentation

The system developer shall provide to the evaluators a document
that describes the test
plan 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. THE
RESULTS OF THE MAPPING BETWEEN THE
FORMAL TOP-LEVEL SPECIFICATION AND THE TCB SOURCE CODE
SHALL BE
GIVEN.

4.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.
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 tamperproof, 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 FORMAL TOP- LEVEL SPECIFICATION (FTLS).
The
elements of the FTLS 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.)
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.

4.2 BEYOND CLASS (A1)

Most of the security enhancements envisioned for systems that will provide
features and assurance in addition to that already provided by class (Al)
systems are beyond current technology. The discussion below is intended to
guide future work and is derived from research and development activities
already underway in both the public and private sectors. As more and better
analysis techniques are developed, the requirements for these systems will
become more explicit. In the future, use of formal verification will be
extended to the source level and covert timing channels will be more fully
addressed. At this level the design environment will become important and
testing will be aided by analysis of the formal top-level specification.
Consideration will be given to the correctness of the tools used in TCB
development (e.g., compilers, assemblers, loaders) and to the correct
functioning of the hardware/firmware on which the TCB will run. Areas to be
addressed by systems beyond class (A1) include:

* System Architecture

A demonstration (formal or otherwise) must be given showing
that requirements of
self-protection and completeness for
reference monitors have been implemented in the TCB. />

* Security Testing

Although beyond the current state-of-the-art, it is
envisioned that some test-case
generation will be done
automatically from the formal top-level specification or
formal
lower-level specifications.

* Formal Specification and Verification

The TCB must be verified down to the source code level,
using formal verification
methods where feasible. Formal
verification of the source code of the security-relevant

portions of an operating system has proven to be a difficult
task. Two important
considerations are the choice of a
high-level language whose semantics can be fully and

formally expressed, and a careful mapping, through
successive stages, of the abstract formal
design to a
formalization of the implementation in low-level
specifications. Experience
has shown that only when the
lowest level specifications closely correspond to the actual /> code can code proofs be successfully accomplished.

* Trusted Design Environment

The TCB must be designed in a trusted facility with only
trusted (cleared)
personnel.

PART II:

5.0 CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS

The criteria are divided within each class into groups of requirements. These
groupings were developed to assure that three basic control objectives for
computer security are satisfied and not overlooked. These control objectives
deal with:

* Security Policy
* Accountability
* Assurance

This section provides a discussion of these general control objectives and
their implication in terms of designing trusted systems.

5.1 A Need for Consensus

A major goal of the DoD Computer Security Center is to encourage the Computer
Industry to develop trusted computer systems and products, making them widely
available in the commercial market place. Achievement of this goal will
require recognition and articulation by both the public and private sectors of
a need and demand for such products.

As described in the introduction to this document, efforts to define the
problems and develop solutions associated with processing nationally sensitive
information, as well as other sensitive data such as financial, medical, and
personnel information used by the National Security Establishment, have been
underway for a number of years. The cri

Department of Defense Trusted Computer System Evaluation Criteria

The trusted computer system evaluation criteria defined in this document classify systems into four broad hierarchical divisions of enhanced security protection

Department of Defense Trusted Computer System Evaluation Criteria