DoD 5200.28-STD

Supersedes

CSC-STD-00l-83, dtd l5 Aug 83

Library No. S225,7ll

DEPARTMENT OF DEFENSE STANDARD

DEPARTMENT OF

DEFENSE

TRUSTED COMPUTER

SYSTEM EVALUATION

CRITERIA

DECEMBER l985

December 26, l985

FOREWORD

This publication, DoD 5200.28-STD, "Department of Defense Trusted Computer

System Evaluation Criteria," is issued under the authority of an in accordance

with DoD Directive 5200.28, "Security Requirements for Automatic Data

Processing (ADP) Systems," and in furtherance of responsibilities assigned by

DoD Directive 52l5.l, "Computer Security Evaluation Center." Its purpose is to

provide technical hardware/firmware/software security criteria and associated

technical evaluation methodologies in support of the overall ADP system

security policy, evaluation and approval/accreditation responsibilities

promulgated by DoD Directive 5200.28.

The provisions of this document apply to the Office of the Secretary of Defense

(ASD), the Military Departments, the Organization of the Joint Chiefs of Staff,

the Unified and Specified Commands, the Defense Agencies and activities

administratively supported by OSD (hereafter called "DoD Components").

This publication is effective immediately and is mandatory for use by all DoD

Components in carrying out ADP system technical security evaluation activities

applicable to the processing and storage of classified and other sensitive DoD

information and applications as set forth herein.

Recommendations for revisions to this publication are encouraged and will be

reviewed biannually by the National Computer Security Center through a formal

review process. Address all proposals for revision through appropriate

channels to: National Computer Security Center, Attention: Chief, Computer

Security Standards.

DoD Components may obtain copies of this publication through their own

publications channels. Other federal agencies and the public may obtain copies

from: Office of Standards and Products, National Computer Security Center,

Fort Meade, MD 20755-6000, Attention: Chief, Computer Security Standards.

_________________________________

Donald C. Latham

Assistant Secretary of Defense

(Command, Control, Communications, and Intelligence)

ACKNOWLEDGEMENTS

Special recognition is extended to Sheila L. Brand, National Computer Security

Center (NCSC), who integrated theory, policy, and practice into and directed

the production of this document.

Acknowledgment is also given for the contributions of: Grace Hammonds and

Peter S. Tasker, the MITRE Corp., Daniel J. Edwards, NCSC, Roger R. Schell,

former Deputy Director of NCSC, Marvin Schaefer, NCSC, and Theodore M. P. Lee,

Sperry Corp., who as original architects formulated and articulated the

technical issues and solutions presented in this document; Jeff Makey, formerly

NCSC, Warren F. Shadle, NCSC, and Carole S. Jordan, NCSC, who assisted in the

preparation of this document; James P. Anderson, James P. Anderson & Co.,

Steven B. Lipner, Digital Equipment Corp., Clark Weissman, System Development

Corp., LTC Lawrence A. Noble, formerly U.S. Air Force, Stephen T. Walker,

formerly DoD, Eugene V. Epperly, DoD, and James E. Studer, formerly Dept. of

the Army, who gave generously of their time and expertise in the review and

critique of this document; and finally, thanks are given to the computer

industry and others interested in trusted computing for their enthusiastic

advice and assistance throughout this effort.

CONTENTS

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

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

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

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

PART I: THE CRITERIA

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

2.0 DIVISION C: DISCRETIONARY PROTECTION. . . . . . . . . . 11

2.1 Class (C1): Discretionary Security Protection . . 12

2.2 Class (C2): Controlled Access Protection. . . . . 15

3.0 DIVISION B: MANDATORY PROTECTION. . . . . . . . . . . . 19

3.1 Class (B1): Labeled Security Protection . . . . . 20

3.2 Class (B2): Structured Protection . . . . . . . . 26

3.3 Class (B3): Security Domains. . . . . . . . . . . 33

4.0 DIVISION A: VERIFIED PROTECTION . . . . . . . . . . . . 41

4.1 Class (A1): Verified Design . . . . . . . . . . . 42

4.2 Beyond Class (A1). . . . . . . . . . . . . . . . . 51

PART II: RATIONALE AND GUIDELINES

5.0 CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS. . . . . 55

5.1 A Need for Consensus . . . . . . . . . . . . . . . 56

5.2 Definition and Usefulness. . . . . . . . . . . . . 56

5.3 Criteria Control Objective . . . . . . . . . . . . 56

6.0 RATIONALE BEHIND THE EVALUATION CLASSES. . . . . . . . . 63

6.1 The Reference Monitor Concept. . . . . . . . . . . 64

6.2 A Formal Security Policy Model . . . . . . . . . . 64

6.3 The Trusted Computing Base . . . . . . . . . . . . 65

6.4 Assurance. . . . . . . . . . . . . . . . . . . . . 65

6.5 The Classes. . . . . . . . . . . . . . . . . . . . 66

7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA . . . . 69

7.1 Established Federal Policies . . . . . . . . . . . 70

7.2 DoD Policies . . . . . . . . . . . . . . . . . . . 70

7.3 Criteria Control Objective For Security Policy . . 71

7.4 Criteria Control Objective for Accountability. . . 74

7.5 Criteria Control Objective for Assurance . . . . . 76

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

9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL

FEATURES . . . . . . . . . . . . . . . . . . . . . . . . 81

10.0 A GUIDELINE ON SECURITY TESTING . . . . . . . . . . . . 83

10.1 Testing for Division C . . . . . . . . . . . . . . 84

10.2 Testing for Division B . . . . . . . . . . . . . . 84

10.3 Testing for Division A . . . . . . . . . . . . . . 85

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

APPENDIX B: Summary of Evaluation Criteria Divisions . . . . 89

APPENDIX C: Sumary of Evaluation Criteria Classes. . . . . . 91

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

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

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

PREFACE

The trusted computer system evaluation criteria defined in this document

classify systems into four broad hierarchical divisions of enhanced security

protection. They provide a basis for the evaluation of effectiveness of

security controls built into automatic data processing system products. The

criteria were developed with three objectives in mind: (a) to provide users

with a yardstick with which to assess the degree of trust that can be placed

