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 for being the "subjects"
whose access to objects the TCB will mediate.
Similarly, one must identify those passive entities,
those data repositories, that are candidates for being
the "objects," access to which the TCB will mediate.
As usual, the existence of an abstraction
within a system does not make it necessarily a
reference-monitor object, i.e., one visible at the TCB
interface. This is because the TCB will make use of
system abstractions for both its internal processes and
its storage requirements. Those entities, while being
stored in system "objects," will not be available to
untrusted processes (that is, they are not exported by
the TCB). Thus the analytical, iterative step is the
separation of candidate subjects and objects into those
that are mediated by the TCB and those that are not.
The various trust classes include
requirements, at varying levels of completeness and
rigor, that the basic reference monitor perspective of
mediating access of subjects to objects be implemented
in a correct, self-protecting, and non-bypassable
manner. The core requirements of the TCSEC classes
focus on these reference monitor imperatives. The
increasingly strict requirements for visibility into
the system design and implementation (structure,
documentation, testing, configuration, and distribution
requirements) all support the notion of checking the
system's conformance to its identified intent with
regard to the subjects, objects, and policy.
TC-3 NEED FOR EVALUATION BY PARTS
The need to be able to evaluate and certify
systems built in parts is increasingly evident. This
need is seen in a variety of contexts:
The need to evaluate and certify systems
built out of parts sold by different vendors, a
situation especially prevalent in the field of trusted
DBMSs.
The need to re-assess systems that have
undergone either small- or large-scale improvements and
are already evaluated and placed on the Evaluated
Products List (EPL).
The general problem of "families of
systems," systems that exist on a spectrum of hardware
bases or that can be customized for a user's specific
needs.
In all such cases, two related versions of a
system are largely similar. It should be possible to
undertake evaluations and certifications in such a way
that the entire assessment does not have to be re-done
for every slight variation that appears. The current
state of technology, however, places limitations on
what can be accomplished in this regard; it is not
currently possible to determine the trust
characteristics of a system on the basis of an
arbitrary collection of subparts. The overall task of
trust assessment entails so many interrelated subtasks
that the ability to separate and reassemble is not well
understood.
In this circumstance of needing to be able to
accommodate evaluation of a system built in parts and
the lack of consensus about how this can be done in a
technically sound fashion, a conservative approach must
be adopted. The following are required: (1) a clear
description of what "parts" will be considered for
separate evaluation; (2) a clear description of the
conditions under which such an evaluation by parts will
be undertaken; and (3) a general interpretation of
TCSEC requirements as they would apply when a system is
being evaluated by parts. The "parts" that will be
considered by separate evaluation are called "TCB
subsets," the topic of Section TC-4 below.
TC-4 TCB SUBSETS
TC-4.1 INTRODUCTION
To attempt an evaluation of a TCB by
splitting it into parts, there must be available a
precise definition of what parts are candidates for
separate evaluation (that is, for evaluation by parts)
as well as any other conditions that must be satisfied
before an evaluation by parts will be undertaken. This
section defines "TCB subset" as a strict and
conservative extension of the traditional concept of
the reference validation mechanism (RVM) as a method of
delineating which parts of a TCB can be candidates for
separate evaluation. The definition of TCB subsets, as
well as explanatory and motivational material, is
included below in Section TC-4.2, "TCB Subsets
Context." Section TC-4.3 addresses the conditions that
must be satisfied by a TCB divided into a set of TCB
subsets before evaluation by parts will be undertaken.
These conditions assure that the structure of and
relationships among TCB subsets will satisfy TCSEC
requirements, especially those derived from the
reference monitor concept.
TC-4.2 TCB SUBSETS CONTEXT
TC-4.2.1 DEFINITION OF TCB SUBSETS
A TCB subset M is a set of software,
firmware, and hardware (where any of these three could
be absent) that mediates the access of a set S of
subjects to a set O of objects on the basis of a stated
access control policy P and satisfies the properties:
1) M mediates every access to objects in O by
subjects in S;
2) M is tamper resistant; and
3) M is small enough to be subject to
analysis and tests, the completeness of which can be
assured.
M uses resources provided by an explicit set
of more primitive TCB subsets to create the objects of
O, create and manage its data structures, and enforce
the policy P. If there are no TCB subsets more
primitive than M, then M uses only hardware resources
to instantiate its objects, to create and manage its
own data structures, and to enforce its policy.
The above definition does not explicitly
prohibit an access control policy P that allows trusted
subjects. The implications for the evaluation process
when a TCB subset's policy allows or does not allow
such trusted subjects are substantial and are discussed
in Section TC-6.4. As described in TC-4.3, one of the
conditions for an evaluation by parts of a TCB made up
of TCB subsets is that all the trusted subjects of each
TCB subset be included in that TCB subset.
TC-4.2.2 MOTIVATION
The definition of "TCB subset" is intended to
parallel the definitions of the reference monitor and
reference validation mechanism found in the Anderson
report [1] and included in the TCSEC itself. "The term
Trusted Computing Base [refers] to the reference
validation mechanism, be it security kernel, front-end
security filter, or the entire trusted computer
system." [8, p. 67] "TCB subset" is defined exactly
like a reference validation mechanism, with only one
difference, that it does not necessarily extend to the
hardware. Rather, a TCB subset uses either hardware
resources or the resources provided by other, more
primitive TCB subsets. Thus TCB subsets build on
abstract machines, either physical hardware machines or
other TCB subsets. Just like reference validation
mechanisms, a TCB subset must enforce a defined access
control policy.
TC-4.3 CONDITIONS FOR EVALUATION BY PARTS
Building or evaluating a system using the
definition of TCB subsets in the section above requires
meeting six conditions in addition to demonstrating
that the candidate TCB subsets satisfy the properties
appropriate to the evaluation target class. The
conditions are as follows:
The candidate TCB subsets are
identified;
The system policy is allocated to
the candidate TCB subsets;
Each candidate TCB subset M[i]
includes all the trusted subjects with respect to
its technical policies P[i];
The TCB subset structure or
architecture is explicitly described;
Each TCB subset occupies distinct
subset-domains; and
The more primitive TCB subsets
provide support for the RVM arguments for less primitve TCB
subsets.
These conditions are described below.
TC-4.3.1 CANDIDATE TCB SUBSETS
The first condition is that the relevant
elements of each candidate TCB subset M[i] be
identified. The hardware, firmware, and software which
compose the TCB subset need to be clearly identified,
along with the subjects and objects. In terms of
Section TC-4.2.1, this condition is the identification
of M[i], S[i], and O[i]. There may be no objects
mediated by more than one TCB subset. That is, there
cannot be an object O that is both in O[i] and O[j].
TC-4.3.2 POLICY ALLOCATION
The next condition is policy allocation, the
description of the technical policy P[i] for each
identified M[i] along with the relation of these
policies to the system policy P. The policies P[i]
will be expressed in terms of subjects in S[i] and
objects in O[i]. Thus, to satisfy the TCSEC
requirement that the (composite) TCB enforce its stated
policy P, each rule in P must be traceable through the
structure of the candidate TCB subsets to the TCB
subset(s) where that enforcement occurs. See Sections
TC-5.2.1.1 and TC-5.2.1.4.
TC-4.3.3 TRUSTED SUBJECTS INCLUDED
Every trusted subject with respect to P[i]
must be part of the TCB subset M[i]. This condition
makes possible separate evaluation of TCB subsets with
respect to "local" requirements. When this condition
is not met, evaluation of candidate TCB subsets cannot
be guaranteed on an evaluation by parts basis. This
situation is treated in Section 6.4.
TC-4.3.4 TCB SUBSET STRUCTURE
The TCB subsets will exhibit a structure
based on the ordering implied by dependency. TCB
subset A is less primitive than TCB subset B if (a) A
directly depends on B or (b) a chain of TCB subsets
from A to B exists such that each element of the chain
directly depends on its successor in the chain. In
this case we use the phrase "TCB subset B is more
primitive than TCB subset A" synonymously.
The sense of "directly depend" in (a) is
exactly the following: it is not possible to verify
the implementation of A with respect to its
specification without a statement about the
specification of B.
More precisely, for a candidate TCB subset M,
let sM denote the specification of M. The
specification will include, as a minimum, the statement
of the technical policy P of M. Further, let vM denote
the (engineering) demonstrations of the correct
implementation of M with respect to its specification.
A (candidate) TCB subset A "depends (for its
correctness)" on (candidate) TCB subset B if and only
if the arguments of vA assume, wholly or in part, that
sB has been implemented correctly. (See Appendix B,
item 5 for additional discussion.)
The proposed structure of TCB subsets has to
be identified. The order must be a partial order.
(Without a partial order, there could be circular
chains of dependencies that would inhibit separate
evaluations of the TCB subsets.)
TC-4.3.5 SEPARATE SUBSET-DOMAINS
The candidate TCB subsets must operate in
near isolation from each other, with the only
interaction between them being that explicitly asserted
as part of the interface. In the case of reference
monitors, many existing implementations have relied on
the domain concept [23] which supports the assertions
of non-bypassability and self protection. A natural
extension of the domain concept will be required for
isolation of TCB subsets from each other and from
non-TCB entities.
A subset-domain is a set of system domains.
Each candidate TCB subset must occupy a distinct
subset-domain such that modify-access to a TCB subset's
subset-domain is permitted only to that TCB subset and
(possibly) to more primitive TCB subsets. This
requirement ensures that the structure of
subset-domains with respect to access is consonant with
the dependency relation among TCB subsets.
TC-4.3.6 SUPPORT FOR RVM ARGUMENTS
Candidate TCB subsets must satisfy the three
RVM properties included in the definition in TC-4.2.1
in order to complete evaluation by parts successfully.
TCB subsets that build on resources and functionality
provided by more primitive TCB subsets must rely on
assured and evaluatable characteristics of those more
primitive TCB subsets. A convincing argument must be
advanced that the features, characteristics, and
assurances provided by the more primitive TCB subsets
are capable of supporting RVM arguments for the less
primitive TCB subsets.
The first property (mediating every access)
requires that there is no way of bypassing the
mediation provided by TCB subset M for its objects,
either directly or by unexpected side-effects of
interactions with other TCB subsets. A variety of
approaches could suffice for demonstrating this
property.
The second property (tamper resistance)
requires that the policy-critical code and data for the
less primitive TCB subset be protected from any
alteration not specifically allowed by the TCB subset.
A variety of approaches could suffice for demonstrating
this property.
The third property (completeness of testing
and analysis for correctness) requires the
(engineering) demonstrations vM[i] of the correctness
of each less primitive candidate TCB subset M[i]. A
convincing argument must therefore be advanced that the
specifications sM[k] for all of the more primitive TCB
subsets M[k] on which M[i] depends will suffice for
establishing vM[i].
TC-4.4 EVALUATION ALTERNATIVES
As noted earlier, the need to evaluate
systems whose elements are developed separately,
possibly by independent developers, results in the need
to define TCB subsets. That is not to say, however,
that design by TCB subsetting and the subsequent
evaluation by parts are the only alternatives. Rather,
there are three distinct possibilities.
A system TCB, regardless of any internal
structure, may be viewed as a single entity. In such a
case, the evaluation may proceed essentially as an
evaluation against the TCSEC. This case is examined in
Section TC-6.2.
A system TCB may be presented as a subsetted
architecture composed of a number of candidate TCB
subsets. Given that each of the candidate TCB subsets
satisfies the conditions set forth in Section TC-4.3,
an evaluation by parts is possible. This case is
described in Section TC-6.3.
It may be possible to satisfy only some of
the conditions for evaluation by parts. This situation
might arise when a previously evaluated TCB or TCB
subset is modified to accommodate the policy-enforcing
elements of a new application layer. A special case of
this situation is described in Section TC-6.4. In such
cases, depending upon the particulars, it may be
possible to realize some of the savings in evaluation
effort. However, no general statements can be made for
these cases.
TC-5 GENERAL INTERPRETED REQUIREMENTS
TC-5.1 OVERVIEW
This section provides specific
interpretations of those TCSEC requirements that are
particularly relevant for subsetted architectures and
evaluation by parts. Its organization is derived from
the structure of the TCSEC requirements. For each
relevant TCSEC requirement there is a discussion of how
that requirement is interpreted in an evaluation by
parts.
For conciseness, only the requirements
headings applicable for A1 systems are included below.
Thus, the interpretation guidance below should be
applied only as demanded by the requirements for the
target class of the candidate trusted system. For a
system targeted at an evaluation class below A1, only
those requirements that pertain to the target class
apply to the TCB subsets making up that system.
A listing of the requirements and
interpretations by TCSEC class is presented in Appendix
A. The rationale for the applicability of the TCSEC
requirements to TCB subsets alone or to the TCB as an
entirety is described in Appendix B, item 7.
TC-5.2 DETAILED REQUIREMENTS
TC-5.2.1 SECURITY POLICY
TC-5.2.1.1 Discretionary Access Control
The discretionary access control requirements
apply as stated in the TCSEC to every TCB subset whose
policy includes discretionary access control of its
subjects to its objects. Any TCB subset whose policy
does not include such discretionary access control is
exempt from this requirement.
TC-5.2.1.2 Object Reuse
This requirement applies as stated in the
TCSEC to every TCB subset in the TCB.
TC-5.2.1.3 Labels
This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.
Label Integrity
This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.
Exportation of Labeled Information
This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.
Subject Sensitivity Labels
This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.
Device Labels
This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its objects
and has attached physical or virtual devices. Any TCB
subset whose policy does not include such mandatory
access control or has no attached physical or virtual
devices is exempt from this requirement. This
requirement can be satisifed by the cooperative action
of more than one TCB subset.
TC-5.2.1.4 Mandatory Access Control
This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.
TC-5.2.2 ACCOUNTABILITY
TC-5.2.2.1 Identification and Authentication
This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.
If the TCB is composed of TCB subsets, one
TCB subset may either rely on a mechanism in another
TCB subset to provide identification and authentication
services or provide the services directly. Similarly,
that TCB subset may rely on a mechanism in another more
primitive TCB subset to ensure that the security level
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. Each TCB
subset may maintain its own identification and
authentication data or one central repository may be
maintained. If each TCB subset has its own data, then
the information for each individual user must be
consistent among all subsets.
Trusted Path
This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.
When TCB subsets are used, the requirement
for trusted path at levels B2 and above remains
applicable to the entire TCB. The need for trusted
path "when positive TCB-to-user connection is required
(e.g., login, change subject security level)" can
require user interaction with virtually any TCB subset
within the TCB. The implementation of trusted path
could be localized in a single TCB subset.
Alternatively, it could be implemented in more than one
TCB subset if the separate implementations together
comply with the system security policy.
TC-5.2.2.2 Audit
This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.
A TCB subset may maintain its own security
audit log, distinct from that maintained by more
primitive TCB subsets, or it may use an audit interface
provided by a different TCB subset allowing the audit
records it generates to be processed by that TCB
subset.
If the TCB subset uses different user
identifications than a more primitive TCB subset, there
shall be a means to associate audit records generated
by different TCB subsets for the same individual with
each other, either at the time they are generated or
later.
Any TCB subset wherein events may occur that
require notification of the security administrator
shall be able to do the following: (1) detect the
occurrence of these events, (2) initiate the recording
of the audit trail entry, and (3) initiate the
notification of the security administrator. The
ability to terminate events (2) and (3) above may be
provided either in the TCB subset within which they
occur, or in the TCB subset(s) where actions that lead
to the event were initiated.
The monitoring and notification requirements
may require cooperation between multiple distinct TCB
subsets or multiple instantiations of the same TCB
subset. For example, to detect the accumulation of
events for a single user it may be necessary to collect
events from several subjects in distinct processes that
are surrogates for the same user. As another example,
there may be a single TCB subset that collects events
from a number of other TCB subset instantiations and,
based on its analysis of them, notifies the security
administrator.
TC-5.2.3 ASSURANCE
TC-5.2.3.1 Operational Assurance
System Architecture
This requirement applies as stated in the
TCSEC to every TCB subset, with the following
additional interpretations.
The TCB must provide domains for execution
that are allocated to and used by TCB subsets according
to the subset-domain condition for evaluation by parts.
A most primitive TCB subset must provide domains for
execution. A less primitive TCB subset must make use
of domains provided by a more primitive TCB subset. A
less primitive TCB subset may provide further execution
domains but is not required to do so.
Similarly, the TCB must provide distinct
address spaces for untrusted processes. A most
primitive TCB subset must provide distinct address
spaces for its subjects. A less primitive TCB subset
must make use of the distinct address space provided by
a more primitive TCB subset. A less primitive TCB
subset may provide more fine-grained distinct address
spaces, but is not required to do so.
In general, requirements specifically
referring to hardware or firmware apply only to TCB
subsets that include hardware or firmware. The
exception is the requirement that the TCB make
effective use of available hardware. This requirement
applies to those TCB subsets that use resources
provided by more primitive TCB subsets in lieu of
hardware. Those TCB subsets are required to make
effective use of the protection-relevant features
exported to it by the more primitive TCB subsets (e.g.,
execution domains, support for distinct address spaces)
to separate those elements that are protection-critical
from those that are not.
System Integrity
This requirement applies as stated in the
TCSEC to every TCB subset that includes hardware or
firmware. Any TCB subset that does not include
hardware or firmware is exempt from this requirement.
Covert Channel Analysis
This requirement applies as stated in the
TCSEC to the entire TCB. When the TCB is made up
entirely of TCB subsets meeting the conditions for
evaluation by parts, analysis of the individual TCB
subsets satisfies this requirement. Otherwise, covert
channel analysis of the entire TCB must be performed
(even if the results of covert channel analysis of the
individual TCB subsets were available).
Trusted Facility Management
This requirement applies as stated in the
TCSEC to the entire TCB. Any "operator" or
"administrator" functions intrinsic to an individual
TCB subset must be supported by that TCB subset or by a
more primitive TCB subset.
Trusted Recovery
This requirement applies as stated in the
TCSEC to the entire TCB and to the individual TCB
subsets. The cooperative recovery actions of the TCB
subsets making up the TCB must provide trusted recovery
for the overall TCB. Otherwise, trusted recovery
evaluation must address the entire TCB (even if the
individual TCB subsets meet the trusted recovery
requirements).
TC-5.2.3.2 Life-Cycle Assurance
Security Testing
This requirement applies as stated in the
TCSEC to the entire TCB. If a TCB consists of TCB
subsets meeting the conditions for evaluation by parts,
the satisfaction of the requirements by each TCB subset
satisfies the requirement for the entire TCB.
Otherwise, security testing of the entire TCB must be
performed (even if the results of testing the
individual TCB subsets were available).
Design Specification and Verification
This requirement applies as stated in the
TCSEC to every TCB subset, with the following specific
additional interpretations.
It must be demonstrated that the security
policy enforced by the composite TCB is represented by
the collection of policy models for the individual TCB
subsets.
The argument that the descriptive top level
specification (DTLS) and formal top level specification
(FTLS) are consistent with the TCB interface applies to
the entire TCB. There is required an explicit and
convincing description of how the set of top level
specifications (one for each TCB subset) describes the
TCB interface in terms of exceptions, errors, and
effects.
Configuration Management
This requirement applies as stated in the
TCSEC to every TCB subset in the TCB, with the
following additional interpretation.
Because subsets of the TCB may be developed
independently, a single configuration management system
may not be feasible. However, the combination of
configuration management systems used to support all
the TCB subsets must meet all the stated requirements.
The information describing the interrelations between
separate TCB subsets and separate security policy
models falls into the category of "all documentation
and code associated with the current version of the
TCB" in the TCSEC requirements.
Trusted Distribution
This requirement applies as stated in the
TCSEC to the entire TCB. It can be met by satisfying
the requirements for each TCB subset if procedures
exist for assuring that all TCB subsets upon which a
particular TCB subset depends (that is, the more
primitive TCB subsets) are exactly the same version as
specified for the TCB subset in question.
TC-5.2.4 DOCUMENTATION
TC-5.2.4.1 Security Features User's Guide
This requirement applies as stated in the
TCSEC to every TCB subset in the TCB. This collection
of guides must include descriptions of every TCB subset
in the TCB and explicit cross-references to other
related user's guides to other TCB subsets, as
required. In addition, interactions between mechanisms
within different TCB subsets must be clearly described.
TC-5.2.4.2 Trusted Facility Manual
This requirement applies as stated in the
TCSEC to the TCB and to every TCB subset in the TCB.
This requirement can be met by providing a
set of manuals, one for each distinct (non-replicated)
TCB subset. Each manual shall address the functions
and privileges to be controlled for the associated TCB
subset. Additionally, it must clearly show the
interfaces to, and the interaction with, more primitive
TCB subsets. The manual for each TCB subset shall
identify the functions and privileges of the TCB
subsets on which the associated TCB subset depends.
Also, the TCB subset's manual shall identify which, if
any, configuration options of the more primitive TCB
subsets are to be used for the composite TCB to operate
securely.
Any pre-defined roles supported (e.g.,
database administrator) by the TCB subset shall be
addressed.
The means for correlating multiple audit logs
and synonymous user identifications from multiple TCB
subsets (if such exist) shall also be addressed.
The trusted facility manual shall describe
the composite TCB so that the interactions among the
TCB subsets can be readily determined. Other manuals
may be referenced in this determination. The manuals
that address the distinct modules of the TCB and the
generation of the TCB need to be integrated with the
other trusted facility manuals only to the extent that
they are affected by the use and operation (versus the
development) of the composite TCB.
The TCB modules that contain the reference
validation mechanism must be associated with the TCB
subset to which they belong. The procedure for
generating a new TCB after modifying only one (or
several) TCB subsets must be described. This may be
accommodated by independent regeneration of the
individual TCB subsets or by regeneration of only the
affected TCB subsets.
TC-5.2.4.3 Test Documentation
This requirement applies as stated in the
TCSEC to the composite TCB.
TC-5.2.4.4 Design Documentation
This requirement applies as stated in the
TCSEC to the composite TCB, with the following specific
additional interpretations:
Requirements concerning models, FTLS and
DTLS, apply to individual TCB subsets.
The requirement concerning the description
of interfaces between modules of the TCB includes the
interfaces between TCB subsets.
The documentation of the implementation of
a reference validation mechanism must include
justification for meeting the conditions for evaluation
by parts.
The A1 requirement to describe
clearly non-FTLS internals of the TCB applies to TCB
subsets.
TC-5.3 SUMMARY OF THE REQUIREMENTS
The requirements interpretations in Section
TC-5.2 above can be grouped into two categories: those
that apply to individual TCB subsets and those that
apply totally or in part to the overall TCB. For
purposes of exposition, the former category will be
termed "local requirements," that is, those for which
separate analysis of the individual TCB subsets
suffices to determine compliance for the composite TCB.
The latter are termed "global requirements," that is,
those which require analysis of the entire system and
for which separate analysis of the individual TCB
subsets does not suffice.
TC-5.3.1 LOCAL REQUIREMENTS
Discretionary Access Control;
Object Reuse;
Labels (except Subject Sensitivity Labels);
Mandatory Access Control;
System Architecture (except domains for
execution and distinct address spaces);
System Integrity;
Configuration Management;
Security Features User's Guide;
Design Documentation
models,
DTLSs,
FTLSs, and
non-FTLS internals.
TC-5.3.2 GLOBAL REQUIREMENTS
Subject Sensitivity Labels;
Identification and Authentication;
Trusted Path;
Audit;
System Architecture domains for execution, and distinct
address spaces;
Covert Channel Analysis;
Trusted Facility Management;
Trusted Recovery (also applies to
individual TCB subsets);
Security Testing;
Design Specification and Verification
correspondence between system
policy and the set of TCB subset models
consistency of TCB interface with the
set of TCB subset DTLSs, and
consistency ofTCB interface with the
set of TCB subset FTLSs;
Trusted Distribution;
Trusted Facility Manual (also applies to individual TCB
subsets);
Test Documentation; and
Design Documentation (except models, DTLSs, FTLSs, and
non-FTLS internals).
TC-6 DESIGN CHOICE
TC-6.1 OVERVIEW
This section examines the several design
choices available for constructing systems in parts and
the consequences of each when attempting to perform an
evaluation by parts. The first case described is that
of a TCB evaluated under the TCSEC without benefit of
TCB subset structuring. This case is of value for
several reasons: it serves as a reference point; it
can be considered the degenerate case of subsetting;
and it is always an option to evaluate any TCB,
regardless of internal structure, as a monolith. The
second and third cases are presented in terms of a
configuration of exactly two subsets; the
generalization to more than two TCB subsets is
straightforward. The second case is that of a
subsetted architecture that exactly satisfies the
conditions for evaluation by parts. The third case
represents a special case of an altered TCB, one which
is implemented using trusted subjects.
Note that no evaluation using TCB subsets and
evaluation by parts results in a TCB subset receiving
an evaluation rating. Rather, the entire system, with
its composite TCB, is evaluated and receives a rating.
However, evaluation by parts is intended to allow the
results of local analysis of individual TCB subsets to
be distinguishable and separately referencable. For
further discussion of this topic, see Appendix B, item
10.
TC-6.2 A SINGLE TCB SUBSET
The evaluation of a TCB consisting of a
single TCB subset is equivalent to a straightforward
evaluation against the TCSEC. The conditions for
evaluation by parts (Section TC-4.3) reduce to
requirements found in the TCSEC itself.
TC-6.2.1 ANALYSIS OF THE CONDITIONS
TC-6.2.1.1 Condition 1: Candidate TCB
Subsets
The TCB (hardware, software, and firmware),
as distinguished from the rest of the computing system,
must be identified. This is a basic requirement for
TCSEC evaluation. Similarly, the subjects and objects
within the system must be identified. The requirement
that no more than one TCB subset mediate access to any
particular object is satisfied, because there is only
one TCB subset.
TC-6.2.1.2 Condition 2: Policy Allocation
The policy P enforced by the TCB (subset)
must be identified. The demonstration that the TCB
(subset) enforces that policy will be a description of
how the TCB performs access mediation between the
system's subjects and objects according a system-level
description of limitations on access (the technical
policy P[i] of the definition). The tracing of the
policy to the system design and behavior is part of the
stated TCSEC requirements.
?TC-6.2.1.3 Condition 3: Trusted Subjects
Included
This condition is satisfied in the same
manner as it is in evaluations under the TCSEC.
Specifically, the TCB boundary is shown to be the
interface that is presented to untrusted subjects.
TC-6.2.1.4 Condition 4: TCB Subset Structure
Satisfaction of this condition (TC-4.3.4) is
immediate, because there is only one TCB subset.
TC-6.2.1.5 Condition 5: Separate
Subset-Domains
Satisfaction of the separate subset-domain
condition (TC-4.3.5) is identical to the C1 through A1
requirement that "the TCB maintain a domain for its own
execution that protects it from external interference
or tampering." [8, p. 13 et al.]
TC-6.2.1.6 Condition 6: Support for RVM
Arguments
Satisfaction of this condition (TC-4.3.6) is
immediate, inasmuch as there are no less primitive TCB
subsets that must be demonstrated to satisfy RVM
requirements.
TC-6.2.2 EVALUATION CONSEQUENCES
In this case, the evaluation of the (single)
TCB subset proceeds exactly like an evaluation under
the TCSEC. Demonstration that the candidate system
meets all the global and local requirements (as they
apply to the target evaluation class) includes the
consideration of each requirement as it applies
system's philosophy of protection, design,
documentation, and implementation. The system must be
shown to exhibit the properties of a reference
validation mechanism, appropriate to the target class.
TC-6.3 TWO TCB SUBSETS, MEETING THE CONDITIONS
This case is of a TCB that consists of two
candidate TCB subsets, A and B, where A is the most
primitive TCB subset. That is, B uses the abstractions
provided by A (the objects, in particular) as its
resource for the construction and exportation of its
own abstractions. B also uses the abstractions
provided by A for its metadata (that is, internal data
structures) that make it possible for B to instantiate
its exported abstractions as well as keep records that
enable it to correctly enforce its stated policy. In
terms of the discussion of Section TC-4.3.4, TCB subset
B directly depends on TCB subset A. It will be assumed
that TCB subset A enforces mandatory and discretionary
policies on its objects and that TCB subset B enforces
a discretionary policy on the objects it exports.
Additionally, all trusted subjects of A are contained
within A. Thus, every subject of A (including all the
active entities that make up the logic of B) operates
at a single sensitivity level. It will further be
assumed for th is example that the mechanisms for
domains and thus for subset-domains are independent of
the mandatory and discretionary access control policy
enforcement mechanisms.
TC-6.3.1 ANALYSIS OF THE CONDITIONS
TC-6.3.1.1 Condition 1: Candidate TCB
Subsets
The TCB (hardware, software, and firmware),
as distinguished from the rest of the computing system,
must be identified. This is a basic requirement for
TCSEC evaluation. Similarly, the subjects and objects
within the system must be identified.
In this case, all the hardware, software, and
firmware that make up the TCB must be identified as
being part of either TCB subset A or TCB subset B. The
subjects and objects mediated by A (call them the
"A-subjects" and "A-objects" for this discussion) must
be identified. Similarly the B-subjects and B-objects
must also be identified.
The additional requirement in Section
TC-4.3.1 that "there may not be any objects mediated by
more than one TCB subset" means that there can be no
B-object that is also an A-object.
TC-6.3.1.2 Condition 2: Policy Allocation
The policy P enforced by the whole TCB must
be identified. In addition, the policy enforced by A
(call it the A-policy), stated in terms of the
A-subjects and the A-objects, must be identified.
Similarly, the B-policy, stated in terms of the
B-subjects and the B-objects, must be identified.
TC-6.3.1.3 Condition 3: Trusted Subjects
Included
As was stated above, TCB Subset A contains
all its own trusted subjects. There may be trusted
subjects with respect to the policy of A, but all such
subjects execute in the subset-domain of A.
TC-6.3.1.4 Condition 4: TCB Subset Structure
Because B directly uses the A-objects and its
logic is embodied in A-subjects, the structure of the
TCB subsets is precisely "TCB subset A is more
primitive than TCB subset B." This is a partial order.
TC-6.3.1.5 Condition 5: Separate
Subset-Domains
Satisfaction of the separate subset-domain
condition requires that a set of domains provided by
the system be identified as being the domains
"occupied" by A and B. The domain, or domains,
occupied by A is exactly the "domain for its own
execution" found in the TCSEC requirements. The domain
or domains occupied by TCB subset B must not be
modifiable by any code or other system entity except
possibly by TCB subset A.
TC-6.3.1.6 Condition 6: Support for RVM
Arguments
Satisfying the condition for RVM arguments
requires demonstrating the plausibility of being able
to establish the three requisite properties of an RVM.
The first property requires that no B-subject be
allowed to access B-objects without those accesses
being mediated by TCB subset B. The tamper resistance
property requires that TCB subset A provide a way that
TCB subset B can be designed and implemented such that
A-subjects that are not part of B's implementation
cannot tamper with B's policy-critical code or data.
The third RVM property must be satisfied by the
individual TCB subsets. The degree to which each TCB
subset must satisfy this property is commensurate with
the evaluation class of the TCB.
TC-6.3.2 EVALUATION CONSEQUENCES
In this case, the evaluation of the two TCB
subsets requires that each meet TCSEC requirements
applicable to each TCB subset viewed individually and
that the two TCB subsets combine in a way to meet all
the TCSEC requirements stated for the target class.
All local requirements are imposed on the two
TCB subsets, A and B, individually. If each TCB subset
can meet the requirements of the target class, viewed
as if it were a separate TCB, the only areas where
additional evaluation or accreditation work might be
required are those areas where the sum of the analysis
of the parts is not necessarily complete and
convincing. Those areas requiring additional work are
exactly the set of global requirements described in
Section TC-5.3.2.
Demonstrating that the candidate system meets
the TCSEC requirements (as they apply to the target
evaluation class) requires that both A and B be
evaluated with respect to the local requirements of the
target class and that the composite TCB be evaluated
for global requirements. In this case, full testing of
TCB subset A against all the requirements (both local
and global) simplifies the task of demonstrating
satisfaction of the global requirements, both for B and
for the entire TCB.
Suppose, for example, that TCB subset A has
been subjected to security testing appropriate to the
target class and has been shown to be adequately
resistant to penetration attacks. This means that
within the confidence level provided by the testing
requirement, no A-subject can subvert A's enforcement
of its policy. In this situation, every active entity
in B is an A-subject and hence B can neither penetrate
A nor be induced to do so by any B-subject. Thus, no
further testing of A will be required to determine
whether the entire TCB is resistant to penetration; any
additional penetration testing can be limited to
determining the ability of B to withstand assault.
Similarly, if A has been searched for covert
channels (as required for its target class
requirements), then no further search for covert
channels will be required, either in the analysis of B
or in the overall consideration of the entire TCB.
Note that if B implements a mandatory access control
policy (e.g., integrity), then it would be necessary to
perform a covert channel analysis on B, but no further
covert channel analysis of A would be required.
The ability of users to determine the current
sensitivity level of B-subjects operating on their
behalf will have to be shown by considering the TCB
subsets A and B together. This requirement is
satisfied immediately if the argument relies
exclusively on A meeting the requirement.
TC-6.4 TWO TCB SUBSETS, NOT MEETING THE
CONDITIONS
This case also concerns a TCB that consists
of two candidate TCB subsets, C and D. C is the most
primitive TCB subset. That is, D uses the abstractions
provided by C (the objects, in particular) as its
resource for the construction and exportation of its
own abstractions. D also uses the abstractions
provided by C for its metadata (that is, internal data
structures) that make it possible for D to instantiate
its exported abstractions as well as keep records that
enable it to correctly enforce its stated policy. In
terms of the discussion of Section TC-4.3.4, TCB subset
D directly depends on TCB subset C. Additionally, D is
trusted with respect to C. That is, some of the
C-subjects which make up TCB subset D execute as
trusted processes of C. Here also, as in the previous
example, it is assumed that C implements mandatory and
discretionary policies over its objects. Further, the
intent of D is to implement a discretionary policy over
the objects it exports. However, because D includes
subjects which are trusted relative to C's policy
demonstration of the full and correct enforcement of
the mandatory policy requires analysis of both C and D
and is no longer localized to TCB subset C. It will be
assumed that the mechanisms for domains and thus for
subset-domains are independent of the mandatory and
discretionary access control policy enforcement
mechanisms.
This case can be viewed as a special case of
a previously evaluated TCB which has been altered.
However, the alteration takes the form of a less
primitive subset which is implemented, at least in
part, with trusted subjects (i.e., some of the
C-subjects are trusted subjects which execute in the
subset-domain of D). Although this case may appear,
intuitively, to be different from that of arbitrary
alteration of a previously evaluated TCB, the example
demonstrates that such an approach makes it impossible
to perform an evaluation by parts.
TC-6.4.1 ANALYSIS OF THE CONDITIONS
TC-6.4.1.1 Condition 1: Candidate TCB
Subsets
The identification of the TCB (hardware,
software, and firmware) as distinguished from the rest
of the computing system is a basic requirement for
TCSEC evaluation. Likewise, the subjects and objects
within the system must be identified.
In this case, all the hardware, software, and
firmware that make up the TCB must be identified as
being part of either TCB subset C or TCB subset D. The
C-subjects and C-objects mediated by C have to be
identified. Similarly the D-subjects and D-objects
must also be identified.
The additional requirement in Section
TC-4.3.1 that "there may not be any objects mediated by
more than one TCB subset" means there can be no
D-object that is also a C-object.
TC-6.4.1.2 Condition 2: Policy Allocation
The policy P enforced by the whole TCB must
be identified. In addition, the individual policy
enforced by C (call it the C-policy) must be identified
in terms of the C-subjects and the C-objects.
Similarly, the D-policy, stated in terms of the
D-subjects and the D-objects, must be stated. In this
case, the C-policy will include the strict enforcement
of a mandatory access control policy that allows
trusted subjects to execute in the subset-domains which
compose TCB subset D.
TC-6.4.1.3 Condition 3: Trusted Subjects
Included
This condition is not satisfied because D
includes at least one subject that is trusted with
respect to C. Hence a subject that is trusted with
respect to the policy of C is outside C, and evaluation
by parts is not an option. If TCB subset C had
previously been evaluated, then this is an example of
an altered TCB, albeit a special case. The change
consists of the addition of one or more trusted
C-subjects in D whose effect on the behavior of C
cannot be predicted a priori. An assessment of the
impact of D on the behavior of C cannot be made
strictly by an examination of the trusted subjects and
the definition of C's interface. A global assessment
of C and D is required.
TC-6.4.1.4 Condition 4: TCB Subset Structure
Because D directly uses the C-objects and its
logic is embodied in C-subjects, the structure of the
TCB subsets is precisely "TCB subset C is more
primitive than TCB subset D." This is a partial order.
TC-6.4.1.5 Condition 5: Separate
Subset-Domains
Satisfying the separate subset-domain
condition (TC-4.3.5) requires identifying the set of
system domains (likely administered by the most
primitive TCB subset C) as the domains "occupied" by C
and D. The domain, or domains, occupied by C is
exactly the "domain for its own execution" found in the
TCSEC requirements. The domain or domains occupied by
TCB subset D must not be modifiable by any code or
other system entity except possibly by a part of TCB
subset C.
TC-6.4.1.6 Condition 6: Support for RVM
Arguments
Satisfying the condition for RVM arguments
requires demonstrating the plausibility of being able
to establish the three requisite properties of an RVM.
The first property requires that no B-subject be
allowed to access B-objects without those accesses
being mediated by TCB subset B. The tamper resistance
property requires that TCB subset A provide a way that
TCB subset B can be designed and implemented such that
A-subjects that are not part of B's implementation
cannot tamper with B's policy-critical code or data.
The third RVM property must be satisfied by the
individual TCB subsets. The degree to which each TCB
subset must satisfy this property is commensurate with
the evaluation class of the TCB.
TC-6.4.2 EVALUATION CONSEQUENCES
In this example, the conditions for
evaluation by parts are not satisfied and thus, the
full potential for savings in evaluation effort cannot,
in general, be realized. A clear option in such cases
is to view the system as a monolithic TCB and proceed
accordingly. However, because this case represents an
example of an altered TCB, it admits of a wide spectrum
of specific sub-cases. Thus, if the analysis of the
system proceeds in parallel to that required for
evaluation by parts it may be possible, in special
cases, to identify elements of the analysis of the more
primitive candidate TCB subset which can be
successfully argued to be unaffected by the
alterations. Some evaluation effort, often
significant, can be saved, but unlike evaluation by
parts, how much can only be estimated by consideration
of the implementation specifics. For example, in this
specific case, the local analysis of TCB subset C
represents a reasonable candidate for analysis that
need not be redone.
TC-6.5 SUMMARY
The three cases described above illustrate
the effects of various TCB subsetting situations as
they relate to the evaluation requirements.
A monolithic evaluation proceeds exactly as
described in the TCSEC, with requirements being applied
to the entire TCB.
When all the conditions for evaluation by
parts are satisfied, considerable savings in evaluation
effort are realized. The evaluation of a new system
configuration that includes exactly the same TCB subset
that was previously evaluated (such as the TCB subsets
A and B in the Section TC-6.3) is limited to (a) local
analysis of the individual TCB subsets (by reference to
earlier analysis, if available) and (b) a simpler
global analysis, because each TCB subset is an exact
analog of a TCB.
When the conditions for evaluation by parts
are not satisfied, no general statements can be made
about the factorability of analysis or the reusability
of previous analysis. The extent to which previous
evaluation evidence and results remain valid can be
determined only on a case-by-case basis.
PART 2
INTERPRETED REQUIREMENTS
IR-1 OVERVIEW AND CONTEXT
Part 2, "INTERPRETED REQUIREMENTS," provides
specific interpretations of those TCSEC requirements
which are deemed to be either DBMS-specific (or, more
generally, application-specific) or particularly
relevant to DBMSs. All of the requirements in the
TCSEC apply in any case.
For the topics included below, the
interpretations provide clarification of the TCSEC
requirements. As is the case for the TCSEC, the
interpreted requirements at any class include those
specified for that class in addition to interpretations
for lower classes that have not been superseded or
altered.
Section IR-2 presents an overall summary of
the TCSEC requirements, as interpreted in the more
detailed sections that follow. Sections IR-3 through
IR-7 address individual requirements interpretations
for labels, audit, system architecture, design
specification and verification, and design
documentation, respectively. The format is an initial
discussion of the topic in general, followed by
specific requirements and interpretations that apply to
database management systems. A listing of the
requirements and interpretations organized by TCSEC
class is presented in Appendix A.
IR-2 SUMMARY OF THE INTERPRETATIONS
This section provides specific
interpretations of those TCSEC requirements that are
particularly relevant for subsetted architectures and
evaluation by parts. Its organization is derived from
the structure of the TCSEC requirements. For each
relevant TCSEC requirement there is a discussion of how
that requirement is interpreted for a DBMS.
IR-2.1 SECURITY POLICY
IR-2.1.1 DISCRETIONARY ACCESS CONTROL
The requirement for discretionary access
control is not changed in the context of this document
and therefore applies as stated in the TCSEC.
IR-2.1.2 OBJECT REUSE
The requirement for object reuse is not
changed in the context of this document and therefore
applies as stated in the TCSEC.
IR-2.1.3 LABELS
The requirement for labels is treated in
Section IR-3 of this document.
IR-2.1.4 MANDATORY ACCESS CONTROL
The requirement for mandatory access control
is not changed in the context of this document and
therefore applies as stated in the TCSEC. However,
there are several subtle ramifications of this
requirement of which a developer or evaluator should be
aware. A brief discussion can be found in Appendix B,
item 8, "Content-Dependent and Context-Dependent Access
Control."
IR-2.2 ACCOUNTABILITY
IR-2.2.1 IDENTIFICATION AND AUTHENTICATION
The requirement for identification and
authentication is not changed in the context of this
document and therefore applies as stated in the TCSEC.
IR-2.2.2 AUDIT
The requirement for audit is treated in
Section IR-4 of this document.
IR-2.3 ASSURANCE
IR-2.3.1 OPERATIONAL ASSURANCE
IR-2.3.1.1 System Architecture
The requirement for system architecture is
treated in Section IR-5 of this document.
IR-2.3.1.2 System Integrity
The requirement for system integrity is not
changed in the context of this document and therefore
applies as stated in the TCSEC.
IR-2.3.1.3 Covert Channel Analysis
The requirement for covert channel analysis
is not changed in the context of this document and
therefore applies as stated in the TCSEC.
IR-2.3.1.4 Trusted Facility Management
The requirement for trusted facility
management is not changed in the context of this
document and therefore applies as stated in the TCSEC.
IR-2.3.1.5 Trusted Recovery
The requirement for trusted recovery is not
changed in the context of this document and therefore
applies as stated in the TCSEC.
IR-2.3.2 LIFE CYCLE ASSURANCE
IR-2.3.2.1 Security Testing
The requirement for security testing is not
changed in the context of this document and therefore
applies as stated in the TCSEC.
IR-2.3.2.2 Design Specification and
Verification
The requirement for design specification and
verification is treated in Section IR-6 of this
document.
IR-2.3.2.3 Configuration Management
The requirement for configuration management
is not changed in the context of this document and
therefore applies as stated in the TCSEC.
IR-2.3.2.4 Trusted Distribution
The requirement for trusted distribution is
not changed in the context of this document and
therefore applies as stated in the TCSEC.
IR-2.4 DOCUMENTATION
IR-2.4.1 SECURITY FEATURES USER'S GUIDE
The requirement for a security features
user's guide is not changed in the context of this
document and therefore applies as stated in the TCSEC.
IR-2.4.2 TRUSTED FACILITY MANUAL
The requirement for a trusted facility manual
is not changed in the context of this document and
therefore applies as stated in the TCSEC.
IR-2.4.3 TEST DOCUMENTATION
The requirement for test documentation is not
changed in the context of this document and therefore
applies as stated in the TCSEC.
IR-2.4.4 DESIGN DOCUMENTATION
The requirement for design documentation is
treated in Section IR-7 of this document.
IR-3 LABELS
IR-3.1 GENERAL DISCUSSION
The labels requirements of the TCSEC are
entirely applicable to database management systems.
The basic difference between the TCSEC labeling
requirements as they apply to operating systems and
DBMSs involves which storage objects are labeled rather
than how the labels are handled. This section
discusses special considerations in implementing and
evaluating labeling mechanisms in database management
systems. Of particular importance is the selection of
the storage objects that are to be labeled.
Beginning at the B1 evaluation class, trusted
database management systems are required to associate
labels with all storage objects under their control.
The granularity of storage objects to be protected
shall be chosen by the DBMS designer.
Stored view definitions (that is, named query
commands) that are visible at the TCB boundary must be
stored in labeled objects. The TCB must mediate access
both to the view definition and to the view
instantiation (that is, the set of labeled objects
accessed as the result of executing the query command
contained in the view definition).
It has been proposed in several designs that
views be used as a mechanism to implement context- or
content-dependent labeling. The intuitive
attractiveness of this approach is undeniable, but the
implementation details must be carefully worked out to
achieve a sound implementation. A brief discussion of
this topic can be found in Appendix B, item 8,
"Content-Dependent and Context-Dependent Access
Control."
TCB designers and evaluators may make
distinctions between objects that are explicitly
labeled or implicitly labeled. Such distinctions are
meaningful only within the confines of the TCB; all
storage objects are explicitly labeled from a point of
view outside the TCB. For example, consider an object
of one type (e.g., table or file) within the TCB that
"contains" many (reference monitor) objects of another
type (e.g., tuples and records). The file could have
an explicit label associated with it, and some of the
records could have explicit labels associated with
them. Those records that have no explicit label would
be implicitly labeled by the label of the file.
For database management systems, the objects
that store the base data of the database (e.g., files,
records, relations, and tuples), as well as those
objects that store the metadata (e.g., directories,
indices, schemas, data dictionaries, discretionary
authorization tables, recovery logs, and transaction
logs), must be labeled. Objects that need not be
labeled include internal resources that are not user
visible (e.g., printer daemon scratch files and
resource allocation tables). The requirement for
importing data (labeled and unlabeled) is the same as
in the TCSEC. For additional information, see Appendix
B, item 9, "Bulk Loading of a Database."
IR-3.2 SPECIFIC INTERPRETATIONS
CLASS (B1): LABELED SECURITY PROTECTION
There are no interpretations for this class.
CLASS (B2): STRUCTURED PROTECTION
Statement from TCSEC
Sensitivity labels associated with each ADP
system resource . . . that is directly or indirectly
accessible by subjects external to the TCB shall be
maintained by the TCB.
Interpretation
Internal TCB variables that are not visible
to untrusted subjects need not be labeled, provided
that they are not directly or indirectly accessible by
subjects external to the TCB. However, it is important
to understand that such internal variables can function
as covert signaling channels when untrusted subjects
are able to detect changes in these variables by
observing system behavior.
CLASS (B3): SECURITY DOMAINS
There are no additional requirements.
CLASS (A1): VERIFIED DESIGN
There are no additional requirements.
IR-4 AUDIT
IR-4.1 GENERAL DISCUSSION
The audit requirements of the TCSEC apply to
database management systems. This section discusses
special considerations in designing and evaluating
audit mechanisms in database management systems.
The TCB must be capable of maintaining an
audit trail of accesses and attempted accesses to the
objects protected by the mandatory and discretionary
security policies. Two examples are given to
illustrate auditing techniques for discretionary access
control decisions.
Example 1. Consider a DBMS TCB providing discretionary
controls on defined views of the database. Because the
named object presented at the TCB interface is the view
definition (not the records instantiated through the
view), all that needs to be auditable is the use of the
view by any untrusted subject.
Example 2. Consider a DBMS TCB that enforces
discretionary access control on individual data
records. When a user enters a query, the construction
of a response may involve a search over many records
that are not returned to the user because they did not
satisfy the query. Records that do satisfy the query
but to which the user does not have access should be
auditable. Records that do not satisfy the query need
not be auditable. That is, in the context of audit,
access permission to the user and satisfaction of a
query are to be kept separate.
There is no need to audit operations that are
strictly internal to the TCB. Separate security audit
logs may be maintained by the operating system and the
database management system. Likewise, separate
identifications for the same user may be maintained by
the operating system and the database management
system. The correlation of separate audit logs may be
done either at the time they are generated or at some
later time.
The emphasis of the audit criterion is to
provide individual accountability for actions by users.
This goal is not the same as that for a backup and
recovery log. There is no requirement to integrate the
audit log with the backup and recovery log, although
such an integrated log is not prohibited.
At the designer's discretion, there may be a
selectable capability to reduce the number of audit
records generated in response to queries that involve
many access control decisions.
IR-4.2 SPECIFIC INTERPRETATIONS
CLASS (C2): CONTROLLED ACCESS PROTECTION
Statement from TCSEC
The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of accesses to the objects it protects.
Interpretation
Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of
the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to users. That is, each
discretionary access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.
CLASS (B1): LABELED SECURITY PROTECTION
Statement from TCSEC
The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of accesses to the objects it protects.
Interpretation
Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of
the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to the user. That is, each
discretionary access control policy decision and each
mandatory access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.
CLASS (B2): STRUCTURED PROTECTION
There is no interpretation for the additional
requirements.
CLASS (B3): SECURITY DOMAINS
There is no interpretation for the additional
requirements.
CLASS (A1): VERIFIED DESIGN
There are no additional requirements.
IR-5 SYSTEM ARCHITECTURE
IR-5.1 GENERAL DISCUSSION
The system architecture requirements of the
TCSEC apply to database management systems.
The interpretations provided are a
duplication of the general interpreted requirements
that apply to an evaluation by parts. They are
included because DBMS evaluations often involve
multiple TCB subsets.
IR-5.2 SPECIFIC INTERPRETATIONS
CLASS (C1): DISCRETIONARY SECURITY
PROTECTION
Statement from TCSEC
The TCB shall maintain a domain for its own
execution that protects it from external interference
or tampering.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement applies to each TCB subset.
CLASS (C2): CONTROLLED ACCESS PROTECTION
There is no interpretation for the additional
requirements.
CLASS (B1): LABELED SECURITY PROTECTION
There is no interpretation for the additional
requirements.
CLASS (B2): STRUCTURED PROTECTION
Statement from TCSEC
The user interface to the TCB shall be
completely defined and all elements of the TCB
identified.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to the interface between the
TCB subsets as well as the user interface to the whole
TCB.
Statement from TCSEC
It shall make effective use of available
hardware to separate those elements that are
protection-critical from those that are not.
Interpretation
If the TCB is composed of multiple subsets,
each TCB subset must make use of facilities provided to
it by more primitive TCB subsets, such as support for
execution domains and for distinct address spaces, to
achieve the required separation.
CLASS (B3): SECURITY DOMAINS
There is no interpretation for the additional
requirements.
CLASS (A1): VERIFIED DESIGN
There are no additional requirements.
IR-6 DESIGN SPECIFICATION AND VERIFICATION
IR-6.1 GENERAL DISCUSSION
The design specification and verification
requirements of the TCSEC, with the related
documentation requirements, apply to database
management systems.
The interpretations provided include a
duplication of general interpreted requirements that
apply to an evaluation by parts. They are included
because of the likelihood that a DBMS evaluation will
involve multiple TCB subsets.
In the database context, the set of
candidates for "subject" and "object" can be larger
than normally encountered in trusted operating systems.
Where a database system builds on an underlying trusted
operating system, for example, the set of candidate
subjects for the two TCB subsets includes both the
active entities created by the operating system and
those active entities created by the trusted portion of
the DBMS. The set of candidates for objects is large.
Examples are files, segments, buffers, structures,
pages, relations, tables, tuples, rows, columns,
elements, entities, relationships, procedures,
metadata, system tables, query trees, query plans,
locking mechanisms, rollback mechanisms, indices,
recovery and backup mechanisms, precalculated
operations (such as joins), view definitions, view
instantiations, constraints, authorization tables, data
dictionary tables, and audit logs.
The requirements in the TCSEC for showing how
the various representations of the system being
evaluated fit together can be represented as in Figure
IR-1. For monolithic TCBs, the policy must be stated;
the model must be developed, maintained, and shown to
be sufficient to enforce the policy; and the DTLS (FTLS
for A1) must be constructed and shown to correspond
both to the model and to the TCB implementation. These
steps allow a chain of reasoning to proceed from the
stated policy to the assertion that the system in
question actually enforces the policy.
In the case of multiple TCB subsets, the
intent is the same. Tracing all policy requirements to
the actual system implementation must be possible, and
vice versa. The current dilemma is that the theory and
techniques for subdividing a model into a set of models
(or a top level specification into a set of top level
specifications) have not yet been established.
Likewise neither theory or techniques have been
established for composing a set of models or top level
specifications into a unified model or top level
specification. The absence of rigorous methods does
not preclude an evaluation using a subsetted TCB.
The process of mapping policy to
implementation is possible for each TCB subset, using
the same techniques required for a monolithic TCB. For
subsetted TCBs, designers and evaluators must
explicitly show how the policy, model and
specifications for each TCB subset meet the TCSEC
requirements. In addition, convincing informal
arguments must be given to show how the collection of
TCB subsets enforces the policy of the composite TCB.
Because more rigorous composition methods are
unavailable, convincing informal arguments are
appropriate for evaluation of TCBs up to and including
Class A1.
The TCSEC requirements concerning the mapping
from policy to implementation for a TCB composed of
multiple TCB subsets raise these crucial topics:
The allocation of policy to the TCB
subsets,
The relation of the models for the TCB
subsets to the overall system policy, and
The relation of the top level
specification for each TCB subset to the entire system.
Allocation of policy to the TCB subsets is a
precise division of the policy for the entire system,
as addressed in the policy allocation condition of
Section TC-4.3.
The second topic, above, requires that the
policy for each TCB subset be stated. Additionally, it
is required that there be an informal convincing
argument that the collection of models represents the
policy enforced by the entire system.
The third topic, the way in which the set of
top level specifications for the individual TCB subsets
describes the composite TCB interface with respect to
exceptions, errors and effects, is treated in a similar
fashion. The top level specifications for each TCB
subset must meet the requirement. There is, in
addition, a requirement for an informal, convincing
description of how the set of top level specifications
describes the TCB interface with respect to exceptions,
errors, and effects. At the A1 level, there is no
requirement for additional formal specification or
formal proofs beyond the specification and proofs
specific to the individual TCB subsets.
Rather than formally composing the policies,
models, and specifications and performing a single
monolithic evaluation, a series of separate evaluations
may be performed (one for each TCB subset). The
evaluations are then tied together by presentation of
sufficient informal arguments that the individual
policies collectively represent the policy enforced by
the entire system, that the individual models
collectively represent the system's policy, that the
individual specifications represent the TCB interface,
and that the source code of each TCB subset is
consistent with its top level specification.
Note that satisfactory completion of these
requirements is logically equivalent to demonstrating
that a "unified" model for the entire TCB is consistent
with the policy enforced by the system, that a
"unified" top level specification corresponds to the
model, and that the "unified" top level
specification(s) corresponds to the source code. These
interpreted requirements, which do not mandate a
"unified" top level specification, are technically
achievable interpretations of the policy-tracing
requirements in the case of multiple TCB subsets.
IR-6.2 SPECIFIC INTERPRETATIONS
CLASS (B1): LABELED SECURITY PROTECTION
Statement from TCSEC
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.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement applies to the security
policy of each TCB subset. An informal argument that
the set of policy models represents the "security
policy supported by the [composite] TCB" must be
provided.
CLASS (B2): STRUCTURED PROTECTION
Statement from TCSEC
A 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.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement applies to the security
policy of each TCB subset. An informal argument that
the set of policy models represents the "security
policy supported by the [composite] TCB" must be
provided.
Statement from TCSEC
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.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement applies to the DTLS of each
TCB subset. An informal argument that the set of DTLSs
accurately describes the TCB must be provided.
If there is a multifaceted policy (e.g., both
mandatory access control and discretionary access
control policies) in a particular TCB subset, then all
facets must be represented in the DTLS and in the TCB
subset's model.
Statement from TCSEC
The descriptive top-level specification
(DTLS) shall be shown to be an accurate description of
the TCB interface.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to the interface between the
TCB subsets as well as to the user interface of the
composite TCB. The TCB interface description shall
include an explanation of how to describe the total TCB
accurately, in the context of the multiple TCB subset
DTLSs.
CLASS (B3): SECURITY DOMAINS
Statement from TCSEC
A convincing argument shall be given that the
DTLS is consistent with the model.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement applies to individual TCB
subsets. Enforcement of all policies must be shown to
occur in all situations (e.g., state transitions)
required by the formal security policy model. In the
case of a discretionary access control policy, the
presence of the access control check at all identified
state transitions is the total of what is required for
demonstrating consistency between the DTLS and the
model. This may be verified by inspection of the DTLS
(that is, by visually checking that exception checks
required by the model are present in the DTLS). For
the mandatory access control policy, the DTLS must be
shown by a convincing argument to be consistent with
the model.
CLASS (A1): VERIFIED DESIGN
Statement from TCSEC
A formal top-level specification (FTLS) of
the TCB shall be maintained that accurately describes
the TCB in terms of exceptions, error messages, and
effects.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement applies to the FTLS of each
TCB subset. An informal argument that the set of FTLSs
accurately describes the TCB must be provided.
If there is a multifaceted policy (e.g., both
mandatory access control and discretionary access
control policies) in a particular TCB subset, then all
facets must be represented in the FTLS and in the TCB
subset's model.
Statement from TCSEC
The FTLS shall be shown to be an accurate
description of the TCB interface.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to the interface between the
TCB subsets as well as to the user interface of the
composite TCB. The TCB interface description shall
include an explanation of how to describe the total TCB
accurately, in the context of the multiple TCB subset
DTLSs.
Statement from TCSEC
. . . a combination of formal and informal
techniques shall be used to show that the FTLS is
consistent with the model.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement applies to individual TCB
subsets. Enforcement of all policies must be shown to
occur in all situations (e.g., state transitions)
required by the formal security policy model at the
required occasions. In the case of a discretionary
access control policy, the presence of the access
control check at all identified state transitions is
the total of what is required for demonstrating
consistency between the FTLS and the model. This may
be verified by inspection of the FTLS (that is, by
visually checking that exception checks required by the
model are present in the FTLS). For the mandatory
access control policy, the FTLS must be shown by a
combination of formal and informal techniques to be
consistent with the model.
IR-7 DESIGN DOCUMENTATION
IR-7.1 GENERAL DISCUSSION
The design documentation requirement of the
TCSEC applies to database management systems.
The interpretations