|
Source http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
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 1985
ASSISTANT SECURITY OF DEFENSE
COMMAND, CONTROL, COMMUNICATIONS AND INTELLIGENCE
DoD 5200.28-STD
December 26, 1985
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)
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
ACKNOWLEDGEMENTS
PREFACE
INTRODUCTION
PART I: CRITERIA
1.0 DIVISION D: MINIMAL PROTECTION
2.0 DIVISION C: DISCRETIONARY PROTECTION
- 2.1 CLASS (C1): DISCRETIONARY SECURITY PROTECTION
- 2.2 CLASS (C2): CONTROLLED ACCESS PROTECTION
3.0 DIVISION B: MANDATORY PROTECTION
- 3.1 CLASS (B1): LABELED SECURITY PROTECTION
- 3.2 CLASS (B2): STRUCTURED PROTECTION
- 3.3 CLASS (B3): SECURITY DOMAINS
4.0 DIVISION A: VERIFIED PROTECTION
- 4.1 CLASS (A1): VERIFIED DESIGN
- 4.2 BEYOND CLASS (A1)
PART II: RATIONAL AND GUIDELINES
5.0 CONTROL OBJECTIVES FOR TRUSTED COMPUTER
SYSTEMS
- 5.1 A NEED FOR CONSENSUS
- 5.2 DEFINITION AND USEFULNESS
- 5.3 CRITERIA CONTROL OBJECTIVES
6.0 RATIONALE BEHIND THE EVALUATION CLASSES
- 6.1 THE REFERENCE MONITOR CONCEPT
- 6.2 A FORMAL SECURITY POLICY MODEL
- 6.3 THE TRUSTED COMPUTING BASE
- 6.4 ASSURANCE
- 6.5 THE CLASSES
7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA
- 7.1 ESTABLISHED FEDERAL POLICIES
- 7.2 DOD POLICIES
- 7.3 CRITERIA CONTROL OBJECTIVE FOR SECURITY
POLICY
- 7.4 CRITERIA CONTROL OBJECTIVE FOR ACCOUNTABILITY
- 7.5 CRITERIA CONTROL OBJECTIVE FOR ASSURANCE
8.0 A GUIDELINE ON COVERT CHANNELS
9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS
CONTROL FEATURES
10.0 A GUIDELINE ON SECURITY TESTING
- 10.1 TESTING FOR DIVISION C
- 10.2 TESTING FOR DIVISION B
- 10.3 TESTING FOR DIVISION A
APPENDIX A: Commercial Product Evaluation
Process
APPENDIX B: Summary of Evaluation Criteria
Divisions
APPENDIX C: Summary of Evaluation Criteria
Classes
APPENDIX D: Requirement Directory
GLOSSARY
REFERENCES
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.
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 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.
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.
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.
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
- 2.1.2 Accountability
- 2.1.2.1 Identification and Authentication
- 2.1.3 Assurance
- 2.1.3.1 Operational Assurance
- 2.1.3.1.1 System Architecture
- 2.1.3.1.2 System Integrity
- 2.1.3.2 Life-Cycle Assurance
- 2.1.3.2.1 Security Testing
- 2.1.4 Documentation
- 2.1.4.1 Security Features User's
Guide
- 2.1.4.2 Trusted Facility Manual
- 2.1.4.3 Test Documentation
- 2.1.4.4 Design Documentation
- 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.
- 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 maintain a domain for its own execution that
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.
- 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.
- 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.)
- 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.
- 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 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.
- 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.
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
- 2.2.1.2 Object Reuse
- 2.2.2 Accountability
- 2.2.2.1 Identification and Authentication
- 2.2.2.2 Audit
- 2.2.3 Assurance
- 2.2.3.1 Operational Assurance
- 2.2.3.1.1 System Architecture
- 2.2.3.1.2 System Integrity
- 2.2.3.2 Life-Cycle Assurance
- 2.2.3.2.1 Security Testing
2.2.4 Documentation
2.2.4.1 Security Features User's Guide
2.2.4.2 Trusted Facility Manual
2.2.4.3 Test Documentation
2.2.4.4 Design Documentation
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.)
- 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.
- 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 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.
- 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.
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.
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
- 3.1.1.2 Object Reuse
- 3.1.1.3 Labels
- 3.1.1.3.1 Label Integrity
- 3.1.1.3.2 Exportation of
Labeled Information
- 3.1.1.3.2.1 Exportation
to Multilevel Devices
- 3.1.1.3.2.2 Exportation
to Single-Level Devices
- 3.1.1.3.2.3 Labeling
Human-Readable Output
- 3.1.1.4 Mandatory Access Control
- 3.1.2 Accountability
- 3.1.2.1 Identification and Authentication
- 3.1.2.2 Audit
- 3.1.3 Assurance
- 3.1.3.1 Operational Assurance
- 3.1.3.1.1 System Architecture
- 3.1.3.1.2 System Integrity
- 3.1.3.2 Life-Cycle Assurance
- 3.1.3.2.1 Security Testing
- 3.1.3.2.2 Design Specification
and Verification
3.1.4 Documentation
3.1.4.1 Security Features User's Guide
3.1.4.2 Trusted Facility Manual
3.1.4.3 Test Documentation
3.1.4.4 Design Documentation
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- The TCB shall enforce a mandatory access control policy over
all subjects and storage objects under its control (e.g., processes,
files, segments, devices). These subjects and objects shall be
assigned sensitivity labels that are a combination of hierarchical
classification levels and non-hierarchical categories, and the
labels shall be used as the basis for mandatory access control
decisions. The TCB shall be able to support two or more such
security levels. (See the Mandatory Access Control Guidelines.)
The following requirements shall hold for all accesses between
subjects and objects controlled by the TCB: a subject can read
an object only if the hierarchical classification in the subject's
security level is greater than or equal to the hierarchical classification
in the object's security level and the non-hierarchical categories
in the subject's security level include all the non-hierarchical
categories in the object's security level. A subject can write
an object only if the hierarchical classification in the subject's
security level is less than or equal to the hierarchical classification
in the object's security level and all the non-hierarchical categories
in the subject's security level are included in the non-hierarchical
categories in the object's security level. Identification and
authentication data shall be used by the TCB to authenticate
the user's identity and to ensure that the security level and
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.
- The TCB shall require users to identify themselves to it before
beginning to perform any other actions that the TCB 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 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.
- 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 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.
- 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.
- 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.)
- 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.
- 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.
- 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 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.
- 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.
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
- 3.2.1.2 Object Reuse
- 3.2.1.3 Labels
- 3.2.1.3.1 Label Integrity
- 3.2.1.3.2 Exportation of
Labeled Information
- 3.2.1.3.2.1 Exportation
to Multilevel Devices
- 3.2.1.3.2.2 Exportation
to Single-Level Devices
- 3.2.1.3.2.3 Labeling
Human-Readable Output
- 3.2.1.3.3 Subject Sensitivity
Labels
- 3.2.1.3.4 Device Labels
- 3.2.1.4 Mandatory Access Control
- 3.2.2 Accountability
- 3.2.2.1 Identification and Authentication
- 3.2.2.1.1 Trusted Path
- 3.2.2.2 Audit
- 3.2.3 Assurance
- 3.2.3.1 Operational Assurance
- 3.2.3.1.1 System Architecture
- 3.2.3.1.2 System Integrity
- 3.2.3.1.3 Covert Channel
Analysis
- 3.2.3.1.4 Trusted Facility
Management
- 3.2.3.2 Life-Cycle Assurance
- 3.2.3.2.1 Security Testing
- 3.2.3.2.2 Design Specification
and Verification
- 3.2.3.2.3 Configuration
Management
- 3.2.4 Documentation
- 3.2.4.1 Security Features User's
Guide
- 3.2.4.2 Trusted Facility Manual
- 3.2.4.3 Test Documentation
- 3.2.4.4 Design Documentation
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 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.
- 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.
- 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.
- 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.
- 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.
- The TCB shall be able to create, maintain, and protect from
modification or unauthorized access or destruction an audit trail
of accesses to the objects it protects. The audit data shall
be protected by the TCB so that read access to it is limited
to those who are authorized for audit data. The TCB shall be
able to record the following types of events: use of identification
and authentication mechanisms, introduction of objects into a
user's address space (e.g., file open, program initiation), deletion
of objects, and actions taken by computer operators and system
administrators and/or system security officers, and other security
relevant events. The TCB shall also be able to audit any override
of human-readable output markings. For each recorded event, the
audit record shall identify: date and time of the event, user,
type of event, and success or failure of the event. For identification/authentication
events the origin of request (e.g., terminal ID) shall be included
in the audit record. For events that introduce an object into
a user's address space and for object deletion events the audit
record shall include the name of the object and the object's
security level. The ADP system administrator shall be able to
selectively audit the actions of any one or more users based
on individual identity and/or object security level. The TCB
shall be able to audit the identified events that may be used
in the exploitation of covert storage channels.
- The TCB shall 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.
- 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.
- 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.)
- The TCB shall support separate operator and administrator functions.
- 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.)
- 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.
- 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.
- 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.
- 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.
- The system developer shall provide to the evaluators a document
that describes the test plan, test procedures that show how the
security mechanisms were tested, and results of the security
mechanisms' functional testing. It shall include results of testing
the effectiveness of the methods used to reduce covert channel
bandwidths.
- Documentation shall be available that provides a description
of the manufacturer's philosophy of protection and an explanation
of how this philosophy is translated into the TCB. The interfaces
between the TCB modules shall be described. A formal description
of the security policy model enforced by the TCB shall be available
and proven that it is sufficient to enforce the security policy.
The specific TCB protection mechanisms shall be identified and
an explanation given to show that they satisfy the model. The
descriptive top-level specification (DTLS) shall be shown to
be an accurate description of the TCB interface. Documentation
shall describe how the TCB implements the reference monitor concept
and give an explanation why it is tamper resistant, cannot be
bypassed, and is correctly implemented. Documentation shall describe
how the TCB is structured to facilitate testing and to enforce
least privilege. This documentation shall also present the results
of the covert channel analysis and the tradeoffs involved in
restricting the channels. All auditable events that may be used
in the exploitation of known covert storage channels shall be
identified. The bandwidths of known covert storage channels the
use of which is not detectable by the auditing mechanisms, shall
be provided. (See the Covert Channel Guideline section.)
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
- 3.3.1.2 Object Reuse
- 3.3.1.3 Labels
- 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
- 3.3.1.3.2.3 Labeling
Human-Readable Output
- 3.3.1.3.3 Subject Sensitivity
Labels
- 3.3.1.3.4 Device Labels
- 3.3.1.4 Mandatory Access Control
- 3.3.2 Accountability
- 3.3.2.1 Identification and Authentication
- 3.3.2.1.1 Trusted Path
- 3.3.2.2 Audit
- 3.3.3 Assurance
- 3.3.3.1 Operational Assurance
- 3.3.3.1.1 System Architecture
- 3.3.3.1.2 System Integrity
- 3.3.3.1.3 Covert Channel
Analysis
- 3.3.3.1.4 Trusted Facility
Management
- 3.3.3.1.5 Trusted Recovery
- 3.3.3.2 Life-Cycle Assurance
- 3.3.3.2.1 Security Testing
- 3.3.3.2.2 Design Specification
and Verification
- 3.3.3.2.3 Configuration
Management
- 3.3.4 Documentation
- 3.3.4.1 Security Features User's
Guide
- 3.3.4.2 Trusted Facility Manual
- 3.3.4.3 Test Documentation
- 3.3.4.4 Design Documentation
- The TCB shall define and control access between named users
and named objects (e.g., files and programs) in the ADP system.
The enforcement mechanism (e.g., access control lists) shall
allow users to specify and control sharing of those objects,
and shall provide controls to limit propagation of access rights.
The discretionary access control mechanism shall, either by explicit
user action or by default, provide that objects are protected
from unauthorized access. These access controls shall be capable
of specifying, for each named object, a list of named individuals
and a list of groups of named individuals with their respective
modes of access to that object. Furthermore, for each such named
object, it shall be possible to specify a list of named individuals
and a list of groups of named individuals for which no access
to the object is to be given. Access permission to an object
by users not already possessing access permission shall only
be assigned by authorized users.
- All authorizations to the information contained within a storage
object shall be revoked prior to initial assignment, allocation
or reallocation to a subject from the TCB's pool of unused storage
objects. No information, including encrypted representations
of information, produced by a prior subjects actions is to be
available to any subject that obtains access to an object that
has been released back to the system.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 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.
- 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.
- 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.
- The TCB shall require users to identify themselves to it before
beginning to perform any other actions that the TCB is expected
to mediate. Furthermore, the TCB shall maintain authentication
data that includes information for verifying the identity of
individual users (e.g., passwords) as well as information for
determining the clearance and authorizations of individual users.
This data shall be used by the TCB to authenticate the user's
identity and to ensure that the security level and authorizations
of subjectsexternal to the TCB that may be created to act on
behalf of the in
|