in computer systems for the secure processing of classified or other sensitive

information; (b) to provide guidance to manufacturers as to what to build into

their new, widely-available trusted commercial products in order to satisfy

trust requirements for sensitive applications; and (c) to provide a basis for

specifying security requirements in acquisition specifications. Two types of

requirements are delineated for secure processing: (a) specific security

feature requirements and (b) assurance requirements. Some of the latter

requirements enable evaluation personnel to determine if the required features

are present and functioning as intended. The scope of these criteria is to be

applied to the set of components comprising a trusted system, and is not

necessarily to be applied to each system component individually. Hence, some

components of a system may be completely untrusted, while others may be

individually evaluated to a lower or higher evaluation class than the trusted

product considered as a whole system. In trusted products at the high end of

the range, the strength of the reference monitor is such that most of the

components can be completely untrusted. Though the criteria are intended to be

application-independent, the specific security feature requirements may have to

be interpreted when applying the criteria to specific systems with their own

functional requirements, applications or special environments (e.g.,

communications processors, process control computers, and embedded systems in

general). The underlying assurance requirements can be applied across the

entire spectrum of ADP system or application processing environments without

special interpretation.

INTRODUCTION

Historical Perspective

In October 1967, a task force was assembled under the auspices of the Defense

Science Board to address computer security safeguards that would protect

classified information in remote-access, resource-sharing computer systems.

The Task Force report, "Security Controls for Computer Systems," published in

February 1970, made a number of policy and technical recommendations on

actions to be taken to reduce the threat of compromise of classified

information processed on remote-access computer systems.[34] Department of

Defense Directive 5200.28 and its accompanying manual DoD 5200.28-M, published

in 1972 and 1973 respectively, responded to one of these recommendations by

establishing uniform DoD policy, security requirements, administrative

controls, and technical measures to protect classified information processed

by DoD computer systems.[8;9] Research and development work undertaken by the

Air Force, Advanced Research Projects Agency, and other defense agencies in

the early and mid 70's developed and demonstrated solution approaches for the

technical problems associated with controlling the flow of information in

resource and information sharing computer systems.[1] The DoD Computer

Security Initiative was started in 1977 under the auspices of the Under

Secretary of Defense for Research and Engineering to focus DoD efforts

addressing computer security issues.[33]

Concurrent with DoD efforts to address computer security issues, work was

begun under the leadership of the National Bureau of Standards (NBS) to define

problems and solutions for building, evaluating, and auditing secure computer

systems.[17] As part of this work NBS held two invitational workshops on the

subject of audit and evaluation of computer security.[20;28] The first was

held in March 1977, and the second in November of 1978. One of the products

of the second workshop was a definitive paper on the problems related to

providing criteria for the evaluation of technical computer security

effectiveness.[20] As an outgrowth of recommendations from this report, and in

support of the DoD Computer Security Initiative, the MITRE Corporation began

work on a set of computer security evaluation criteria that could be used to

assess the degree of trust one could place in a computer system to protect

classified data.[24;25;31] The preliminary concepts for computer security

evaluation were defined and expanded upon at invitational workshops and

symposia whose participants represented computer security expertise drawn from

industry and academia in addition to the government. Their work has since

been subjected to much peer review and constructive technical criticism from

the DoD, industrial research and development organizations, universities, and

computer manufacturers.

The DoD Computer Security Center (the Center) was formed in January 1981 to

staff and expand on the work started by the DoD Computer Security

Initiative.[15] A major goal of the Center as given in its DoD Charter is to

encourage the widespread availability of trusted computer systems for use by

those who process classified or other sensitive information.[10] The criteria

presented in this document have evolved from the earlier NBS and MITRE

evaluation material.

Scope

The trusted computer system evaluation criteria defined in this document apply

primarily to trusted commercially available automatic data processing (ADP)

systems. They are also applicable, as amplified below, the the evaluation of

existing systems and to the specification of security requirements for ADP

systems acquisition. Included are two distinct sets of requirements: 1)

specific security feature requirements; and 2) assurance requirements. The

specific feature requirements encompass the capabilities typically found in

information processing systems employing general-purpose operating systems that

are distinct from the applications programs being supported. However, specific

security feature requirements may also apply to specific systems with their own

functional requirements, applications or special environments (e.g.,

communications processors, process control computers, and embedded systems in

general). The assurance requirements, on the other hand, apply to systems that

cover the full range of computing environments from dedicated controllers to

full range multilevel secure resource sharing systems.

Purpose

As outlined in the Preface, the criteria have been developedto serve a number

of intended purposes:

* To provide a standard to manufacturers as to what security

features to build into their new and planned, commercial

products in order to provide widely available systems that

satisfy trust requirements (with particular emphasis on preventing

the disclosure of data) for sensitive applications.

* To provide DoD components with a metric with which to evaluate

the degree of trust that can be placed in computer systems for

the secure processing of classified and other sensitive

information.

* To provide a basis for specifying security requirements in

acquisition specifications.

With respect to the second purpose for development of the criteria, i.e.,

providing DoD components with a security evaluation metric, evaluations can be

delineated into two types: (a) an evaluation can be performed on a computer

product from a perspective that excludes the application environment; or, (b)

it can be done to assess whether appropriate security measures have been taken

to permit the system to be used operationally in a specific environment. The

former type of evaluation is done by the Computer Security Center through the

Commercial Product Evaluation Process. That process is described in Appendix

A.

The latter type of evaluation, i.e., those done for the purpose of assessing a

system's security attributes with respect to a specific operational mission,

is known as a certification evaluation. It must be understood that the

completion of a formal product evaluation does not constitute certification or

accreditation for the system to be used in any specific application

environment. On the contrary, the evaluation report only provides a trusted

computer system's evaluation rating along with supporting data describing the

product system's strengths and weaknesses from a computer security point of

view. The system security certification and the formal approval/accreditation

procedure, done in accordance with the applicable policies of the issuing

agencies, must still be followed-before a system can be approved for use in

processing or handling classified information.[8;9] Designated Approving

Authorities (DAAs) remain ultimately responsible for specifying security of

systems they accredit.

The trusted computer system evaluation criteria will be used directly and

