Hackers Toolkit v2.0/Hackers_Toolkit_v2.0.iso/HTML/archive/Rainbow/ncsc/lavendarncsc.txt

Text File | 1999-11-04 | 250KB | 5,634 lines

Trusted Database Management System
Interpretation

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,
commercial, and government communities met to address issues of database
management security. The met to discuss aspects of trust (defined by the
that were sufficiently well defined and capable producing repeatable and
objective assessments. The NCSC invited issue papers and prepared a
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 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

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, beit 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 candidateTCB 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 correctimplementation 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 correctnessof each
less primitive candidate TCB subset M[i]. Aconvincing 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 securitypolicy 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 DOCUMENTATION

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 S CONSEQUENCE

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 theD-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, thef ull 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.1GENERAL 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 backupmechanisms,
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 morerigorous 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 PROTECTIONStatement 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.

SUMMARY OF THE INTERPRETATIONS BY CLASS Appendix A

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 forexecution. 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 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 SECURITY POLICY

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.2 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 separatesubset-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 1

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
undermine the evaluation rating and thus theconfidence 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 ll 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]

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 TCBsubset 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.