NCSC-TG-021
Library
No. S235,625
FOREWORD
The National Computer Security Center is
issuing the Trusted Database Management System
Interpretation as part of the Technical Guidelines
Program, through which we produce the "Rainbow Series."
In the Rainbow Series, we discuss in detail the
features of the Trusted Computer System Evaluation
Criteria (DoD 5200.28-STD) and provide guidance for
meeting each requirement. The National Computer
Security Center, through its Trusted Product Evaluation
Program, analyzes the security features of commercially
produced and supported computer systems. Together,
these programs ensure that organizations are capable of
protecting their important data with trusted computer
systems.
The Trusted Database Management System
Interpretation extends the evaluation classes of the
Trusted Computer System Evaluation Criteria to trusted
applications in general, and database management
systems in particular. It serves as an adjunct to the
Trusted Computer System Evaluation Criteria by
providing a technical context for the consideration of
entire systems constructed of parts and by presenting
database-specific interpretation of topics that require
direct comment. Thus, it is relevant to applications
which support sharing of computer services and
resources, and which enforce access control policies.
More specifically, it provides insight into the the
design, implementation, evaluation, and accreditation
of database management systems.
This document will be used for at least one
year after the date of signature. During this period
the NCSC will gain experience using the Trusted
Database Management Systems Interpretation in several
evaluations and continue to receive comments on issues
of technical accuracy, clarity of exposition, and
utility. After this trial period, necessary changes
will be made and a revised version issued.
_____________
PATRICK R. GALLAGHER, JR.
April 1991
Director National Computer Security Center
ACKNOWLEDGMENTS
This document represents the combined effort
of participants from the research community, industry,
and government working over several years. Three major
drafts and numerous intermediary versions were
produced, reviewed, and commented upon. To name all
the contributors would be impossible. To single out a
few would be to slight a host of others who gave
unstintingly of their time and talent. To all those
who contributed to the development and refinement of
the fundamental concepts, contributed to the
development of the several predecessor versions, and
who contributed valuable personal time and invaluable
experience in reviewing and commenting on the previous
versions, thanks is extended.
TABLE OF CONTENTS
FOREWORD i
ACKNOWLEDGMENTS iii
INTRODUCTION 1
HISTORICAL PERSPECTIVE 1
SCOPE 2
PURPOSE 2
STRUCTURE OF THE DOCUMENT 4
PART 1 TECHNICAL CONTEXT 7
TC-1 INTRODUCTION 9
TC-2 REFERENCE MONITOR PERSPECTIVE 10
TC-3 NEED FOR EVALUATION BY PARTS 11
TC-4 TCB SUBSETS 11
TC-4.1 INTRODUCTION 12
TC-4.2 TCB SUBSETS CONTEXT 13
TC-4.2.1 DEFINITION OF TCB SUBSETS 13
TC-4.2.2 MOTIVATION 13
TC-4.3 CONDITIONS FOR EVALUATION BY PARTS 14
TC-4.3.1 CANDIDATE TCB SUBSETS 14
TC-4.3.2 POLICY ALLOCATION 15
TC-4.3.3 TRUSTED SUBJECTS INCLUDED 15
TC-4.3.4 TCB SUBSET STRUCTURE 15
TC-4.3.5 SEPARATE SUBSET-DOMAINS 16
TC-4.3.6 SUPPORT FOR RVM ARGUMENTS 16
TC-4.4 EVALUATION ALTERNATIVES 17
TC-5 GENERAL INTERPRETED REQUIREMENTS 18
TC-5.1 OVERVIEW 18
TC-5.2 DETAILED REQUIREMENTS 18
TC-5.2.1 SECURITY POLICY 18
TC-5.2.1.1 Discretionary Access Control 18
TC-5.2.1.2 Object Reuse 18
TC-5.2.1.3 Labels 19
TC-5.2.1.4 Mandatory Access Control 20
TC-5.2.2 ACCOUNTABILITY 20
TC-5.2.2.1 Identification and Authentication 20
TC-5.2.2.2 Audit 21
TC-5.2.3 ASSURANCE 22
TC-5.2.3.1 Operational Assurance 22
TC-5.2.3.2 Life-Cycle Assurance 23
TC-5.2.4 DOCUMENTATION 24
TC-5.2.4.1 Security Features User's Guide 24
TC-5.2.4.2 Trusted Facility Manual 25
TC-5.2.4.3 Test Documentation 26
TC-5.2.4.4 Design Documentation 26
TC-5.3 SUMMARY OF THE REQUIREMENTS 26
TC-5.3.1 LOCAL REQUIREMENTS 26
TC-5.3.2 GLOBAL REQUIREMENTS 27
TC-6 DESIGN CHOICES 28
TC-6.1 OVERVIEW 28
TC-6.2 A SINGLE TCB SUBSET 28
TC-6.2.1 ANALYSIS OF THE CONDITIONS 28
TC-6.2.1.1 Condition 1: Candidate TCB Subsets 28
TC-6.2.1.2 Condition 2: Policy Allocation 29
TC-6.2.1.3 Condition 3: Trusted Subjects Included 29
TC-6.2.1.4 Condition 4: TCB Subset Structure 29
TC-6.2.1.5 Condition 5: Separate Subset-Domains 29
TC-6.2.1.6 Condition 6: Support for RVM Arguments 29
TC-6.2.2 EVALUATION CONSEQUENCES 29
TC-6.3 TWO TCB SUBSETS,MEETING THE CONDITIONS 30
TC-6.3.1 ANALYSIS OF THE CONDITIONS 30
TC-6.3.1.1 Condition 1: Candidate TCB Subsets 30
TC-6.3.1.2 Condition 2: Policy Allocation 31
TC-6.3.1.3 Condition 3: Trusted Subjects Included 31
TC-6.3.1.4 Condition 4: TCB Subset Structure 31
TC-6.3.1.5 Condition 5: Separate Subset-Domains 31
TC-6.3.1.6 Condition 6: Support for RVM Arguments 31
TC-6.3.2 EVALUATION CONSEQUENCES 32
TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS 33
TC-6.4.1 ANALYSIS OF THE CONDITIONS 34
TC-6.4.1.1 Condition 1: Candidate TCB Subsets 34
TC-6.4.1.2 Condition 2: Policy Allocation 34
TC-6.4.1.3 Condition 3: Trusted Subjects Included 34
TC-6.4.1.4 Condition 4: TCB Subset Structure 35
TC-6.4.1.5 Condition 5: Separate Subset-Domains 35
TC-6.4.1.6 Condition 6: Support for RVM Arguments 35
TC-6.4.2 EVALUATION CONSEQUENCES 35
TC-6.5 SUMMARY 36
PART 2 INTERPRETED REQUIREMENTS 37
IR-1 OVERVIEW AND CONTEXT 39
IR-2 SUMMARY OF THE INTERPRETATIONS 39
IR-2.1 SECURITY POLICY 39
IR-2.1.1 DISCRETIONARY ACCESS CONTROL 39
IR-2.1.2 OBJECT REUSE 40
IR-2.1.3 LABELS 40
IR-2.1.4 MANDATORY ACCESS CONTROL 40
IR-2.2 ACCOUNTABILITY 40
IR-2.2.1 IDENTIFICATION AND AUTHENTICATION 40
IR-2.2.2 AUDIT 40
IR-2.3 ASSURANCE 40
IR-2.3.1 OPERATIONAL ASSURANCE 40
IR-2.3.1.1 System Architecture 40
IR-2.3.1.2 System Integrity 40
IR-2.3.1.3 Covert Channel Analysis 41
IR-2.3.1.4 Trusted Facility Management 41
IR-2.3.1.5 Trusted Recovery 41
IR-2.3.2 LIFE CYCLE ASSURANCE 41
IR-2.3.2.1 Security Testing 41
IR-2.3.2.2 Design Specification and Verification 41
IR-2.3.2.3 Configuration Management 41
IR-2.3.2.4 Trusted Distribution 41
IR-2.4 DOCUMENTATION 42
IR-2.4.1 SECURITY FEATURES USER'S GUIDE 42
IR-2.4.2 TRUSTED FACILITY MANUAL 42
IR-2.4.3 TEST DOCUMENTATION 42
IR-2.4.4 DESIGN DOCUMENTATION 42
IR-3 LABELS 42
IR-3.1 GENERAL DISCUSSION 42
IR-3.2 SPECIFIC INTERPRETATIONS 43
IR-4 AUDIT 44
IR-4.1 GENERAL DISCUSSION 44
IR-4.2 SPECIFIC INTERPRETATIONS 45
IR-5 SYSTEM ARCHITECTURE 47
IR-5.1 GENERAL DISCUSSION 47
IR-5.2 SPECIFIC INTERPRETATIONS 47
IR-6 DESIGN SPECIFICATION AND VERIFICATION 48
IR-6.1 GENERAL DISCUSSION 48
IR-6.2 SPECIFIC INTERPRETATIONS 52
IR-7 DESIGN DOCUMENTATION 55
IR-7.1 GENERAL DISCUSSION 55
IR-7.2 SPECIFIC INTERPRETATIONS 56
APPENDIX A 59
CLASS (C1): 62
C1-1 SECURITY POLICY 62
C1-2 ACCOUNTABILITY 62
C1-3 ASSURANCE 62
C1-4 DOCUMENTATION 63
CLASS (C2): 66
C2-1 SECURITY POLICY 66
C2-2 ACCOUNTABILITY 66
C2-3 ASSURANCE 67
C2-4 DOCUMENTATION 68
CLASS (B1): 70
B1-1 SECURITY POLICY 70
B1-2 ACCOUNTABILITY 71
B1-3 ASSURANCE 73
B1-4 DOCUMENTATION 74
CLASS (B2): 77
B2-1 SECURITY POLICY 77
B2-2 ACCOUNTABILITY 79
B2-3 ASSURANCE 81
B2-4 DOCUMENTATION 85
CLASS (B3): 89
B3-1 SECURITY POLICY 89
B3-2 ACCOUNTABILITY 91
B3-3 ASSURANCE 93
B3-4 DOCUMENTATION 98
CLASS (A1): 102
A1-1 SECURITY POLICY 102
A1-2 ACCOUNTABILITY 104
A1-3 ASSURANCE 106
A1-4 DOCUMENTATION 112
APPENDIX B 117
1. PERSPECTIVE ON ASSURANCE 119
2. PROCUREMENT OPTIONS 120
3. ALTERATION OF PREVIOUSLY EVALUATED TCB 122
4. SATISFYING RVM REQUIREMENTS 125
5. SUBSET DEPENDENCY 127
6. TAMPER RESISTANCE ARGUMENTS 131
7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS 132
8 CONTENT-DEPENDENT AND CONTEXT-DEPENDENT
ACCESS CONTROL 136
9. BULK LOADING OF A DATABASE 137
10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT 137
11. RATING MORE COMPLEX SYSTEMS 139
GLOSSARY 141
BIBLIOGRAPHY 145
INTRODUCTION
HISTORICAL PERSPECTIVE
The Department of Defense Trusted Computer System
Evaluation Criteria (TCSEC), published in 1983 as
CSC-STD-001-83, consolidates knowledge about the degree
of trust one can place in a computer system to protect
sensitive information and organizes this knowledge into
usable criteria for system evaluation. The TCSEC was
republished as a DoD standard, DoD-5200.28-STD, in
December 1985 to provide a means of evaluating specific
security features and assurances available in "trusted,
commercially available automatic data processing system
The TCSEC's rating scale extends from a
minimal to a high level of trust with advanced security
features and sophisticated assurance measures.
Specific criteria determine each rating level and guide
system builders and evaluators in determining the level
of trust provided by specific systems. When the rating
levels are combined with environmental guidelines and
minimum security protection requirements, accreditation
decisions for specific installations can be made.
The philosophy of protection embodied in the
TCSEC requires that the access of subjects (i.e.,
processes in a domain) to objects (i.e., containers of
information) be mediated in accordance with an explicit
and well-defined security policy. At the higher
criteria classes, the "reference monitor concept" [1]
is an essential part of the system and the security
policy is modeled. There are several security policy
models that represent the desired behavior of a
reference monitor. The Bell-La Padula model [4-6] and
its Multics interpretation [3] are commonly used, but
not mandated.
The computer security research and
development that underpin the TCSEC began in the late
1960s and concentrated on secure operating systems. By
the early 1970s initial worked examples had provided a
substantial amount of information about building trust
into operating systems. Research continued throughout
the 1970s to refine mechanisms, features, and
assurances needed to provide trusted operating systems.
Multilevel database management security
received far less research and development attention
than did secure operating systems. This was primarily
due to the perception that one could not credibly
implement a multilevel secure database management
system (DBMS) on top of an untrusted operating system
base. However, some research in multilevel secure
DBMSs (mostly theoretical) was conducted during the
1970s [15-16], and research has continued to the
present [9-14, 17-19, 22, 25-28]. By the mid 1980s,
commercially developed, trusted operating systems were
becoming available that could provide the basis for
hosting secure applications such as multilevel secure
DBMSs.
In June 1986, the National Computer Security
Center (NCSC) initiated its efforts to address the
evaluation of trusted database management systems with
an Invitational Workshop in Baltimore, Maryland.
Representatives from the research, database vendor,
commercial, and government communities met to address
issues of database management security. The attendees
met to discuss aspects of trust (defined by the TCSEC)
that were sufficiently well defined and capable of
producing repeatable and objective assessments. The
NCSC invited issue papers and prepared a discussion
agenda. The issue papers and the subcommittee
summaries were published as the Proceedings of the
National Computer Security Center Invitational Workshop
on Database Security [20].
As an outgrowth of this workshop, the NCSC
undertook the task of preparing this Trusted Database
Management System Interpretation (TDI) of the TCSEC to
focus on the special problems posed by DBMSs. A
working group was assembled to draft this
Interpretation. Three drafts were produced, with
extensive community review and public discussion. This
Interpretation is the result of the interaction within
the general computer security and database management
communities.
SCOPE
The interpretations in this document are
intended to be used in conjunction with the TCSEC
itself; they apply to application-oriented software
systems in general, and database management systems
(DBMSs) in particular. Although the interpretations,
as noted, are general enough to apply to any software
system which supports sharing and needs to enforce
access control (e.g., transaction processing systems,
electronic mail systems), in the interest of
simplicity, the discussion, and thus the terminology,
will be directed toward DBMSs.
The interpretations are intended to be
applied primarily to commercially developed trusted
DBMSs, but can also be applied to the evaluation of
existing non-commercial DBMSs and to the specification
of security requirements for DBMS acquisitions.
PURPOSE
This Interpretation of the TCSEC has been
prepared for the following purposes:
To provide a standard to manufacturers for
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 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,
and
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 a security
evaluation metric, evaluations can be delineated into
two types: (1) evaluations performed on a computer
product from a perspective that excludes the
application environment; or, (2) evaluations 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 National Computer Security Center (NCSC)
through the Trusted Product Evaluation Program and is
called "formal product evaluation."
The latter type of evaluation, that is, one
done for the purpose of assessing a system's security
attributes with respect to a specific operational
mission, is known as a "certification evaluation." A
formal product evaluation does not constitute
certification or accreditation for the system to be
used in any specific application environment. 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 sensitive or
classified information. Designated Approving
Authorities (DAAs) remain ultimately responsible for
specifying the security of systems they accredit.
3
The TCSEC and this Interpretation will be
used directly and indirectly in the certification
process. Along with applicable policy, they 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 formal product evaluation,
reports from that process will be used as input to the
certification evaluation. Moreover, the National
Security Agency plans to publish additional guidelines
to assist certifiers and help ensure consistency in
certifications of systems processing national security
informantion.
STRUCTURE OF THE DOCUMENT
The remainder of the TDI is divided into two
parts, plus two appendices and a glossary.
PART 1, "TECHNICAL CONTEXT," presents general
information about the evaluation of trusted systems
that are constructed of several parts. This discussion
is critical to trusted DBMSs built upon trusted
operating systems, but is not limited to DBMSs only.
It is included in the TDI because it is not currently
available in any previously published document. This
section reviews the central reference monitor concept,
explains the need to evaluate a system built of
well-defined parts, and develops the concept of TCB
subsets. TCB subsets provide a way of splitting a
total TCB along access control policy lines such that
an evaluation by parts can be undertaken. PART 1
concludes with an interpretation of those TCSEC
requirements which are relevant to an evaluation by
parts, and a description of the process of evaluation
by parts.
PART 2, "INTERPRETED REQUIREMENTS," provides
interpretions of those TCSEC requirements that are
either specific to DBMSs (or applications in general),
or are particularly relevant to DBMSs. The number of
requirements that are treated explicitly is relatively
small, because many of the TCSEC requirements apply as
stated to database management systems. The
requirements treated explicitly are labels, audit,
system architecture, design specification and
verification, and design documentation.
Appendix A summarizes the interpreted
requirements for each TCSEC class and is intended to
provide an easy reference for those requiring a listing
of requirements for a specific class (e.g., B2).
Appendix B provides discussion of several topics not
directly tied to the requirements levied on trusted
DBMSs by the interpretation of the TCSEC requirements.
The TDI proper will be supplemented by a
Companion Document Series (CDS). The CDS will address
a wide spectrum of issues related to trusted DBMSs but
which are beyond the scope of this document. Community
debate about on-going topics of interest will probably
result in gradual extensions of what is known about
trusted DBMSs. Thus, volumes in the CDS will be issued
both regularly (to document the state of the community
debate) and by exception (to record new problems and
new solutions).
PART 1
TECHNICAL CONTEXT
7
TC-1 INTRODUCTION
Modern computing systems are rarely conceived
and built by a single organization. Rather, the rule
is that systems are constructed by assembling
parts?hardware, firmware, and software?produced
independently by various organizations or vendors.
This fact introduces a fundamental difficulty into the
task of evaluating a "system" for conformance to the
trust requirements of the Trusted Computer System
Evaluation Criteria (TCSEC). [8] This difficulty stems
from the fact that assessment (either evaluation of a
product or certification of a system) entails a global
perspective of the entire system under consideration.
There are not yet widely accepted methods of factoring
the various aspects of a trust assessment and then
reassembling the results into a statement about the
whole.
These conflicting perspectives of local
production and global evaluation analysis are
particularly evident in the field of database
management, but they are by no means limited to that
field. Thus the publication of this Interpretation
requires consideration of how to deal with systems
built in parts in the absence of a general treatment of
the topic. On the other hand, any treatment of the
issue in the context of trusted database management
will have significant influence in other fields where
the same or similar problems arise, just because of
community review and NCSC publication. The approach
taken in this document is to address the issues of
evaluating systems built of parts in a way that is
independent of the field of trusted database
management. This conscious attitude of generality is
intended to make clear the distinction between the
larger system-of-parts issues and the more specific
DBMS issues.
PART 1, "TECHNICAL CONTEXT," is divided into
six sections. Section TC-2, "Reference Monitor
Perspective," summarizes the role of the reference
monitor concept in both the TCSEC and the assessing of
a system for its trust characteristics. Section TC-3,
"Need for Evaluation by Parts," deals with the need to
extend the reference monitor perspective slightly to
begin to address the evaluation of systems constructed
of separate parts. Section TC-4, "TCB Subsets," is the
heart of PART 1. That section introduces a
conservative extension to the reference validation
mechanism, TCB subsets. This extension provides the
basis for being able to undertake evaluation of systems
built in parts in a way that allows re-use of the
results of separate evaluations (whether those
evaluations were performed before the current
evaluation was begun or whether the separate
evaluations overlap in time). Section TC-5, "General
Interpreted Requirements," outlines the application of
the TCSEC requirements to individual TCB subsets when
an evaluation by parts is being done. Section TC-6,
"Design Choices" describes the general process of
applying TCB subsets and meeting the conditions for
evaluation by parts. The treatment in this section is
general and not limited to DBMSs; DBMS-specific issues
are discussed in the appendices.
TC-2 REFERENCE MONITOR PERSPECTIVE
Building or evaluating a system for
compliance with the requirements of a particular class
in the TCSEC is based on the perspective of the Trusted
Computing Base (TCB). The notion of the TCB is central
to the entire concept of assessing systems for trust.
The reference monitor described in the Anderson report
[1] is the basis of the notion of a TCB, as described
in the TCSEC:
For convenience, these evaluation criteria
use the term Trusted Computing Base to refer to the
reference validation mechanism, be it a security
kernel, front-end security filter, or the entire
trusted computer system. [8, p. 67]
Even in those lower classes (below B2) where
the reference monitor concept and reference validation
mechanisms are not mentioned explicitly, the
perspective of the reference monitor and its
implementation as a reference validation mechanism is
present. Specifically, there are requirements for (1)
identifying the policy being enforced, (2) identifying
subjects and objects, (3) providing evidence that the
operation of the reference validation mechanism matches
the high-level description of the user interface, and
(4) demonstrating isolation of the TCB.
Therefore, all TCSEC evaluations share the
initial conceptual steps of identifying the mediation
policy, the subjects, and the objects. Starting from a
global system perspective, the initial step is to
identify the access mediation policy that will be
enforced. One must then identify those active system
entities that are candidates >
Transfer interrupted!