indirectly in the certification process. Along with applicable policy, it

will be used directly as technical guidance for evaluation of the total system

and for specifying system security and certification requirements for new

acquisitions. Where a system being evaluated for certification employs a

product that has undergone a Commercial Product Evaluation, reports from that

process will be used as input to the certification evaluation. Technical data

will be furnished to designers, evaluators and the Designated Approving

Authorities to support their needs for making decisions.

Fundamental Computer Security Requirements

Any discussion of computer security necessarily starts from a statement of

requirements, i.e., what it really means to call a computer system "secure."

In general, secure systems will control, through use of specific security

features, access to information such that only properly authorized

individuals, or processes operating on their behalf, will have access to read,

write, create, or delete information. Six fundamental requirements are

derived from this basic statement of objective: four deal with what needs to

be provided to control access to information; and two deal with how one can

obtain credible assurances that this is accomplished in a trusted computer

system.

Policy

Requirement 1 - SECURITY POLICY - There must be an explicit and

well-defined security policy enforced by the system. Given identified subjects

and objects, there must be a set of rules that are used by the system to

determine whether a given subject can be permitted to gain access to a specific

object. Computer systems of interest must enforce a mandatory security policy

that can effectively implement access rules for handling sensitive (e.g.,

classified) information.[7] These rules include requirements such as: No

person lacking proper personnel security clearance shall obtain access to

classified

information. In addition, discretionary security controls are required to

ensure that only selected users or groups of users may obtain access to data

(e.g., based on a need-to-know).

Requirement 2 - MARKING - Access control labels must be associated

with objects. In order to control access to information stored in a computer,

according to the rules of a mandatory security policy, it must be possible to

mark every object with a label that reliably identifies the object's

sensitivity level (e.g., classification), and/or the modes of access accorded

those subjects who may potentially access the object.

Accountability

Requirement 3 - IDENTIFICATION - Individual subjects must be

identified. Each access to information must be mediated based on who is

accessing the information and what classes of information they are authorized

to deal with. This identification and authorization information must be

securely maintained by the computer system and be associated with every active

element that performs some security-relevant action in the system.

Requirement 4 - ACCOUNTABILITY - Audit information must be

selectively kept and protected so that actions affecting security can be traced

to the responsible party. A trusted system must be able to record the

occurrences of security-relevant events in an audit log. The capability to

select the audit events to be recorded is necessary to minimize the expense of

auditing and to allow efficient analysis. Audit data must be protected from

modification and unauthorized destruction to permit detection and

after-the-fact investigations of security violations.

Assurance

Requirement 5 - ASSURANCE - The computer system must contain

hardware/software mechanisms that can be independently evaluated to provide

sufficient assurance that the system enforces requirements 1 through 4 above.

In order to assure that the four requirements of Security Policy, Marking,

Identification, and Accountability are enforced by a computer system, there

must be some identified and unified collection of hardware and software

controls that perform those functions. These mechanisms are typically embedded

in the operating system and are designed to carry out the assigned tasks in a

secure manner. The basis for trusting such system mechanisms in their

operational setting must be clearly documented such that it is possible to

independently examine the evidence to evaluate their sufficiency.

Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that

enforce these basic requirements must be continuously protected against

tampering and/or unauthorized changes. No computer system can be considered

truly secure if the basic hardware and software mechanisms that enforce the

security policy are themselves subject to unauthorized modification or

subversion. The continuous protection requirement has direct implications

throughout the computer system's life-cycle.

These fundamental requirements form the basis for the individual evaluation

criteria applicable for each evaluation division and class. The interested

reader is referred to Section 5 of this document, "Control Objectives for

Trusted Computer Systems," for a more complete discussion and further

amplification of these fundamental requirements as they apply to

general-purpose information processing systems and to Section 7 for

amplification of the relationship between Policy and these requirements.

Structure of the Document

The remainder of this document is divided into two parts, four appendices, and

a glossary. Part I (Sections 1 through 4) presents the detailed criteria

derived from the fundamental requirements described above and relevant to the

rationale and policy excerpts contained in Part II.

Part II (Sections 5 through 10) provides a discussion of basic objectives,

rationale, and national policy behind the development of the criteria, and

guidelines for developers pertaining to: mandatory access control rules

implementation, the covert channel problem, and security testing. It is

divided into six sections. Section 5 discusses the use of control objectives

in general and presents the three basic control objectives of the criteria.

Section 6 provides the theoretical basis behind the criteria. Section 7 gives

excerpts from pertinent regulations, directives, OMB Circulars, and Executive

Orders which provide the basis for many trust requirements for processing

nationally sensitive and classified information with computer systems.

Section 8 provides guidance to system developers on expectations in dealing

with the covert channel problem. Section 9 provides guidelines dealing with

mandatory security. Section 10 provides guidelines for security testing.

There are four appendices, including a description of the Trusted Computer

System Commercial Products Evaluation Process (Appendix A), summaries of the

evaluation divisions (Appendix B) and classes (Appendix C), and finally a

directory of requirements ordered alphabetically. In addition, there is a

glossary.

Structure of the Criteria

The criteria are divided into four divisions: D, C, B, and A ordered in a

hierarchical manner with the highest division (A) being reserved for systems

providing the most comprehensive security. Each division represents a major

improvement in the overall confidence one can place in the system for the

protection of sensitive information. Within divisions C and B there are a

number of subdivisions known as classes. The classes are also ordered in a

hierarchical manner with systems representative of division C and lower

classes of division B being characterized by the set of computer security

mechanisms that they possess. Assurance of correct and complete design and

implementation for these systems is gained mostly through testing of the

security- relevant portions of the system. The security-relevant portions of

a system are referred to throughout this document as the Trusted Computing

Base (TCB). Systems representative of higher classes in division B and

division A derive their security attributes more from their design and

implementation structure. Increased assurance that the required features are

operative, correct, and tamperproof under all circumstances is gained through

progressively more rigorous analysis during the design process.

Within each class, four major sets of criteria are addressed. The first three

represent features necessary to satisfy the broad control objectives of

Security Policy, Accountability, and Assurance that are discussed in Part II,

Section 5. The fourth set, Documentation, describes the type of written

