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 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-7.2 SPECIFIC INTERPRETATIONS
CLASS (C1): DISCRETIONARY SECURITY PROTECTION
Statement from TCSEC
If the TCB is composed of distinct modules,
the interfaces between these modules shall be
described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.
CLASS (C2): CONTROLLED ACCESS PROTECTION
There are no additional requirements.
CLASS (B1): LABELED SECURITY PROTECTION
Statement from TCSEC
The specific TCB protection mechanisms shall
be identified and an explanation given to show that
they satisfy the model.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and shall
include the protection mechanisms which support the
conditions for TCB subset structure and separate
subset-domains.
CLASS (B2): STRUCTURED PROTECTION
Statement from TCSEC
The interfaces between the TCB modules shall
be described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between different TCB subsets.
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.
Statement from TCSEC
Documentation shall describe how the TCB
implements the reference monitor concept and give an
explanation of why it is tamper resistant, cannot be
bypassed, and is correctly implemented.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
each TCB subset with respect to its specific technical
policy. In addition, there must be documented an
informal argument that the cooperative action of the
TCB subsets makes the TCB itself tamper resistant,
non-bypassable, and correct.
Statement from TCSEC
Documentation shall describe how the TCB is
structured to facilitate testing and to enforce least
privilege.
Interpretation
If the TCB is composed of multiple subsets,
this requirement is interpreted to apply to individual
TCB subsets as well as to the overall TCB.
CLASS (B3): SECURITY DOMAINS
Statement from TCSEC
The TCB implementation shall be informally
shown to be consistent with the DTLS.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
individual TCB subsets.
CLASS (A1): VERIFIED DESIGN
Statement from TCSEC
The TCB implementation shall be informally
shown to be consistent with the FTLS.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
individual TCB subsets.
APPENDIX A
SUMMARY OF THE
INTERPRETATIONS BY CLASS
This section is a presentation of all the
interpreted requirements organized by TCSEC class. It
includes all the requirements which are either relevant
to subsetted architectures or are DBMS-specific. Any
TCSEC requirements not explicitly identified herein
apply as stated in the TCSEC.
CLASS (C1): DISCRETIONARY SECURITY PROTECTION
C1-1 SECURITY POLICY
C1-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.
C1-2 ACCOUNTABILITY
C1-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. 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.
C1-3 ASSURANCE
C1-3.1 OPERATIONAL ASSURANCE
C1-3.1.1 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.
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.
C1-3.1.2 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.
C1-3.2 LIFE CYCLE ASSURANCE
C1-3.2.1 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).
C1-4 DOCUMENTATION
C1-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.
C1-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.
C1-4.3 TEST DOCUMENTATION
This requirement applies as stated in the TCSEC to the
composite TCB.
C1-4.4 DESIGN DOCUMENTATION
This requirement applies as stated in the TCSEC to the
composite TCB.
Statement from TCSEC
If the TCB is composed of distinct modules,
the interfaces between these modules shall be
described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.
CLASS (C2): CONTROLLED ACCESS PROTECTION
C2-1 SECURITY POLICY
C2-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.
C2-1.2 OBJECT REUSE
This requirement applies as stated in the TCSEC to
every TCB subset in the TCB.
C2-2 ACCOUNTABILITY
C2-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. 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.
C2-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.
Statement from TCSEC
The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of access 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.
C2-3 ASSURANCE
C2-3.1 OPERATIONAL ASSURANCE
C2-3.1.1 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.
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.
C2-3.1.2 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.
C2-3.2 LIFE CYCLE ASSURANCE
C2-3.2.1 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).
C2-4 DOCUMENTATION
C2-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.
C2-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.
C2-4.3 TEST DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB.
C2-4.4 DESIGN DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB.
Statement from TCSEC
If the TCB is composed of distinct modules,
the interface between these modules shall be described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.
CLASS (B1): LABELED SECURITY PROTECTION
B1-1 SECURITY POLICY
B1-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.
B1-1.2 OBJECT REUSE
This requirement applies as stated in the
TCSEC to every TCB subset in the TCB.
B1-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.
B1-1.3.1 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.
B1-1.3.2 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.
B1-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.
B1-2 ACCOUNTABILITY
B1-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.
B1-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.
Statement from TCSEC
The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of access 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.
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.
B1-3 ASSURANCE
B1-3.1 OPERATIONAL ASSURANCE
B1-3.1.1 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.
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.
B1-3.1.2 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.
B1-3.1 LIFE CYCLE ASSURANCE
B1-3.2.1 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).
B1-3.2.2 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.
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.
B1-4 DOCUMENTATION
B1-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.
B1-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.
B1-4.3 TEST DOCUMENTATION
This requirement applies as stated in the TCSEC to the
composite TCB.
B1-4.4 DESIGN DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB, with the following specific
additional interpretation:
Requirements concerning models and DTLSs
apply to individual TCB subsets.
Statement from TCSEC
If the TCB is composed of distinct modules,
the interface between these modules shall be described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.
Statement from TCSEC
The specific TCB protection mechanisms shall
be identified and an explanation given to show that
they satisfy the model.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and shall
include the protection mechanisms which support the
conditions for TCB subset structure and separate
subset-domains.
CLASS (B2): STRUCTURED PROTECTION
B2-1 SECURITY POLICY
B2-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.
B2-1.2 OBJECT REUSE
This requirement applies as stated in the TCSEC to
every TCB subset in the TCB.
B2-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.
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.
B2-1.3.1 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.
B2-1.3.2 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.
B2-1.3.3 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.
B2-1.3.4 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.
B2-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.
B2-2 ACCOUNTABILITY
B2-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.
B2-2.1.1 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 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.
B2-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: (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.
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, 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.
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.
B2-3 ASSURANCE
B2-3.1 OPERATIONAL ASSURANCE
B2-3.1.1 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.
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.
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.
B2-3.1.2 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.
B2-3.1.3 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).
B2-3.1.4 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.
B2-3.2 LIFE CYCLE ASSURANCE
B2-3.2.1 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).
B2-3.2.2 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) is 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.
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.
B2-3.2.3 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.
B2-4 DOCUMENTATION
B2-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.
B2-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.
B2-4.3 TEST DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB.
B2-4.4 DESIGN DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB, with the following specific
addditional interpretations.
Requirements concerning models and DTLSs
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.
Statement from TCSEC
The interfaces between the TCB modules shall
be described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.
Statement from TCSEC
The specific TCB protection mechanisms shall
be identified and an explanation given to show that
they satisfy the model.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and shall
include the protection mechanisms which support the
conditions for TCB subset structure and separate
subset-domains.
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.
Statement from TCSEC
Documentation shall describe how the TCB
implements the reference monitor concept and give an
explanation of why it is tamper resistant, cannot be
bypassed, and is correctly implemented.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
each TCB subset with respect to its specific technical
policy. In addition, there must be documented an
informal argument that the cooperative action of the
TCB subsets makes the TCB itself tamper resistant,
non-bypassable, and correct.
Statement from TCSEC
Documentation shall describe how the TCB is
structured to facilitate testing and to enforce least
privilege.
Interpretation
If the TCB is composed of multiple subsets,
this requirement is interpreted to apply to individual
TCB subsets as well as to the overall TCB.
CLASS (B3): SECURITY DOMAINS
B3-1 SECURITY POLICY
B3-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.
B3-1.2 OBJECT REUSE
This requirement applies as stated in the TCSEC to
every TCB subset in the TCB.
B3-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.
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.
B3-1.3.1 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.
B3-1.3.2 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.
B3-1.3.3 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.
B3-1.3.4 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.
B3-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.
B3-2 ACCOUNTABILITY
B3-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.
B3-2.1.1 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.
B3-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 at
some later time.
Any TCB subset wherein events may occur that
require notification of the security administrator
shall be able to: (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.
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, 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 audited. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.
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.
B3-3 ASSURANCE
B3-3.1 OPERATIONAL ASSURANCE
B3-3.1.1 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. However,
the requirement that the TCB make effective use of
hardware requires that a less primitive TCB subset 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.
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.
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.
B3-3.1.2 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.
B3-3.1.3 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).
B3-3.1.4 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.
B3-3.1.5 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).
B3-3.2 LIFE CYCLE ASSURANCE
B3-3.2.1 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).
B3-3.2.2 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) is 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.
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.
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.
B3-3.2.3 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.
B3-4 DOCUMENTATION
B3-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.
B3-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.
B3-4.3 TEST DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB.
B3-4.4 DESIGN DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB, with the following
addtional specific interpretations.
Requirements concerning models and DTLSs
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.
Statement from TCSEC
The interfaces between the TCB modules shall
be described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.
Statement from TCSEC
The specific TCB protection mechanisms shall
be identified and an explanation given to show that
they satisfy the model.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and shall
include the protection mechanisms which support the
conditions for TCB subset structure and separate
subset-domains.
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.
Statement from TCSEC
Documentation shall describe how the TCB
implements the reference monitor concept and give an
explanation of why it is tamper resistant, cannot be
bypassed, and is correctly implemented.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
each TCB subset with respect to its specific technical
policy. In addition, there must be documented an
informal argument that the cooperative action of the
TCB subsets makes the TCB itself tamper resistant,
non-bypassable, and correct.
Statement from TCSEC
Documentation shall describe how the TCB is
structured to facilitate testing and to enforce least
privilege.
Interpretation
If the TCB is composed of multiple subsets,
this requirement is interpreted to apply to individual
TCB subsets as well as to the overall TCB.
Statement from TCSEC
The TCB implementation shall be informally
shown to be consistent with the DTLS.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
individual TCB subsets.
CLASS (A1): VERIFIED DESIGN
A1-1 SECURITY POLICY
A1-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.
A1-1.2 OBJECT REUSE
This requirement applies as stated in the TCSEC to
every TCB subset in the TCB.
A1-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.
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.
A1-1.3.1 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.
A1-1.3.2 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.
A1-1.3.3 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.
A1-1.3.4 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.
A1-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.
A1-2 ACCOUNTABILITY
A1-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.
A1-2.1.1 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.
A1-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 at
some later time.
Any TCB subset wherein events may occur that
require notification of the security administrator
shall be able to: (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.
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, 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 audited. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.
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.
A1-3 ASSURANCE
A1-3.1 OPERATIONAL ASSURANCE
A1-3.1.1 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. However,
the requirement that the TCB make effective use of
hardware requires that a less primitive TCB subset 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.
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.
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.
A1-3.1.2 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.
A1-3.1.3 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).
A1-3.1.4 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.
A1-3.1.5 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).
A1-3.2 LIFE CYCLE ASSURANCE
A1-3.2.1 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).
A1-3.2.2 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.
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
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 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.
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.
A1-3.2.3 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.
A1-3.2.4 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.
A1-4 DOCUMENTATION
A1-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.
A1-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.
A1-4.3 TEST DOCUMENTATION
This requirement applies as stated in the
TCSEC to the composite TCB.
A1-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.
Statement from TCSEC
The interfaces between the TCB modules shall
be described.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.
Statement from TCSEC
The specific TCB protection mechanisms shall
be identified and an explanation given to show that
they satisfy the model.
Interpretation
If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and shall
include the protection mechanisms which support the
conditions for TCB subset structure and separate
subset-domains.
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.
Statement from TCSEC
Documentation shall describe how the TCB
implements the reference monitor concept and give an
explanation of why it is tamper resistant, cannot be
bypassed, and is correctly implemented.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
each TCB subset with respect to its specific technical
policy. In addition, there must be documented an
informal argument that the cooperative action of the
TCB subsets makes the TCB itself tamper resistant,
non-bypassable, and correct.
Statement from TCSEC
The TCB implementation shall be informally
shown to be consistent with the DTLS.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
individual TCB subsets.
Statement from TCSEC
The TCB implementation shall be informally
shown to be consistent with the FTLS.
Interpretation
If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
individual TCB subsets.
Statement from TCSEC
Documentation shall describe how the TCB is
structured to facilitate testing and to enforce least
privilege.
Interpretation
If the TCB is composed of multiple subsets,
this requirement is interpreted to apply to individual
TCB subsets as well as to the overall TCB.
APPENDIX B
GENERAL ITEMS
1. PERSPECTIVE ON ASSURANCE
This Trusted Database Management System
Interpretation (TDI) of the Trusted Computer System
Evaluation Criteria (TCSEC) derives its perspective on
assurance directly from the reference monitor concept
as recorded in the Anderson Report [1] and as embodied
in the TCSEC. In both the reference monitor concept
and in the TCSEC, the assessment of a system for trust
characteristics involves a single, global review of the
system at issue. That same perspective of an even,
global review of a candidate trusted database
management system (DBMS) is present in the TDI, in that
only complete systems will be considered for
assessment. That is, neither software packages in
isolation nor systems that satisfy only a subset of the
TCSEC. requirements will be considered for evaluation
or accreditation. The interpretation of requirements,
both in Part 1, "Technical Context," and Part 2,
"Interpreted Requirements," is consistent with both
community experience in designing and assessing trusted
systems, and the precedents of the reference monitor
concept and the TCSEC. The interpretations, therefore,
provide special guidance for the task of evaluating (or
accrediting) candidate systems composed of
distinguishable parts. However, the interpretations
neither attenuate nor delete TCSEC requirements.
It is worth noting that the introduction of
the TCSEC with its metric for the evaluation of whole
systems had as one goal the simplification of the task
of accrediting computer systems for use in the
processing of sensitive information. The evaluation
process was not intended to replace the accreditation
process but to provide input to that process. It must
be recognized that there will be occasions when a
fielded suite of computer systems, each evaluated
against the TCSEC requirements at a particular class,
will not be able to be assigned a TCSEC class, nor is
it necessary to be able to make such an assignment.
The accreditation decision includes the assessment of
risk of a particular system configuration in a
particular environment; a decision to connect a suite
of TCSEC evaluated systems may have to be made without
a uniformly applied TCSEC-like assessment over the
entire system.
2. PROCUREMENT OPTIONS
The Trusted Computing System Evaluation
Criteria (TCSEC) and its published interpretations,
including this Trusted Database Management System
Interpretation, have as a primary purpose the
"provision [of] a basis for specifying security
requirements in acquisition specifications." [8, p.
2] In the area of trusted DBMS and trusted systems that
include database management functionality, there is a
range of options open to an acquisition organization.
These options need to be understood by the acquisition
managers and their staffs to allow them the greatest
possible flexibility in matching operational
requirements with a combination of available products
and the state of the art in system integration and
development.
The fundamental point is the distinction
between the target trust class (that is, C1, C2, B1,
B2, B3, or A1) needed for a particular installation and
the degree of trusted DBMS functionality that is
required. Succinctly, a system that requires a
particular level of trust (B2, for example) and DBMS
functionality does not necessarily require an evaluated
trusted DBMS at the level of B2. In fact, if the
statement of required capability allows it, meeting the
requirement without a trusted DBMS could well be the
preferred risk-reducing approach. This is generally
true because the more sophisticated the trusted DBMS
requirement, the more likely it is that the current
vendor base will not be able to supply the needed
functionality (with the requisite assurance) from the
normal product line. Further, even if one can specify
carefully just what additional assured capability is
needed so that a program-specific development can be
undertaken, the lack of community experience and
consensus on advanced trusted DBMS issues and
implementations introduces the potential for
significant programmatic, schedule, and cost risks.
Although a full description of options for
the acquisition manager is beyond the scope of this
document, a representative description of some of the
options that could be considered is included below.
The options include (1) multiple copies of a DBMS
running at different levels, each maintaining
single-level databases; (2) a single copy of a DBMS,
but with each database maintained at a single
sensitivity level (i.e., no sharing of data between
databases); (3) a single copy supporting single level
databases, but with limited sharing, perhaps of a
"snapshot" nature; and (4) DBMSs that allow databases
that include data of several sensitivity levels. This
option admits of subcases from the very simple to the
very complex.
To illustrate the options listed above,
consider a command post where a commander's staff uses
a single computer system. Included on the staff are
logistics, weather, and intelligence organizations,
each dealing with information of differing (maximum)
sensitivity. If all three organizations require
similar DBMS functions, there might be a variety of
ways to provide that functionality.
(1) If the product DBMS-1 suited the needs of
each of the organizations and there were no requirement
to share data between them, then three copies of DBMS-1
could be used, running at, for example, TOP SECRET,
SECRET, and CONFIDENTIAL, respectively, and maintaining
separate single-level databases. If the organizational
missions do not require multilevel operations or
sharing, this option could be perfectly suited to the
operational need. In this case, every copy of DBMS-1
would be running as an application outside the TCB and
would not have to be evaluated at all, neither as a
product nor as a developed system. The advantages of
this option are that commercial, off-the-shelf systems
can be used (both the DBMS and the underlying trusted
operating system) and no evaluation risk is entailed.
The disadvantages are the limited flexibility and the
hidden fact that the installation procedures for many
DBMSs require the insertion of code into the heart of
the underlying computer system, insertions that would
un dermine the evaluation rating and thus the
confidence in the trusted operating system.
(2) A cost advantage could be realized in the
preceding case if there were a product, DBMS-2, such
that a single copy could provide DBMS functionality at
all three levels. This capability requires that the
base trusted operating system and the DBMS itself are
designed so that the DBMS code uses scratch space to
allow the code to be shared without the potential for
mixing control or metadata in workspaces, indices, and
stacks. Not all commercial DBMSs have this property,
so this option will be less available than case (1).
Note that in this case also, the databases themselves
are single-level and the workspace used by the DBMS
itself will have to be single-level.
(3) If the operational requirements are that
the intelligence and logistics organizations must have
access to the weather data maintained by the weather
organization, the simplest technical solution would be
to periodically provide a snapshot of the needed
weather data for use by the other organizations. The
database management system DBMS-2 above could provide a
solution in this case if a portion of the weather
database could be copied onto diskette (or even into
another file) for the other organizations to
incorporate into their own DBMS operations. The
disadvantage of this approach is that the information
will not be as current as that available to the weather
organization itself. Frequently, however, that lack of
currency may be a reasonable price to pay for the
enormous reductions in cost and risk in procurement and
maintenance.
(4) If the operational requirements will not
allow anything less than real-time sharing of
information, then DBMS-2 will not be sufficient. At
this point, the operational requirements have forced
the inclusion of the most sophisticated solution to a
trusted system with DBMS requirements, a true
multilevel DBMS. In this case, it remains a valuable
goal to minimize the complexity of the needed sharing.
If the DBMS is providing a functionality that looks
like tables to the user, then it is less complex if
each table is at a single level than if each row (or
each column) could be at a different sensitivity level.
The most complex situation is when each entry in the
table could be at a different sensitivity level.
During the procurement and development process, it
would be worthwhile to structure the procurement to
favor solutions that are as simple as possible from a
multilevel trusted DBMS standpoint.
3. ALTERATION OF PREVIOUSLY EVALUATED TCB
The discussion in Part 1, "Technical Context"
arose from consideration of the conditions under which
it is possible to add an application layer, such as a
DBMS, to another TCB in such a way as to allow the
system rating to be determined by evaluating the system
elements (i.e., the subsets) separately. The benefit
to both the applications vendor and the evaluators
derives from the fact that the DBMS operates as an
untrusted subject relative to the underlying TCB (even
though the DBMS enforces its own policy). Therefore,
there is no need to re-examine previous evaluation
evidence; any and all actions performed by the
application layer are completely constrained in
accordance with the security policy defined for the
underlying TCB.
The savings in evaluation effort is
predicated on the assumption that the vendor of the
application layer makes no changes of any kind to the
other TCB. In effect, the argument made by the vendor
is as follows:
(a) The underlying TCB enforces policy P[i].
The validity of the claims about the underlying TCB has
already been established, and these claims remain valid
because the underlying TCB has not been altered in any
way and because the DBMS is completely constrained by
that policy (i.e., P[i] cannot be violated by any
action of the DBMS).
(b) The application is a TCB subset which
enforces policy P[k].
(c) Thus, the policy enforced by the
composite system (i.e., the policy enforced at the user
interface of the composite TCB) is merely a combination
of the policies of the individual TCB subsets.
Because there is neither theory nor
experience which allows one to make general, a priori
statements about the effects of arbitrary changes, any
alterations to a previously evaluated product must, in
general, be considered to result in a product whose
security attributes, and thus whose rating, is unknown.
Thus, if the previously evaluated product is altered,
argument (a) cannot be made merely by referencing the
published evaluation report. It becomes the
responsibility of the DBMS vendor to state P[i] (i.e.,
identify the policy enforced by the altered product)
and to demonstrate that the implementation satisfies
the appropriate TCSEC requirements. Hence, at least
some evaluation evidence focused on the underlying TCB
must be provided by the vendor of the application
layer. The amount of evidence required will be
determined by the type, extent, and amount of change,
as well as the characteristics of the original TCB.
This is not to say, however, that changes
always invalidate all previous evaluation evidence.
Rather, that there is no way to predict what effect
arbitrary change will have on that evidence. Clearly,
some changes will invalidate a substantial part, if not
all, of the previous evaluation results, requiring a
completely new evaluation. In some cases it will be
virtually impossible to determine the full effect of
even relatively simple changes, whereas in other
instances it may be possible to determine the effects
of at least some changes quite precisely. In a
well-modularized system, changes to the internals of a
module might be shown to have no functional or security
effect outside of the module. Even changes to the
module that alter its interface might be shown to have
effects which do not propagate beyond those modules
which have a direct interface to the altered module.
In either case however, at least some
evidence must be produced about the underlying, altered
TCB. Thus, the vendor who alters the product which is
hosting his application becomes responsible for any and
all evidence required to substantiate the claims being
made for both the application and the underlying TCB.
In fact, it is always the case that the DBMS
vendor is responsible for all the evidence required to
demonstrate that the system (i.e., the trusted
components of the application plus the underlying TCB)
has the level of trust claimed for it. In the case of
strict subsetting for evaluation by parts, in which the
application is layered onto an unaltered,
previously-evaluated TCB, part of the evidence is
satisfied by referencing the previous evaluation
results and the commercially-available specifications
for that portion of the system. However, if the
previously evaluated TCB has been altered, the
applications vendor is now responsible for
demonstrating that the underlying TCB has the level of
trust being claimed for it. How much, if any, of the
previous evaluation evidence is still valid is a matter
to be resolved.
The development of the subsetting notion has
been motivated by the need for evaluating systems whose
elements may have been developed by different vendors.
Consequently, the discussion of TCB subsets has been
largely focused on the topic of extending the policy
enforcement attributes of previously evaluated TCBs.
However, the notion of TCB subsetting provides a
perfectly general design method. A TCB can be
structured and policy enforcement allocated to simplify
both analysis and evaluation. To the extent that each
TCB subset in a subsetted system satisfies the
conditions of TC-4.3, the evaluation can be factored
along policy lines, and a rating for the composite
system determined.
4. SATISFYING RVM REQUIREMENTS
The evaluation of a system whose TCB is made
up of a set of TCB subsets follows a logical flow that
makes it an orderly process. The initial step is
satisfying the conditions for evaluation by parts.
Those conditions are as follows:
Identification of the candidate TCB
subsets;
Allocation of the policy (the clear
statement of the technical policies enforced by the
individual TCB subsets, stated in terms of the subjects
and objects for that TCB subset);
Demonstration that each candidate TCB
subset contains its own trusted subjects;
Specification of the structure of the TCB
subsets (as a collection of abstract machines);
Identification of sets of domains (called
"subset-domains") assigned for the execution of the
individual TCB subsets; and
Identification of what externally stated
properties of TCB subsets will be used to argue
convincingly and independently for the RVM nature of
each of the constituent TCB subsets.
The successful completion of this step,
especially the "support for RVM arguments" will result
in a conditional approval of two items: a set of goals
in the evaluation of the more primitive TCB subsets and
the feasibility of being able to argue the RVM
properties of less primitive TCB subsets using no more
information about the more primitive TCB subsets than
the identified goals. The goals for the more primitive
TCB subsets will be a set of mechanisms,
characteristics, or properties whose proper, assured
functioning will have to be demonstrated. Examples are
domain mechanisms, mandatory integrity policy
enforcement mechanisms, and a special category of
object with associated content-preservation guarantees.
These mechanisms or characteristics or properties are
strictly a function of the more primitive TCB subset
and will have to be evaluated and approved in a
(possibly) later part of the evaluation process. The
conditional approval of the feasibility of constructing
an independent RVM argument for less primitive TCB
subsets relies on an interplay between the proposed
mechanisms of the more primitive TCB subset and the
anticipated needs of the RVM argument for the less
primitive TCB subset.
The next steps of the evaluation process,
with regards to the reference validation mechanism
requirements, involve the independent evaluation of the
TCB subsets. TCB subsets that have been identified as
providing features or mechanisms on which other TCB
subsets will rely for RVM arguments will have to be
demonstrated to provide the stated mechanisms with the
same level of assurance as the target evaluation class
of the entire system. If all the identified mechanisms
can be validated, the conditional approval of the
"support for RVM arguments" condition remains
unchanged. If some mechanism cannot be properly
established from either a functional or an assurance
perspective, then the conditional approval of that
portion of the "support" condition is withdrawn and the
evaluation effort must regroup.
TCB subsets that were projected to be able to
complete RVM arguments successfully using no more than
the identified "support" mechanisms and features will
have to have full RVM arguments advanced and accepted
by the evaluation team. There are three possible
outcomes: (1) it could be shown that the TCB subset in
question does not meet the RVM requirements; (2) it
could be shown, using the external descriptions and
assurances of the mechanisms of the more primitive TCB
subsets, that the less primitive TCB subset does meet
the RVM requirements; or (3) it might be impossible to
determine whether or not the TCB subset meets the
requirements. In case (1), the TCB subset failed to
meet its reference validation mechanism requirements
and the design team must regroup. In case (2), the TCB
subset satisfies its reference validation mechanism
requirements. In case (3), the conditional approval of
the "support for RVM arguments" condition will be
withdrawn and the design and evaluation teams will have
to agree on an alternate course of action.
In the case that an attempt to establish RVM
properties for a less primitive TCB subset could not be
completed (case (3) above), it might well be that
additional mechanisms or features of the more primitive
TCB subset would allow the RVM arguments to be
completed successfully. In that case, the evaluation
team and the design team would have to establish a new,
augmented set of mechanisms for the "support"
condition. The evaluation could then continue with the
new mechanism requiring validation by the evaluation
team and the argument for the RVM properties of the
less primitive TCB subset having to be re-attempted.
It is important to note that the dependency
of the less primitive TCB subsets on the assured
policies and RVM supporting mechanisms makes it
imperative that the evaluation of the whole TCB be done
by a single evaluation team through the final
determination that the system complies with the full
set of requirements for the target class. Thus, in
particular, an evaluation team addressing an evaluation
by parts (including the case of a TCB subset that has
been previously evaluated and placed on the EPL) must
be kept together for the entire evaluation. Local
evaluation of one TCB subset does not justify
dissolving the responsible subteam. Later results,
global or local to another TCB subset, could require a
full evaluation team current on all aspects of the
evaluated configuration. This does not mean, of
course, that the original evaluation team for a
previously evaluated EPL product has to be reassembled.
A new team, part of which may be delegated prime
responsibility for that TCB subset, suffices, as long
as the full team is kept together for the whole
evaluation.
5. SUBSET DEPENDENCY
For candidate TCB subset M, sM denotes the
specification of M, including as a minimum, the
statement of the technical policy P of M. The term vM
denotes the (engineering) demonstrations of the
correctness of the 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 within vA assume the
correctness of the implementation of B with respect to
sB.
In less precise terms, the specification sM
defines what M is supposed to do. M does whatever its
implementation allows, features and all. How well M
does compared to what sM says it should do is
encompassed in the engineering arguments vM. If, in
the argument vA, one has to assume that all or part of
sB accurately describes what B does, A "depends" on B
for its correctness.
Example 1: Use of Provided Objects
Suppose TCB subset B provides "file" as a
mediated object under its technical policy P[B] and
that candidate TCB subset A uses B-files to store data
and executables. If vA uses the fact that different
B-files are distinct and access to them is constrained
by the technical policy P[B] (assumptions that are
nearly certain to apply), then vA is relying on the
fact that sB and B match and in this case, A depends on
B.
Example 2: Mutually Suspicious Systems
Suppose A and B are mutually suspicious
airline reservation systems hosted in two
interconnected systems belonging to two distinct
organizations. It is assumed that sA and sB both
provide for a capability to accept reservations over
the network from "foreign" systems using a mutually
defined protocol. The protocol is carefully and
completely specified (within both sA and sB) and both
vA and vB demonstrate, to the desired level of
satisfaction, that A and B are correct with respect to
sA and sB, respectively. A does not depend for its
correctness on B because sA is complete: for whatever
sequence of bits it receives from B, sA specifies
exactly what behavior A must exhibit, and vA
demonstrates that it does exhibit that behavior.
Similarly, B does not depend upon A for its
correctness. Neither A nor B depends on the other.
There may well exist a "system specification"
that specifies the desired behavior of the entire
system, but that is irrelevant to the arguments that A
and B are individually correct with respect to their
own specifications. It may even be the case that both
A and B are individually correct, while the combined
system is incorrect with respect to the "system
specification." That is, two correct subsystems can be
combined improperly with respect to the desired "system
specification."
Example 3: Use of Remotely Provided Functionality
Suppose A is a mail server and B a generic
SQL DBMS. The specification sA (as might be expected)
makes no mention of a DBMS; it simply specifies the
interface behavior (to its human clients) of the mail
system. In vA, however, we find that the software for
A uses tables provided by B to store messages. A and B
are on separate, interconnected machines. Neither sB
nor vB make mention of the mail system at all. As in
the preceding example, sB completely specifies the
behavior of B for all received bit patterns and
sequences. Here, A depends upon B, but B does not
depend on A. Note that data flow in both directions is
completely legitimate and does not compromise in any
way the "integrity" (correctness) of B. Dependency is
distinct from "data flow."
This example shows that a superficial
examination of the "architecture" of a domain structure
is insufficient to determine which candidate TCB
subsets depend upon other TCB subsets. Superficially,
this architecture is the same as the example of
mutually suspicious systems above, but here A depends
on B. It also shows that an examination of the
interface specifications is insufficient. Finally, it
shows that dependency is not the same as the notion of
"privilege" (as normally understood in the context of
operating systems to mean loosened restrictions on
allowed functions and accesses), because there is in
this example no sense in which B has access to all of
A's internal structures. It only has access to some of
them.
Example 4: Use of Locally Provided Functionality
Suppose A and B are the mail server and SQL
DBMS of the preceding example, except that A is
implemented in a less privileged ring than B. That is,
the interconnect is replaced by a ring-crossing service
call. Obviously, A still depends on B and B does not
depend on A. The change is that now B has potential
access to any of A's structures. The general rule for
the use of domain protection mechanisms (such as rings)
is that if B is privileged with respect to A, then A
necessarily depends on B (simply by virtue of B's
privilege to access any of A's structures). Thus, a
detailed examination of sA and vA is unnecessary to
establish dependency.
Cautionary Example
Suppose that A and B are "mutually
dependent"; that is, A depends on B and B depends on A.
This means that vA assumes that B is implemented
correctly with respect to sB, and vB assumes that A is
implemented correctly with respect to sA. Further
suppose that both vA and vB are valid (reasonable and
compelling). One would hope that it follows from this
that both A and B are correct. Unfortunately, this is
not always the case.
If A and B are both correct with respect to
sA and sB, then vA is a valid argument with a true
premise and is therefore true. The same is true for B
and vB.
Suppose, however, that A is implemented
incorrectly with respect to sA and B is implemented
incorrectly with respect to sB. vA is a valid argument
with a false premise; it is thus valid but (possibly)
untrue. Similarly, vB is valid but (possibly) untrue.
This case shows that it is quite possible for vA and vB
to both be valid while A and B are both (individually)
incorrectly implemented.
What has been exposed here is a hidden case
of circular reasoning: the argument that A is correct
is based on the assumption that B is correct, and the
argument that B is correct is based on the assumption
that A is correct. Thus, vA depends (circularly) on
the assumption that A is correct, and vA reduces to the
following tautology:
if vA is correct with respect to sA then vA is correct
with respect to sA.
It is thus possible in principle for mutually dependent
subsystems A and B to have vA and vB to be logically
valid while either A or B, or both, are incorrect with
respect to their specifications (sA or sB).
To make this result concrete, consider two
airline reservation systems, A and B, based on the
mutually suspicious systems of example 2 above.
Suppose that A maintains information about all flights
originating or terminating in the United States while B
maintains information about flights originating or
terminating in Europe. Assume sA includes a statement
that A will generate flight itineraries from an origin
to a destination, with appropriate provision for
connections. "Appropriate provision for connections"
means allowing enough time to change planes without
requiring passengers to wait an excessive period of
time. Further assume that sB includes a similar
statement. From the assumption that A meets sA and B
meets sB, one can construct a valid argument that A
meets its specification sA for itineraries orginating
or terminating in either the U.S. or Europe. A
similarly valid argument can be made about B. If,
however, A stores flight segment times in the local
time of the airport and B stores them i n Greenwich
Mean Time, an itinerary generated by either A or B that
relies on information from the other will be incorrect
because of the time differences. Thus, A will not
generate accurate, timely flight itineraries, even
though a valid argument that it does can be
constructed. This difficulty arises from the
presumption that A and B are mutually dependent.
6. TAMPER RESISTANCE ARGUMENTS
The requirement to demonstrate that
individual TCB subsets exhibit the reference validation
mechanism tamper resistance property deserves special
attention. In a subsetted architecture there are two
(related) aspects to this requirement. The first is
the ability of a less primitive TCB subset to maintain
control over access to the objects that implement its
logic and data structures. The second is establishing
the assurance that policy-critical or
correctness-critical data used by a TCB subset is
persistent (that is, that it does not change or become
contaminated with other data between the execution of
instructions).
A less primitive TCB subset will be using
objects and subjects provided by a more primitive TCB
subset. Thus, policy-critical data will be stored in
objects that are provided by the more primitive TCB
subset rather than in some system entity created and
maintained by the less primitive TCB subset itself.
One part of the tamper resistance argument focuses on
being able to demonstrate that no alteration of either
the policy-critical data or of the TCB subset's code is
possible. That is, no system entity external to a TCB
subset (with the possible exception of more primitive
TCB subsets upon which it depends) should be capable of
causing arbitrary changes to that TCB subset's code or
data structures. If a third, not more primitive TCB
subset (or a subject totally outside the TCB) were able
to gain access to an object where policy-critical data
was stored, the tamper resistance property could not be
established for the TCB subset in question. For a
most-primitive TCB subset, a wide variety of techniques
could be used to limit access to an object in which
such policy-critical data is stored (e.g., prohibition
on the sharing of objects, strict ownership control of
the ability to extend access permission, and mandatory
access controls). Similarly, the conditions for
evaluation by parts require that the system designer
identify a set of mechanisms and their assured
properties as the basis for demonstrating tamper
resistance for each TCB subset.
The second topic is the assurance that the
contents of the objects that store a TCB subset's
policy-critical data not change except through the
execution of that TCB subset's logic. If a data
structure that identified an exported object (such as
tables or tuples or entities) were to have extraneous
data inserted by a more primitive TCB subset (for
example, as a result of garbage collection or the
random action of memory management), then no basis
would exist for arguments concerning the correct
implementation of the less primitive TCB subset. For a
most primitive TCB subset (which includes supporting
hardware), the argument that the policy-critical data
is kept current and correct can be made strictly on the
basis of that TCB subset. However, when a TCB subset
obtains resources from a more primitive TCB subset, the
argument cannot be made strictly on the basis of the
design of the TCB subset. Rather, the argument must
proceed from assured mechanisms provided by more
primitive TCB subsets. This is exactl y analogous to
the case of a reference validation mechanism for which
one relies on mechanisms not strictly included in the
design of the policy-enforcing elements to establish
the requisite properties of non-bypassability and
tamper resistance. A variety of mechanisms might
provide a basis for demonstrating that the
implementation of a TCB subset is correct, even though
resources are obtained from a more primitive TCB subset
(e.g., type-enforcement).
7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS
Section TC-5, "General Interpreted
Requirements," lists the requirements of the TCSEC
according to how the requirements apply to a TCB made
up of more than one TCB subset. The general rationale
for distinguishing which requirements can be satisfied
by independent analysis and consideration of the TCB
subsets was to consider the requirements one at a time
to determine whether satisfaction of the requirement by
the individual TCB subsets would necessarily mean that
the entire system satisfies the stated requirement.
For some requirements, such as those for certain
documentation, it is clear that the requirement is
factorable; that is, it is satisfied for the composite
TCB if it is satisfied for each of the TCB subsets
individually. For other requirements, individual
system characteristics could make factorability of a
requirement patently obvious, but not all systems would
enjoy such simple factorability. An example would be
trusted path requirements for security-related events:
if all security-related ev ents occur in the most
primitive TCB subset, satisfaction of the requirement
by that TCB subset suffices to demonstrate that the
system meets the requirement, but for systems that have
security-relevant events in less primitive TCB subsets,
some explanation of the cooperative action of the TCB
subsets would be required. For still other
requirements, one can expect that the satisfaction of
the requirement for the entire system will always
require some explanation of the cooperative action of
the constituent TCB subsets. Provision of a coherent
audit record across events in several TCB subsets is in
this category.
In the paragraphs below, a brief rationale
for identifying requirements as wholly or partially
global is provided. Those requirements that are not
listed are considered to be completely local.
Subject Sensitivity Labels
At level B2 and above, the TCSEC requires the
following:
The TCB shall immediately notify a terminal
user of each change in the security level associated
with that user during an interactive session. A
terminal user shall be able to query the TCB as desired
for a display of the subject's complete sensitivity
level.
For subsetted architectures, the user
interface could be to a TCB subset that does not
support a mandatory access control policy. Thus, a
change noted by a more primitive TCB subset that does
support such a policy would have to be relayed to the
user, possibly through cooperative action of the full
set of TCB subsets. Similarly, a request by a terminal
user for the complete sensitivity level could be
initially received by a TCB subset that does not
support a mandatory access control policy and will
require cooperation between TCB subsets to determine
the complete subject sensitivity level and to provide
that information to the requesting user.
Identification and Authentication
The identification and authentication
requirements in the TCSEC address the need to correctly
associate authorizations with subjects. In a TCB made
of several TCB subsets, it is possible that only one of
the TCB subsets will provide identification and
authentication, which will be used by all the less
primitive TCB subsets. Alternatively, identification
and authentication may be provided directly in more
than one TCB subset. In either case, the TCB subsets
have to work cooperatively to use identification and
authentication data for uniquely identifying users and
for associating users with auditable actions.
Trusted Path
At B2, the only required uses of trusted path
are login and authentication. At B3 and above,
occasions "when a positive TCB-to-user connection is
required (e.g., login, change subject security level)"
are included. In both cases, a system vendor may
choose to use trusted path for situations where the
security-relevant event could be recognized or handled
in more than one TCB subset. On those occasions, the
careful coordination of all the involved TCB subsets in
the correct handling of trusted path situations must be
shown. If a single TCB subset implements trusted path
and all the invocations of trusted path are limited to
that TCB subset (that is, the flow of control in
responding to a trusted path initiation never leaves
the TCB subset until the response is completed), then
nothing further would be required. The description of
the limitation of trusted path to a single TCB subset
will suffice for the global part of the requirement,
leaving only the demonstration of local satisfaction of
the requireme nt by the identified TCB subset.
Audit
If each of several TCB subsets meets the
audit requirements locally, then there is the issue of
whether the set of audit records meets the requirements
of being able to note and record individual user
actions, and at B3 and above, to be able to initiate
required action. If not all the TCB subsets meet the
audit requirements locally, then the requirements must
be satisfied by the cooperative action of the set of
TCB subsets. In both cases, consideration of the audit
characteristics of all the TCB subsets has to be part
of determining that the entire TCB meets the audit
requirements.
System Architecture
For many of the system architecture
requirements, demonstrating that a requirement is
satisfied by all of the consitituent TCB subsets is
sufficient to demonstrate that it is satisfied for the
composite TCB. The requirements for the "TCB [to]
maintain a domain for its execution" and for the TCB to
"maintain process isolation through the provision of
distinct address spaces" could be satisfied by the
entire TCB without each constituent TCB meeting the
requirement.
The requirement for the TCB to maintain a
domain for its execution implies the need for each TCB
subset to have a domain for its own execution, isolated
from both untrusted portions of the system and from
less primitive TCB subsets. The exact wording of the
TCSEC requirement could be read as disallowing a less
primitive TCB subset from occupying a domain provided
by a more primitive TCB subset and to allocate its
subjects to domains that do not have access to its own
domain: the verb "maintain" could be (erroneously)
read as requiring each TCB subset to create and
maintain its own domain for execution. The proper
interpretation is that the TCB as a whole must provide
and maintain such domains for execution, rather than
each individual TCB subset.
Similarly, the exact wording of the TCSEC
requirement on the "maintain[ing] of process isolation
through the provision of distinct address spaces" could
be read as requiring each TCB subset to provide
distinct address spaces. The proper interpretation is
that the TCB as a whole must provide and maintain
process isolation, either through provision and
subsequent use of distinct address spaces, or through
provision of distinct address spaces by every TCB
subset.
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 suffices to satisfy this analysis requirement.
Otherwise, covert channel analysis must address the
entire TCB (even if the result of covert channel
analyses of the individual TCB subsets were available).
Trusted Facility Management
The ability to run a trusted system facility
properly applies to the combination of TCB subsets
making up the TCB. This requirement should not be
difficult to meet, provided that the individual TCB
subsets meet the requirement and the interactions
between the TCB subsets at the facility management
level are clear.
Trusted Recovery
In the case of "an ADP system failure or
other discontinuity," each TCB subset in a B3 or above
system needs to be able to recover "without a
protection compromise." Further, the recovery actions
of distinct TCB subsets needs to be coordinated and
combined so that the resulting system is not only
recovered as far as each TCB subset is concerned, but
is also recovered as a composite TCB.
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
suffices to satisfy the requirement for the entire TCB.
Otherwise, security testing must include testing of the
entire TCB (even if the results of testing the
individual TCB subsets are available).
Design Specification and Verification
For many of the design specification and
verification requirements, demonstrating that a
requirement is satisfied by all of the consitituent TCB
subsets is sufficient to demonstrate that it is
satisfied for the composite TCB. The requirements for
a "formal model of the security policy supported by the
TCB" and that the DTLS at B3 and the FTLS at A1 "be an
accurate description of the TCB interface" apply in a
limited way to the entire TCB.
After complying security models are provided
for the individual TCB subsets, a convincing argument
is required to explain how the set of models represents
abstractly the policy of the entire system.
After complying top-level specifications
(DTLS at B3 and FTLS at A1) are provided for the
individual TCB subsets, an explicit and convincing
description of how the set of top-level specifications
describe the TCB interface with respect to exceptions,
errors and effects must also be provided.
8. CONTENT-DEPENDENT AND CONTEXT-DEPENDENT ACCESS
CONTROL
An attractive proposition in a database
managment system is to implement access controls that
depend in some way on the values of the data in a
storage object or the context in which the information
is accessed. For example, one might desire to limit
access to all personnel records in a database according
to the salary value (content-dependent access rules).
On the other hand, a company's earnings report might be
held in confidence until announced at the stockholders'
meeting, at which time it is public information
(context-dependent access rules).
This document does not encourage or endorse
mandatory access control on storage objects that are
based on the content of data values or on the context
in which the information is viewed. Given that these
are research topics, it is prudent to take this
conservative stance. Research and current practice are
insufficient to allow definitive guidance on such
implementations.
9. BULK LOADING OF A DATABASE
The bulk loading of a database into (perhaps
thousands of) database objects must be done with care.
If the data to be loaded are unlabeled, it may not be
practical to require an authorized user to examine the
data to be loaded into each object and assign it a
sensitivity label. Instead it may be more practical to
assign labels to the data according to the sensitivity
label of the single-level device that is used to import
it. In this way, bulk loading may be done in
single-level stages.
Even importing labeled multilevel data may
prove difficult. The imported data records may be
organized on the input device in accordance with their
logical structure, not their sensitivity levels. For
some trusted DBMS architectures, this requires that the
TCB first separate the data by sensitivity levels and
subsequently load the data into the database as
single-level structures.
Another problem with bulk loading of labeled
data is granularity. It may be that the labeling
granularity of data on the input device is different
from the labeling granularity supported by the
receiving trusted DBMS. As an example, the data being
imported may be labeled at the file or field level, and
the importing DBMS may support labeling at the tuple
level. In such instances, the data would have to be
mapped into objects of the proper labeling granularity
as the data are being imported.
10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT
The ability to distinguish and separately
reference the results of local analysis of TCB subsets
is a primary aspect of evaluation by parts, and the
benefits which accrue are apparent in two, closely
related, cases that arise in evalutions by parts.
These may be thought of as dealing with the problems of
"hosting" and "porting" although they are actually two
aspects of the same problemthat of assessing a trusted
system constructed of previously evaluated parts.
For the first case (i.e., that of "hosting"),
consider an operating system which has been evaluated
against the TCSEC requirements and has received a
rating. Thus, the operating system is a TCB for which
both the local and global analysis has been done. The
results of the local analysis can now be used to
support the evaluation of a TCB made up of the
operating system (or, the more primitive TCB subset)
and any proposed TCB extension (or, less primitive TCB
subset). Suppose, for example, that vendor A chooses
the rated operating system as the host for a DBMS
product, which implements an access control policy. As
described in TC-6, it is now possible, under the
correct conditions, to re-use the results of the local
analysis of the host operating system in developing a
rating for the composite system. Even for those cases
not meeting all the conditions for evaluation by parts,
it may be possible that some, if not most, of the
previous results are still valid. If vendor B also
chooses the rated operating system as the host for his
DBMS product, it will be possible (again, under the
proper conditions) to develop a rating for the (new)
composite system without having to repeat the local
analysis of the host operating system. As an alternate
case, suppose a site has need of an electronic mail
service as well as the DBMS utility. The mail utility
will operate in a peer-entity relation with the trusted
DBMS utility (i.e., both the mail service and the DBMS
depend on the host operating system, but neither
depends on the other). Again, having the results of
the local analysis of the host operating system eases
the burden of assessing the security characteristics of
the user interface to the composite system made up of
the mail system and the host operating system. In
short, the ability to distinguish and separately
reference the results of the local analysis of the host
operating system makes it feasible to evaluate the
effect of adding arbitrary trusted applications, only
by performing the local analyis for the application and
any global analysis required.
For the second case, (i.e., that of
"porting") the question becomes that of determining the
effect of moving a known trusted application, such as a
DBMS, across arbitrary host systems. Assume that a
trusted DBMS product meeting the conditions for
evaluation by parts has been evaluated on some trusted
host, and a rating determined for the composite system.
Clearly, the results of the local analysis of the
trusted application available are also applicable to
the analysis of a composite system made up of the
trusted application and a different host operating
system. Thus, having the local analysis of the trusted
application will ease the evaluation burden associated
with porting of trusted applications to different
hosts. To the extent that the conditions for
evaluations by parts have been satisfied, the local
analysis of the application is valid by reference.
Hence only the local analysis of the host operating
system and the requisite global analysis is needed to
assess the security attributes of the new composite
system.
11. RATING MORE COMPLEX SYSTEMS
The view taken by the TCSEC is that of an
"atomic" TCB; the TCB is seen to be a single entity
which is, in some sense, homogeneous. This allows a
relatively simple measure (i.e., the digraphs) to be
assigned to the TCB. However, real systems may be more
complex, resulting in the inability of a single, simple
rating to convey the full complexity of the system.
This is implicitly recognized in TCSEC evaluation
reports and EPL entries, in which credit may be given
to a vendor for meeting TCSEC (functional) requirements
beyond those necessary to satisfy the rating (e.g., the
B3 discretionary access control feature in a C2 TCB).
In short, systems which reflect straightforward
implementations or extensions of the TCSEC can
accurately be described with a single digraph. On the
other hand, adding complexity to systems may violate
assumptions which underlie the TCSEC rating system,
requiring a more complex description if accuracy is to
be achieved.
If a TCB made up of TCB subsets is consistent
with the TCSEC assumptions on homogeneity, then a
simple digraph suffices for a full and accurate
description of the security properties of the product.
However, to the extent that a subsetted architecture
introduces complexity not captured by the digraphs, the
simple TCSEC ratings cannot be applied to the composite
system. More specifically, for a subsetted TCB to
achieve a single rating, all the requirements of that
class must be satisfied. For example, if a
discretionary access control-enforcing DBMS TCB subset
is added onto a previously evaluated B3 product, the
entire system can achieve a B3 rating if it could also
have achieved the B3 rating evaluated as a monolith.
That is, the new TCB subset must also satisfy all the
assurance and architectural requirements of B3.
Consider a candidate TCB subset which
enforces a discretionary access control policy over a
new type of object, targeted at a host system which has
already been evaluated at the B3 level. Examples are a
database management system providing discretionary
access control over tuples, a transaction processor
providing discretionary access control over
transactions, and a message system providing
discretionary access control over messages. If the
candidate TCB subset meets all the C2 requirements, the
problem is what rating will be assigned to the
composite system. To designate it a "C2" is clearly
inaccurate, as well as being unfair to the original B3
product vendor. To designate it "B3" may be equally
inaccurate, and it creates ambiguity in the meaning of
the metric used for comparing systems. In fact,
depending on the details of the specific candidate, the
composite system could legitimately be rated at any
level from C2 to B3 under a TCSEC evaluation.
The TCSEC rating system assumes a measure of
homogeneity which the above example violates thus
invalidating the very basis upon which a single digraph
may be assigned. Hence, a subsetted system such as
described above, will have to be characterized with a
more complex description than a single digraph.
Although this may seem undesirable, it will be a more
accurate description of the system, and it provides
sufficient information to allow system designers and
accreditors to make decisions about sufficiency of
security for their specific applications. In essence,
such an approach is necessary for recognizing the
additional complexity which can be introduced by
architectures which allow system elements to be
developed separately.
GLOSSARY
candidate TCB subset The identification of the
hardware, firmware, and software that make up the
proposed TCB subset, along with the identification of
its subjects and objects; one of the conditions for
evaluation by parts.
content-dependent access control Access control in
which access is determined by the value of the data to
be accessed.
context-dependent access control Access control in
which access is determined by the specific
circumstances under which the data is being accessed.
database management system A computer system whose
main function is to facilitate the sharing of a common
set of data among many different users. It may or may
not maintain semantic relationships among the data
items.
DBMS Abbreviation for "database management system."
depends A TCB subset A depends (for its correctness)
on TCB subset B if and only if the (engineering)
arguments of the correct implementation of A with
respect to its specification assume, wholly or in part,
that the specification of B has been implemented
correctly.
domain The set of objects that a subject has the
ability to access.
dominated by Security level A is dominated by
security level B if (1) the clearance/classification in
A is less than or equal to the clearance/classification
in B, and (2) the set of access approvals (e.g.,
compartment designators) in A is contained in the set
of access approvals in B (i.e., each access approval
appearing in A also appears in B). This dominance
relation is a special case of a partial order.
dominates "Security level B dominates security level
A" is synonymous with "security level A is dominated by
security level B." See "dominated by."
global requirements Those which require analysis of
the entire system and for which separate analysis of
the individual TCB subsets does not suffice. See
Section TC-5.3.2 for a summary list.
lattice A partially ordered set for which every pair
of elements has a greatest lower bound and a least
upper bound.
local requirements Those for which separate analysis
of the individual TCB subsets suffices to determine
compliance for the composite TCB. See Section TC-5.3.1
for summary list.
metadata (1) Data referring to other data; data
(such as data structures, indices, and pointers) that
are used to instantiate an abstraction (such as
"process," "task," "segment," "file," or "pipe"). (2)
A special database, also referred to as a data
dictionary, containing descriptions of the elements
(e.g., relations, domains, entities, or relationships)
of a database.
monolithic TCB A TCB that consists of a single TCB
subset.
object A passive entity that contains or receives
information. Access to an object potentially implies
access to the information it contains. Examples of
objects are: records, blocks, pages, segments, files,
directories, directory trees, and programs, as well as
bits, bytes, words, fields, processors, video displays,
keyboards, clocks, printers, network nodes, etc.
partial order A relation that is symmetric (a is
related to a), transitive (if a is related to b and b
is related to c, then a is related to c), and
antisymmetric (if a is related to b and b is related to
a, then a and b are identical.)
primitive An ordering relation between TCB subsets
based on dependency (see "depends" above). A TCB
subset B is more primitive than a second TCB subset A
(and A is less primitive than 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.
reference monitor concept An access control concept
that refers to an abstract machine that mediates all
accesses to objects by subjects.
reference validation mechanism "An implementation of
the reference monitor concept . . . that validates
each reference to data or programs by any user
(program) against a list of authorized types of
reference for that user." It must be tamper proof,
must always be invoked, and must be small enough to be
subject to analysis and tests, the completeness of
which can be assured. [1]
security policy The set of laws, rules, and
practices that regulate how an organization manages,
protects, and distributes sensitive information.
storage object An object that supports both read and
write accesses.
subject An active entity, generally in the form of a
person, process, or device that causes information to
flow among objects or changes the system state.
Technically, a process/domain pair.
subset-domain A set of system domains. For
evaluation by parts, each candidate TCB subset must
occupy a distinct subset domain such that modify-access
to a domain within a TCB subset's subset-domain is
permitted only to that TCB subset and (possibly) to
more primitive TCB subsets.
TCB subset 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 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.
technical policy The set of rules regulating access
of subjects to objects enforced by a computer system.
Trusted Computing Base (TCB) The totality of
protection mechanisms within a computer system
including hardware, firmware, and software the
combination of which is responsible for enforcing a
security policy. A TCB consists of one or more
components that together enforce a unified security
policy over a product or system. The ability of a TCB
to correctly enforce a security policy depends solely
on the mechanisms within the TCB and on the correct
input by system administrative personnel of parameters
(e.g., a user's clearance) related to the security
policy.
trusted subject A subject that is permitted to have
simultaneous view- and alter-access to objects of more
than one sensitivity level.
user Any person who interacts directly with a
computer system.
view That portion of the database that satisfies the
conditions specified in a query.
view definition A stored query; sometimes loosely
referred to as a "view."
BIBLIOGRAPHY
1. J. P. Anderson, "Computer Security Technology
Planning Study," ESD-TR-73-51 (AD-758206), J. P.
Anderson Co., October 1972.
2. J. P. Anderson, "On the Feasibility of Connecting
RECON to an External Network," Technical Report, J. P.
Anderson Co., March 1981.
3. D. E. Bell and L. J. La Padula, "Secure
Computer Systems: Unified Exposition and Multics
Interpretation," MTR-2997, (AY/W 020 445), The MITRE
Corporation, Bedford, Massachusetts, July 1975.
4. D. E. Bell and L. J. La Padula, "Secure
Computer Systems: Mathematical Foundations,"
MTR-2547-I, (AD 770 768), The MITRE Corporation,
Bedford, Massachusetts, March 1973.
5. L. J. La Padula and D. E. Bell, "Secure
Computer Systems: A Mathematical Model," MTR 2547-II,
(AD 771 543), The MITRE Corporation, Bedford,
Massachusetts, May 1973.
6. D. E. Bell, "Secure Computer Systems: A
Refinement of the Mathematical Model," MTR 2547-III,
(AD 780 528), The MITRE Corporation, Bedford,
Massachusetts, December 1973.
7. D. E. Bell, "Secure Computer Systems: A Network
Interpretation," Proceedings of the Second Aerospace
Computer Security Conference, McLean Virginia, December
2-4, 1986, pp. 32-39.
8. Department of Defense, Department of Defense
Trusted Computer System Evaluation Criteria, DOD
5200.28-STD, December 1985.
9. D. E. Denning, "Cryptographic Checksums for
Multilevel Database Security," Proceedings of the IEEE
Symposium on Security & Privacy, Oakland, California,
April 29-May 2, 1984, pp. 52-61.
10. D. E. Denning, "Commutative Filters for Reducing
Inference Threats in Multilevel Database Systems,"
Proceedings of the IEEE Symposium on Security &
Privacy, Oakland, California, April 22-24, 1985, pp.
134-146.
11. E. B. Fernandez, R. C. Summers, and C. Wood,
Database Security and Integrity, Boston, Massachusetts:
Addison Wesley, 1981.
12. C. Garvey and A. Wu, "ASD Views," Proceedings of
the Fourth Aerospace Computer Security Applications
Conference, Orlando, Florida, December 1988, pp.
85-95.
13. R. D. Graubart and J. P. L. Woodward, "A
Preliminary Naval Surveillance DBMS Security Model,"
Proceedings of the IEEE Symposium on Security &
Privacy, Oakland, California, April 26-28, 1982, pp.
21-37.
14. R. D. Graubart, "The Integrity-Lock Approach to
Secure Database Management," Proceedings of the IEEE
Symposium on Security & Privacy, Oakland, California,
April 29-May 2, 1984, pp. 62-74.
15. M. J. Grohn, "A Model of a Protected Data
Management System," ESD-TR-76-289, I. P. Sharp
Associates, Ltd., June 1976.
16. T. H. Hinke, M. Schaefer et al., "Secure Data
Management System," RADC-TR-75-266 (AD-A019201), System
Development Corporation, Santa Monica, California,
November 1975.
17. C. E. Landwehr, C. L. Heitmeyer, and J.
McLean, "A Security Model for Military Message
Systems," ACM Transactions on Computer Systems, Vol.
2, No. 3, August 1984, pp. 198-222.
18. T. F. Lunt, D. E. Denning, P. G. Neumann, R.
R. Schell, M. Heckman, and W. R. Shockley, "Final
Report Vol. 1: Security Policy and Policy
Interpretation for a Class A1 Multilevel Secure
Relational Database System," Computer Science
Laboratory, SRI International, Menlo Park, California,
1988.
19. J. McHugh and B. M. Thuraisingham, "Multilevel
Security Issues in Distributed Database Management
Systems," Computers & Security, Vol. 7, No. 4,
Elsevier Advanced Technology Publications, August 1988,
pp. 387-396.
20. National Computer Security Center, Proceedings of
the National Computer Security Center Invitational
Workshop on Database Security, Baltimore, Maryland,
June 17-20, 1986.
21. P. A. Rougeau and E. D. Sturms, "The Sybase
Secure Dataserver: A Solution to the Multilevel Secure
DBMS Problem," Proceedings of the 10th National
Computer Security Conference, Baltimore, Maryland,
September 21-24, 1987, pp. 211-215.
22. M. Schaefer, ed., Multilevel Data Management
Security, Air Force Studies Board, Committee on
Multilevel Data Management Security, National Academy
Press: Washington, D.C., 1983.
23. M. D. Schroeder and J. H. Saltzer, "A Hardware
Architecture for Implementing Protection Rings,"
Communications of the ACM, Vol. 15, No. 3, March
1972, pp.157-170.
24. W. R. Shockley and R. R. Schell, "TCB Subsets
for Incremental Evaluation," Proceedings of the Third
Aerospace Computer Security Conference, Orlando,
Florida, December 7-11, 1987, pp. 131-139.
25. P. Stachour and B. Thuraisingham, "Design of LDV
- A Multilevel Secure Database Management System," IEEE
Transactions on Knowledge and Data Engineering, Vol.
2, No. 2, June 1990, pp. 190-209.
26. M. Stonebraker, "Operating System Support for
Database Management," Communications of the ACM, Vol.
24, No. 7, July 1981, pp. 412-418.
27. Unisys Corporation, "Secure Distributed Database
Management System," Final Technical Report, Rome Air
Development Center Technical Report, RADC-TR-89-314,
Vol. 1-5, December 1989.
28. J. Wilson, "Views as the Security Objects in a
Multi-level Secure Relational Database Management
System," Proceedings of the 1988 IEEE Symposium on
Security & Privacy, Oakland, California, April 18-21,
1988, pp. 70-84.