evidence in the form of user guides, manuals, and the test and design

documentation required for each class.

A reader using this publication for the first time may find it helpful to

first read Part II, before continuing on with Part I.

PART I: THE CRITERIA

Highlighting (UPPERCASE) is used in Part I to indicate criteria not contained

in a lower class or changes and additions to already defined criteria. Where

there is no highlighting, requirements have been carried over from lower

classes without addition or modification.

1.0 DIVISION D: MINIMAL PROTECTION

This division contains only one class. It is reserved for those systems that

have been evaluated but that fail to meet the requirements for a higher

evaluation class.

2.0 DIVISION C: DISCRETIONARY PROTECTION

Classes in this division provide for discretionary (need-to-know) protection

and, through the inclusion of audit capabilities, for accountability of

subjects and the actions they initiate.

2.1 CLASS (C1): DISCRETIONARY SECURITY PROTECTION

The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies

the discretionary security requirements by providing separation of users and

data. It incorporates some form of credible controls capable of enforcing

access limitations on an individual basis, i.e., ostensibly suitable for

allowing users to be able to protect project or private information and to

keep other users from accidentally reading or destroying their data. The

class (C1) environment is expected to be one of cooperating users processing

data at the same level(s) of sensitivity. The following are minimal

requirements for systems assigned a class (C1) rating:

2.1.1 Security Policy

2.1.1.1 Discretionary Access Control

The TCB shall define and control access between named users and

named objects (e.g., files and programs) in the ADP system. The

enforcement mechanism (e.g., self/group/public controls, access

control lists) shall allow users to specify and control sharing

of those objects by named individuals or defined groups or both.

2.1.2 Accountability

2.1.2.1 Identification and Authentication

The TCB shall require users to identify themselves to it before

beginning to perform any other actions that the TCB is expected

to mediate. Furthermore, the TCB shall use a protected

mechanism (e.g., passwords) to authenticate the user's identity.

The TCB shall protect authentication data so that it cannot be

accessed by any unauthorized user.

2.1.3 Assurance

2.1.3.1 Operational Assurance

2.1.3.1.1 System Architecture

The TCB shall maintain a domain for its own execution

protects it from external interference or tampering

(e.g., by modification of its code or data strucutres).

Resources controlled by the TCB may be a defined subset

of the subjects and objects in the ADP system.

2.1.3.1.2 System Integrity

Hardware and/or software features shall be provided that

can be used to periodically validate the correct operation

of the on-site hardware and firmware elements of the TCB.

2.1.3.2 Life-Cycle Assurance

2.1.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested

and found to work as claimed in the system documentation.

Testing shall be done to assure that there are no obvious

ways for an unauthorized user to bypass or otherwise

defeat the security protection mechanisms of the TCB.

(See the Security Testing Guidelines.)

2.1.4 Documentation

2.1.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation

shall describe the protection mechanisms provided by the TCB,

guidelines on their use, and how they interact with one another.

2.1.4.2 Trusted Facility Manual

A manual addressed to the ADP System Administrator shall

present cautions about functions and privileges that should be

controlled when running a secure facility.

2.1.4.3 Test Documentation

The system developer shall provide to the evaluators a document

that describes the test plan, test procedures that show how the

the security mechanisms were tested, and results of the

security mechanisms' functional testing.

2.1.4.4 Design Documentation

Documentation shall be available that provides a description of

the manufacturer's philosophy of protection and an explanation

of how this philosophy is translated into the TCB. If the TCB

is composed of distinct modules, the interfaces between these

modules shall be described.

2.2 CLASS (C2): CONTROLLED ACCESS PROTECTION

Systems in this class enforce a more finely grained discretionary access

control than (C1) systems, making users individually accountable for their

actions through login procedures, auditing of security-relevant events, and

resource isolation. The following are minimal requirements for systems

assigned a class (C2) rating:

2.2.1 Security Policy

2.2.1.1 Discretionary Access Control

The TCB shall define and control access between named users and

named objects (e.g., files and programs) in the ADP system. The

enforcement mechanism (e.g., self/group/public controls, access

control lists) shall allow users to specify and control sharing

of those objects by named individuals, or defined groups of

individuals, or by both, and shall provide controls to limit

propagation of access rights. The discretionary access control

mechanism shall, either by explicit user action or by default,

provide that objects are protected from unauthorized access.

These access controls shall be capable of including or excluding

access to the granularity of a single user. Access permission

to an object by users not already possessing access permission

shall only be assigned by authorized users.

2.2.1.2 Object Reuse

All authorizations to the information contained within a

storage object shall be revoked prior to initial assignment,

allocation or reallocation to a subject from the TCB's pool

of unused storage objects. No information, including encrypted

representations of information, produced by a prior subject's

actions is to be available to any subject that obtains access

to an object that has been released back to the system.

2.2.2 Accountability

2.2.2.1 Identification and Authentication

The TCB shall require users to identify themselves to it before

beginning to perform any other actions that the TCB is expected

to mediate. Furthermore, the TCB shall use a protected

mechanism (e.g., passwords) to authenticate the user's identity.

The TCB shall protect authentication data so that it cannot be

accessed by any unauthorized user. The TCB shall be able to

enforce individual accountability by providing the capability to

uniquely identify each individual ADP system user. The TCB

shall also provide the capability of associating this identity

with all auditable actions taken by that individual.

2.2.2.2 Audit

The TCB shall be able to create, maintain, and protect from

modification or unauthorized access or destruction an audit

trail of accesses to the objects it protects. The audit data

shall be protected by the TCB so that read access to it is

limited to those who are authorized for audit data. The TCB

shall be able to record the following types of events: use of

identification and authentication mechanisms, introduction or

objects into a user's address space (e.g., file open, program

initiation), deletion of objects, and actions taken by

computer operators and system administrators and/or system

security officers, and other security relevant events. For

each recorded event, the audit record shall identify: date and

time of the event, user, type of event, and success or failure

of the event. For identification/authentication events the

origin of request (e.g., terminal ID) shall be included in the

audit record. For events that introduce an object into a user's

address space and for object deletion events the audit record

shall include the name of the object. The ADP system

administrator shall be able to selectively audit the actions of

any one or more users based on individual identity.

2.2.3 Assurance

2.2.3.1 Operational Assurance

2.2.3.1.1 System Architecture

The TCB shall maintain a domain for its own execution

that protects it from external interference or tampering

(e.g., by modification of its code or data structures).

Resources controlled by the TCB may be a defined subset

of the subjects and objects in the ADP system. The TCB

shall isolate the resources to be protected so that they

are subject to the access control and auditing

requirements.

2.2.3.1.2 System Integrity

Hardware and/or software features shall be provided that

can be used to periodically validate the correct operation

of the on-site hardware and firmware elements of the TCB.

2.2.3.2 Life-Cycle Assurance

2.2.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested

and found to work as claimed in the system documentation.

Testing shall be done to assure that there are no obvious

ways for an unauthorized user to bypass or otherwise

defeat the security protection mechanisms of the TCB.

Testing shall also include a search for obvious flaws that

would allow violation of resource isolation, or that would

permit unauthorized access to the audit or authentication

data. (See the Security Testing guidelines.)

2.2.4 Documentation

2.2.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation

shall describe the protection mechanisms provided by the TCB,

guidelines on their use, and how they interact with one another.

2.2.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall

present cautions about functions and privileges that should be

controlled when running a secure facility. The procedures for

examining and maintaining the audit files as well as the

detailed audit record structure for each type of audit event

shall be given.

2.2.4.3 Test Documentation

The system developer shall provide to the evaluators a document

that describes the test plan, test procedures that show how the

security mechanisms were tested, and results of the security

mechanisms' functional testing.

2.2.4.4 Design Documentation

Documentation shall be available that provides a description of

the manufacturer's philosophy of protection and an explanation

of how this philosophy is translated into the TCB. If the TCB

is composed of distinct modules, the interfaces between these

modules shall be described.

3.0 DIVISION B: MANDATORY PROTECTION

The notion of a TCB that preserves the integrity of sensitivity labels and

uses them to enforce a set of mandatory access control rules is a major

requirement in this division. Systems in this division must carry the

sensitivity labels with major data structures in the system. The system

developer also provides the security policy model on which the TCB is based

and furnishes a specification of the TCB. Evidence must be provided to

demonstrate that the reference monitor concept has been implemented.

3.1 CLASS (B1): LABELED SECURITY PROTECTION

Class (B1) systems require all the features required for class (C2). In

addition, an informal statement of the security policy model, data labeling,

and mandatory access control over named subjects and objects must be present.

The capability must exist for accurately labeling exported information. Any

flaws identified by testing must be removed. The following are minimal

requirements for systems assigned a class (B1) rating:

3.1.1 Security Policy

3.1.1.1 Discretionary Access Control

The TCB shall define and control access between named users and

named objects (e.g., files and programs) in the ADP system.

The enforcement mechanism (e.g., self/group/public controls,

access control lists) shall allow users to specify and control

sharing of those objects by named individuals, or defined groups

of individuals, or by both, and shall provide controls to limit

propagation of access rights. The discretionary access control

mechanism shall, either by explicit user action or by default,

provide that objects are protected from unauthorized access.

These access controls shall be capable of including or excluding

access to the granularity of a single user. Access permission

to an object by users not already possessing access permission

shall only be assigned by authorized users.

3.1.1.2 Object Reuse

All authorizations to the information contained within a

storage object shall be revoked prior to initial assignment,

allocation or reallocation to a subject from the TCB's pool

of unused storage objects. No information, including encrypted

representations of information, produced by a prior subject's

actions is to be available to any subject that obtains access

to an object that has been released back to the system.

3.1.1.3 Labels

Sensitivity labels associated with each subject and storage

object under its control (e.g., process, file, segment, device)

shall be maintained by the TCB. These labels shall be used as

the basis for mandatory access control decisions. In order to

import non-labeled data, the TCB shall request and receive from

an authorized user the security level of the data, and all such

actions shall be auditable by the TCB.

3.1.1.3.1 Label Integrity

Sensitivity labels shall accurately represent security

levels of the specific subjects or objects with which they

are associated. When exported by the TCB, sensitivity

labels shall accurately and unambiguously represent the

internal labels and shall be associated with the

information being exported.

3.1.1.3.2 Exportation of Labeled Information

The TCB shall designate each communication channel and

I/O device as either single-level or miltilevel. Any

change in this designation shall be done manually and

shall be auditable by the TCB. The TCB shall maintain

and be able to audit any change in the security level

or levels associated with a communication channel or

I/O device.

3.1.1.3.2.1 Exportation to Multilevel Devices

When the TCB exports an object to a multilevel I/O

device, the sensitivity label associated with that

object shall also be exported and shall reside on

the same physical medium as the exported

information and shall be in the same form

(i.e., machine-readable or human-readable form).

When the TCB exports or imports an object over a

multilevel communication channel, the protocol

used on that channel shall provide for the

unambiguous pairing between the sensitivity labels

and the associated information that is sent or

received.

3.1.1.3.2.2 Exportation to Single-Level Devices

Single-level I/O devices and single-level

communication channels are not required to

maintain the sensitivity labels of the information

they process. However, the TCB shall include a

mechanism by which the TCb and an authorized user

reliably communicate to designate the single

security level of information imported or exported

via single-level communication channels or I/O

devices.

3.1.1.3.2.3 Labeling Human-Readable Output

The ADP system administrator shall be able to

specify the printable label names associated with

exported sensitivity labels. The TCB shall mark

the beginning and end of all human-readable, paged,

hardcopy output (e.g., line printer output) with

human-readable sensitivity labels that properly*

represent the sensitivity of the output. The TCB

shall, be default, mark the top and bottom of each

page of human-readable, paged, hardcopy output

(e.g., line printer output) with human-readable

sensitivity labels that properly* represent the

overall sensitivity of the output or that properly*

represent the sensitivity of the information on the

page. The TCB shall, by default and in an

appropriate manner, mark other forms of human-

readable output (e.g., maps, graphics) with human-

readable sensitivity labels that properly*

represent the sensitivity of the touput. Any

override of these marking defaults shall be

auditable by the TCB.

3.1.1.4 Mandatory Access Control

The TCB shall enforce a mandatory access control policy over

all subjects and storage objects under its control (e.g.,

processes, files, segments, devices). These subjects and

objects shall be assigned sensitivity labels that are a

combination of hierarchical classification levels and

non-hierarchical categories, and the labels shall be used as

the basis for mandatory access control decisions. The TCB

shall be able to support two or more such security levels.

(See the Mandatory Access Control Guidelines.) The following

requirements shall hold for all accesses between subjects and

objects controlled by the TCB: a subject can read an object

only if the hierarchical classification in the subject's

security level is greater than or equal to the hierarchical

classification in the object's security level and the non-

hierarchical categories in the subject's security level include

all the non-hierarchical categories in the object's security

level. A subject can write an object only if the hierarchical

classification in the subject's security level is less than or

equal to the hierarchical classification in the object's

security level and all the non-hierarchical categories in the

subject's security level are included in the non-hierarchical

categories in the object's security level. Identification

and authentication data shall be used by the TCB to authenti-

cate the user's identity and to ensure that the security level

and authorization of subjects external to the TCB that may be

created to act on behalf of the individual user are dominated

by the clearance and authorization of that user.

3.1.2 Accountability

3.1.2.1 Identification and Authentication

The TCB shall require users to identify themselves to it before

beginning to perform any other actions that the TCB is expected

to mediate. Furthermore, the TCB shall maintain authentication

data that includes information for verifying the identity of

individual users (e.g., passwords) as well as information for

determining the clearance and authorizations or individual

_____________________________

* The hierarchical classification component in human-readable sensitivity

labels shall be equal to the greatest hierarchical classification or any of the

information in the output that the labels refer to; the non-hierarchical

category component shall include all of the non-hierarchical categories of the

information in the output the labels refer to, but no other non-hierarchical

categories.

users. This data shall be used by the TCB to authenticate the

user's identity and to ensure that the security level and

authorizations of subjects external to the TCB that may be

created to act on behalf of the individual user are dominated

by the clearance and authorization of that user. The TCB shall

protect authentication data so that it cannot be accessed by any

unauthorized user. The TCB shall be able to enforce individual

accountability by providing the capability to uniquely identify

each individual ADP system user. The TCB shall also provide the

capability of associating this identity with all auditable

actions taken by that individual.

3.1.2.2 Audit

The TCB shall be able to create, maintain, and protect from

modification or unauthorized access or destruction an audit

trail of accesses to the objects it protects. The audit data

shall be protected by the TCB so that read access to it is

limited to those who are authorized for audit data. The TCB

shall be able to record the following types of events: use of

identification and authentication mechanisms, introduction of

objects into a user's address space (e.g., file open, program

initiation), deletion of objects, and actions taken by computer

operators and system administrators and/or system security

officers and other security relevant events. The TCB shall also

be able to audit any override of human-readable output markings.

For each recorded event, the audit record shall identify: date

and time of the event, user, type of event, and success or

failure of the event. For identification/authentication events

the origin of request (e.g., terminal ID) shall be included in

the audit record. For events that introduce an object into a

user's address space and for object deletion events the audit

record shall include the name of the object and the object's

security level. The ADP system administrator shall be able to

selectively audit the actions of any one or more users based on

individual identity and/or object security level.

3.1.3 Assurance

3.1.3.1 Operational Assurance

3.1.3.1.1 System Architecture

The TCB shall maintain a domain for its own execution

that protects it from external interference or tampering

(e.g., by modification of its code or data structures).

Resources controlled by the TCB may be a defined subset

of the subjects and objects in the ADP system. The TCB

shall maintain process isolation through the provision of

distinct address spaces under its control. The TCB shall

isolate the resources to be protected so that they are

subject to the access control and auditing requirements.

3.1.3.1.2 System Integrity

Hardware and/or software features shall be provided that

can be used to periodically validate the correct operation

of the on-site hardware and firmware elements of the TCB.

3.1.3.2 Life-Cycle Assurance

3.1.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested

and found to work as claimed in the system documentation.

A team of individuals who thoroughly understand the

specific implementation of the TCB shall subject its

design documentation, source code, and object code to

thorough analysis and testing. Their objectives shall be:

to uncover all design and implementation flaws that would

permit a subject external to the TCB to read, change, or

delete data normally denied under the mandatory or

discretionary security policy enforced by the TCB; as well

as to assure that no subject (without authorization to do

so) is able to cause the TCB to enter a state such that

it is unable to respond to communications initiated by

other users. All discovered flaws shall be removed or

neutralized and the TCB retested to demonstrate that they

have been eliminated and that new flaws have not been

introduced. (See the Security Testing Guidelines.)

3.1.3.2.2 Design Specification and Verification

An informal or formal model of the security policy

supported by the TCB shall be maintained over the life

cycle of the ADP system and demonstrated to be consistent

with its axioms.

3.1.4 Documentation

3.1.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation

shall describe the protection mechanisms provided by the TCB,

guidelines on their use, and how they interact with one another.

3.1.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall

present cautions about functions and privileges that should be

controlled when running a secure facility. The procedures for

examining and maintaining the audit files as well as the

detailed audit record structure for each type of audit event

shall be given. The manual shall describe the operator and

administrator functions related to security, to include changing

the security characteristics of a user. It shall provide

guidelines on the consistent and effective use of the protection

features of the system, how they interact, how to securely

generate a new TCB, and facility procedures, warnings, and

privileges that need to be controlled in order to operate the

facility in a secure manner.

3.1.4.3 Test Documentation

The system developer shall provide to the evaluators a document

that describes the test plan, test procedures that show how the

security mechanisms were tested, and results of the security

mechanisms' functional testing.

3.1.4.4 Design Documentation

Documentation shall be available that provides a description of

the manufacturer's philosophy of protection and an explanation

of how this philosophy is translated into the TCB. If the TCB

is composed of distinct modules, the interfaces between these

modules shall be described. An informal or formal description

of the security policy model enforced by the TCB shall be

available and an explanation provided to show that it is

sufficient to enforce the security policy. The specific TCB

protection mechanisms shall be identified and an explanation

given to show that they satisfy the model.

3.2 CLASS (B2): STRUCTURED PROTECTION

In class (B2) systems, the TCB is based on a clearly defined and documented

formal security policy model that requires the discretionary and mandatory

access control enforcement found in class (B1) systems be extended to all

subjects and objects in the ADP system. In addition, covert channels are

addressed. The TCB must be carefully structured into protection-critical and

non- protection-critical elements. The TCB interface is well-defined and the

TCB design and implementation enable it to be subjected to more thorough

testing and more complete review. Authentication mechanisms are strengthened,

trusted facility management is provided in the form of support for system

administrator and operator functions, and stringent configuration management

controls are imposed. The system is relatively resistant to penetration. The

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

3.2.1 Security Policy

3.2.1.1 Discretionary Access Control

The TCB shall define and control access between named users and

named objects (e.g., files and programs) in the ADP system.

The enforcement mechanism (e.g., self/group/public controls,

access control lists) shall allow users to specify and control

sharing of those objects by named individuals, or defined

groups of individuals, or by both, and shall provide controls

to limit propagation of access rights. The discretionary access

control mechanism shall, either by explicit user action or by

default, provide that objects are protected from unauthorized

access. These access controls shall be capable of including

or excluding access to the granularity of a single user.

Access permission to an object by users not already possessing

access permission shall only be assigned by authorized users.

3.2.1.2 Object Reuse

All authorizations to the information contained within a

storage object shall be revoked prior to initial assignment,

allocation or reallocation to a subject from the TCB's pool of

unused storage objects. No information, including encrypted

representations of information, produced by a prior subject's

actions is to be available to any subject that obtains access

to an object that has been released back to the system.

3.2.1.3 Labels

Sensitivity labels associated with each ADP system resource

(e.g., subject, storage object, ROM) that is directly or

indirectly accessible by subjects external to the TCB shall be

maintained by the TCB. These labels shall be used as the basis

for mandatory access control decisions. In order to import

non-labeled data, the TCB shall request and receive from an

authorized user the security level of the data, and all such

actions shall be auditable by the TCB.

3.2.1.3.1 Label Integrity

Sensitivity labels shall accurately represent security

levels of the specific subjects or objects with which

they are associated. When exported by the TCB,

sensitivity labels shall accurately and unambiguously

represent the internal labels and shall be associated

with the information being exported.

3.2.1.3.2 Exportation of Labeled Information

The TCB shall designate each communication channel and

I/O device as either single-level or multilevel. Any

change in this designation shall be done manually and

shall be auditable by the TCB. The TCB shall maintain

and be able to audit any change in the security level

or levels associated with a communication channel or

I/O device.

3.2.1.3.2.1 Exportation to Multilevel Devices

When the TCB exports an object to a multilevel I/O

device, the sensitivity label associated with that

object shall also be exported and shall reside on

the same physical medium as the exported

information and shall be in the same form (i.e.,

machine-readable or human-readable form). When

the TCB exports or imports an object over a

multilevel communication channel, the protocol

used on that channel shall provide for the

unambiguous pairing between the sensitivity labels

and the associated information that is sent or

received.

3.2.1.3.2.2 Exportation to Single-Level Devices

Single-level I/O devices and single-level

communication channels are not required to

maintain the sensitivity labels of the

information they process. However, the TCB shall

include a mechanism by which the TCB and an

authorized user reliably communicate to designate

the single security level of information imported

or exported via single-level communication

channels or I/O devices.

3.2.1.3.2.3 Labeling Human-Readable Output

The ADP system administrator shall be able to

specify the printable label names associated with

exported sensitivity labels. The TCB shall mark

the beginning and end of all human-readable, paged,

hardcopy output (e.g., line printer output) with

human-readable sensitivity labels that properly*

represent the sensitivity of the output. The TCB

shall, by default, mark the top and bottom of each

page of human-readable, paged, hardcopy output

(e.g., line printer output) with human-readable

sensitivity labels that properly* represent the

overall sensitivity of the output or that

properly* represent the sensitivity of the

information on the page. The TCB shall, by

default and in an appropriate manner, mark other

forms of human-readable output (e.g., maps,

graphics) with human-readable sensitivity labels

that properly* represent the sensitivity of the

output. Any override of these marking defaults

shall be auditable by the TCB.

3.2.1.3.3 Subject Sensitivity Labels

The TCB shall immediately notify a terminal user of each

change in the security level associated with that user

during an interactive session. A terminal user shall be

able to query the TCB as desired for a display of the

subject's complete sensitivity label.

3.2.1.3.4 Device Labels

The TCB shall support the assignment of minimum and

maximum security levels to all attached physical devices.

These security levels shall be used by the TCB to enforce

constraints imposed by the physical environments in which

the devices are located.

3.2.1.4 Mandatory Access Control

The TCB shall enforce a mandatory access control policy over

all resources (i.e., subjects, storage objects, and I/O devices

that are directly or indirectly accessible by subjects external

to the TCB. These subjects and objects shall be assigned

sensitivity labels that are a combination of hierarchical

classification levels and non-hierarchical categories, and the

labels shall be used as the basis for mandatory access control

decisions. The TCB shall be able to support two or more such

security levels. (See the Mandatory Access Control guidelines.)

The following requirements shall hold for all accesses between

All subjects external to the TCB and all objects directly or

indirectly accessible by these subjects: A subject can read an

object only if the hierarchical classification in the subject's

security level is greater than or equal to the hierarchical

classification in the object's security level and the non-

hierarchical categories in the subject's security level include

all the non-hierarchical categories in the object's security

level. A subject can write an object only if the hierarchical

classification in the subject's security level is less than or

equal to the hierarchical classification in the object's

security level and all the non-hierarchical categories in the

subject's security level are included in the non-hierarchical

categories in the object's security level. Identification and

authentication data shall be used by the TCB to authenticate

the user's identity and to ensure that the security level and

authorization of subjects external to the TCB that may be

created to act on behalf of the individual user are dominated

by the clearance and authorization of that user.

3.2.2 Accountability

3.2.2.1 Identification and Authentication

The TCB shall require users to identify themselves to it before

beginning to perform any other actions that the TCB is expected

to mediate. Furthermore, the TCB shall maintain authentication

data that includes information for verifying the identity of

individual users (e.g., passwords) as well as information for

determining the clearance and authorizations of individual

users. This data shall be used by the TCB to authenticate the

user's identity and to ensure that the security level and

authorizations of subjects external to the TCB that may be

created to act on behalf of the individual user are dominated by

the clearance and authorization of that user. The TCB shall

protect authentication data so that it cannot be accessed by any

unauthorized user. The TCB shall be able to enforce individual

accountability by providing the capability to uniquely identify

each individual ADP system user. The TCB shall also provide the

capability of associating this identity with all auditable

actions taken by that individual.

3.2.2.1.1 Trusted Path

The TCB shall support a trusted communication path

between itself and user for initial login and

authentication. Communications via this path shall be

initiated exclusively by a user.

3.2.2.2 Audit

The TCB shall be able to create, maintain, and protect from

modification or unauthorized access or destruction an audit

trail of accesses to the objects it protects. The audit data

shall be protected by the TCB so that read access to it is

limited to those who are authorized for audit data. The TCB

shall be able to record the following types of events: use of

identification and authentication mechanisms, introduction of

objects into a user's address space (e.g., file open, program

initiation), deletion of objects, and actions taken by computer

operators and system administrators and/or system security

officers, and other security relevant events. The TCB shall

also be able to audit any override of human-readable output

markings. For each recorded event, the audit record shall

identify: date and time of the event, user, type of event, and

success or failure of the event. For identification/

authentication events the origin of request (e.g., terminal ID)

shall be included in the audit record. For events that

introduce an object into a user's address space and for object

deletion events the audit record shall include the name of the

object and the object's security level. The ADP system

administrator shall be able to selectively audit the actions of

any one or more users based on individual identity and/or object

security level. The TCB shall be able to audit the identified

events that may be used in the exploitation of covert storage

channels.

3.2.3 Assurance

3.2.3.1 Operational Assurance

3.2.3.1.1 System Architecture

The TCB shall maintain a domain for its own execution

that protects it from external interference or tampering

(e.g., by modification of its code or data structures).

The TCB shall maintain process isolation through the

provision of distinct address spaces under its control.

The TCB shall be internally structured into well-defined

largely independent modules. It shall make effective use

of available hardware to separate those elements that are

protection-critical from those that are not. The TCB

modules shall be designed such that the principle of least

privilege is enforced. Features in hardware, such as

segmentation, shall be used to support logically distinct

storage objects with separate attributes (namely:

readable, writeable). The user interface to the TCB

shall be completely defined and all elements of the TCB

identified.

3.2.3.1.2 System Integrity

Hardware and/or software features shall be provided that

can be used to periodically validate the correct

operation of the on-site hardware and firmware elements

of the TCB.

3.2.3.1.3 Covert Channel Analysis

The system developer shall conduct a thorough search for

covert storage channels and make a determination (either

by actual measurement or by engineering estimation) of

the maximum bandwidth of each identified channel. (See

the covert channels guideline section.)

3.2.3.1.4 Trusted Facility Management

The TCB shall support separate operator and administrator

functions.

3.2.3.2 Life-Cycle Assurance

3.2.3.2.1 Security Testing

The security mechanisms of the ADP system shall be tested

and found to work as claimed in the system documentation.

A team of individuals who thoroughly understand the

specific implementation of the TCB shall subject its

design documentation, source code, and object code to

thorough analysis and testing. Their objectives shall be:

to uncover all design and implementation flaws that would

permit a subject external to the TCB to read, change, or

delete data normally denied under the mandatory or

discretionary security policy enforced by the TCB; as well

as to assure that no subject (without authorization to do

so) is able to cause the TCB to enter a state such that it

is unable to respond to communications initiated by other

users. The TCB shall be found relatively resistant to

penetration. All discovered flaws shall be corrected and

the TCB retested to demonstrate that they have been

eliminated and that new flaws have not been introduced.

Testing shall demonstrate that the TCB implementation is

consistent with the descriptive top-level specification.

(See the Security Testing Guidelines.)

3.2.3.2.2 Design Specification and Verification

A formal model of the security policy supported by the

TCB shall be maintained over the life cycle of the ADP

system that is proven consistent with its axioms. A

descriptive top-level specification (DTLS) of the TCB

shall be maintained that completely and accurately

describes the TCB in terms of exceptions, error messages,

and effects. It shall be shown to be an accurate

description of the TCB interface.

3.2.3.2.3 Configuration Management

During development and maintenance of the TCB, a

configuration management system shall be in place that

maintains control of changes to the descriptive top-level

specification, other design data, implementation

documentation, source code, the running versionof the

object code, and test fixtures and documentation. The

configuration management system shall assure a consistent

mapping among all documentation and code associated with

the current version of the TCB. Tools shall be provided

for generation of a new version of the TCB from source

code. Also available shall be tools for comparing a

newly generated version with the previous TCB version in

order to ascertain that only the intended changes have

been made in the code that will actually be used as the

new version of the TCB.

3.2.4 Documentation

3.2.4.1 Security Features User's Guide

A single summary, chapter, or manual in user documentation

shall describe the protection mechanisms provided by the TCB,

guidelines on their use, and how they interact with one another.

3.2.4.2 Trusted Facility Manual

A manual addressed to the ADP system administrator shall

present cautions about functions and privileges that should be

controlled when running a secure facility. The procedures for

examining and maintaining the audit files as well as the

detailed audit record structure for each type of audit event

shall be given. The manual shall describe the operator and

administrator functions related to security, to include

changing the security characteristics of a user. It shall

provide guidelines on the consistent and effective use of the

protection features of the system, how they interact, how to

securely generate a new TCB, and facility procedures, warnings,

and privileges that need to be controlled in order to operate

the facility in a secure manner. The TCB modules that contain

the reference validation mechanism shall be identified. The

procedures for secure generation of a new TCB from source after

modification of any modules in the TCB shall be described.

3.2.4.3 Test Documentation

The system developer shall provide to the evaluators a document

that describes the test plan, test procedures that show how the

security mechanisms were tested, and results of the security

mechanisms' functional testing. It shall include results of

testi