what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

NCSC-TG-021.txt

NCSC-TG-021.txt
Posted Aug 17, 1999

NCSC-TG-021: Trusted Database Management System Interpretation of the TCSEC (TDI), April 1991. (Purple Book)

tags | paper
SHA-256 | 5c6fe9586b7a5ea5023de4bd2f3571633922fc83aa75b82ee9e9e0cbb3e0ff88

NCSC-TG-021.txt

Change Mirror Download
          NCSC-TG-021
Library
No. S235,625




FOREWORD




The National Computer Security Center is
issuing the Trusted Database Management System
Interpretation as part of the Technical Guidelines
Program, through which we produce the "Rainbow Series."
In the Rainbow Series, we discuss in detail the
features of the Trusted Computer System Evaluation
Criteria (DoD 5200.28-STD) and provide guidance for
meeting each requirement. The National Computer
Security Center, through its Trusted Product Evaluation
Program, analyzes the security features of commercially
produced and supported computer systems. Together,
these programs ensure that organizations are capable of
protecting their important data with trusted computer
systems.

The Trusted Database Management System
Interpretation extends the evaluation classes of the
Trusted Computer System Evaluation Criteria to trusted
applications in general, and database management
systems in particular. It serves as an adjunct to the
Trusted Computer System Evaluation Criteria by
providing a technical context for the consideration of
entire systems constructed of parts and by presenting
database-specific interpretation of topics that require
direct comment. Thus, it is relevant to applications
which support sharing of computer services and
resources, and which enforce access control policies.
More specifically, it provides insight into the the
design, implementation, evaluation, and accreditation
of database management systems.


This document will be used for at least one
year after the date of signature. During this period
the NCSC will gain experience using the Trusted
Database Management Systems Interpretation in several
evaluations and continue to receive comments on issues
of technical accuracy, clarity of exposition, and
utility. After this trial period, necessary changes
will be made and a revised version issued.









_____________

PATRICK R. GALLAGHER, JR.
April 1991
Director National Computer Security Center



ACKNOWLEDGMENTS






This document represents the combined effort
of participants from the research community, industry,
and government working over several years. Three major
drafts and numerous intermediary versions were
produced, reviewed, and commented upon. To name all
the contributors would be impossible. To single out a
few would be to slight a host of others who gave
unstintingly of their time and talent. To all those
who contributed to the development and refinement of
the fundamental concepts, contributed to the
development of the several predecessor versions, and


who contributed valuable personal time and invaluable
experience in reviewing and commenting on the previous
versions, thanks is extended.




TABLE OF CONTENTS

FOREWORD i
ACKNOWLEDGMENTS iii
INTRODUCTION 1
HISTORICAL PERSPECTIVE 1
SCOPE 2
PURPOSE 2
STRUCTURE OF THE DOCUMENT 4

PART 1 TECHNICAL CONTEXT 7

TC-1 INTRODUCTION 9
TC-2 REFERENCE MONITOR PERSPECTIVE 10
TC-3 NEED FOR EVALUATION BY PARTS 11
TC-4 TCB SUBSETS 11
TC-4.1 INTRODUCTION 12
TC-4.2 TCB SUBSETS CONTEXT 13
TC-4.2.1 DEFINITION OF TCB SUBSETS 13
TC-4.2.2 MOTIVATION 13
TC-4.3 CONDITIONS FOR EVALUATION BY PARTS 14
TC-4.3.1 CANDIDATE TCB SUBSETS 14
TC-4.3.2 POLICY ALLOCATION 15
TC-4.3.3 TRUSTED SUBJECTS INCLUDED 15
TC-4.3.4 TCB SUBSET STRUCTURE 15
TC-4.3.5 SEPARATE SUBSET-DOMAINS 16
TC-4.3.6 SUPPORT FOR RVM ARGUMENTS 16
TC-4.4 EVALUATION ALTERNATIVES 17
TC-5 GENERAL INTERPRETED REQUIREMENTS 18
TC-5.1 OVERVIEW 18
TC-5.2 DETAILED REQUIREMENTS 18
TC-5.2.1 SECURITY POLICY 18
TC-5.2.1.1 Discretionary Access Control 18
TC-5.2.1.2 Object Reuse 18
TC-5.2.1.3 Labels 19
TC-5.2.1.4 Mandatory Access Control 20
TC-5.2.2 ACCOUNTABILITY 20


TC-5.2.2.1 Identification and Authentication 20
TC-5.2.2.2 Audit 21
TC-5.2.3 ASSURANCE 22
TC-5.2.3.1 Operational Assurance 22
TC-5.2.3.2 Life-Cycle Assurance 23
TC-5.2.4 DOCUMENTATION 24
TC-5.2.4.1 Security Features User's Guide 24
TC-5.2.4.2 Trusted Facility Manual 25
TC-5.2.4.3 Test Documentation 26
TC-5.2.4.4 Design Documentation 26
TC-5.3 SUMMARY OF THE REQUIREMENTS 26
TC-5.3.1 LOCAL REQUIREMENTS 26
TC-5.3.2 GLOBAL REQUIREMENTS 27
TC-6 DESIGN CHOICES 28
TC-6.1 OVERVIEW 28
TC-6.2 A SINGLE TCB SUBSET 28
TC-6.2.1 ANALYSIS OF THE CONDITIONS 28
TC-6.2.1.1 Condition 1: Candidate TCB Subsets 28
TC-6.2.1.2 Condition 2: Policy Allocation 29
TC-6.2.1.3 Condition 3: Trusted Subjects Included 29
TC-6.2.1.4 Condition 4: TCB Subset Structure 29
TC-6.2.1.5 Condition 5: Separate Subset-Domains 29
TC-6.2.1.6 Condition 6: Support for RVM Arguments 29
TC-6.2.2 EVALUATION CONSEQUENCES 29
TC-6.3 TWO TCB SUBSETS,MEETING THE CONDITIONS 30
TC-6.3.1 ANALYSIS OF THE CONDITIONS 30
TC-6.3.1.1 Condition 1: Candidate TCB Subsets 30
TC-6.3.1.2 Condition 2: Policy Allocation 31
TC-6.3.1.3 Condition 3: Trusted Subjects Included 31
TC-6.3.1.4 Condition 4: TCB Subset Structure 31
TC-6.3.1.5 Condition 5: Separate Subset-Domains 31
TC-6.3.1.6 Condition 6: Support for RVM Arguments 31
TC-6.3.2 EVALUATION CONSEQUENCES 32
TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS 33
TC-6.4.1 ANALYSIS OF THE CONDITIONS 34
TC-6.4.1.1 Condition 1: Candidate TCB Subsets 34
TC-6.4.1.2 Condition 2: Policy Allocation 34
TC-6.4.1.3 Condition 3: Trusted Subjects Included 34
TC-6.4.1.4 Condition 4: TCB Subset Structure 35
TC-6.4.1.5 Condition 5: Separate Subset-Domains 35
TC-6.4.1.6 Condition 6: Support for RVM Arguments 35
TC-6.4.2 EVALUATION CONSEQUENCES 35
TC-6.5 SUMMARY 36

PART 2 INTERPRETED REQUIREMENTS 37

IR-1 OVERVIEW AND CONTEXT 39
IR-2 SUMMARY OF THE INTERPRETATIONS 39
IR-2.1 SECURITY POLICY 39
IR-2.1.1 DISCRETIONARY ACCESS CONTROL 39
IR-2.1.2 OBJECT REUSE 40
IR-2.1.3 LABELS 40
IR-2.1.4 MANDATORY ACCESS CONTROL 40
IR-2.2 ACCOUNTABILITY 40
IR-2.2.1 IDENTIFICATION AND AUTHENTICATION 40
IR-2.2.2 AUDIT 40
IR-2.3 ASSURANCE 40
IR-2.3.1 OPERATIONAL ASSURANCE 40
IR-2.3.1.1 System Architecture 40
IR-2.3.1.2 System Integrity 40
IR-2.3.1.3 Covert Channel Analysis 41
IR-2.3.1.4 Trusted Facility Management 41
IR-2.3.1.5 Trusted Recovery 41
IR-2.3.2 LIFE CYCLE ASSURANCE 41
IR-2.3.2.1 Security Testing 41
IR-2.3.2.2 Design Specification and Verification 41



IR-2.3.2.3 Configuration Management 41
IR-2.3.2.4 Trusted Distribution 41
IR-2.4 DOCUMENTATION 42
IR-2.4.1 SECURITY FEATURES USER'S GUIDE 42
IR-2.4.2 TRUSTED FACILITY MANUAL 42
IR-2.4.3 TEST DOCUMENTATION 42
IR-2.4.4 DESIGN DOCUMENTATION 42
IR-3 LABELS 42
IR-3.1 GENERAL DISCUSSION 42
IR-3.2 SPECIFIC INTERPRETATIONS 43
IR-4 AUDIT 44
IR-4.1 GENERAL DISCUSSION 44
IR-4.2 SPECIFIC INTERPRETATIONS 45
IR-5 SYSTEM ARCHITECTURE 47
IR-5.1 GENERAL DISCUSSION 47
IR-5.2 SPECIFIC INTERPRETATIONS 47
IR-6 DESIGN SPECIFICATION AND VERIFICATION 48
IR-6.1 GENERAL DISCUSSION 48
IR-6.2 SPECIFIC INTERPRETATIONS 52
IR-7 DESIGN DOCUMENTATION 55
IR-7.1 GENERAL DISCUSSION 55
IR-7.2 SPECIFIC INTERPRETATIONS 56

APPENDIX A 59

CLASS (C1): 62
C1-1 SECURITY POLICY 62
C1-2 ACCOUNTABILITY 62
C1-3 ASSURANCE 62
C1-4 DOCUMENTATION 63
CLASS (C2): 66
C2-1 SECURITY POLICY 66
C2-2 ACCOUNTABILITY 66
C2-3 ASSURANCE 67
C2-4 DOCUMENTATION 68
CLASS (B1): 70
B1-1 SECURITY POLICY 70
B1-2 ACCOUNTABILITY 71
B1-3 ASSURANCE 73
B1-4 DOCUMENTATION 74
CLASS (B2): 77


B2-1 SECURITY POLICY 77
B2-2 ACCOUNTABILITY 79
B2-3 ASSURANCE 81
B2-4 DOCUMENTATION 85
CLASS (B3): 89
B3-1 SECURITY POLICY 89
B3-2 ACCOUNTABILITY 91
B3-3 ASSURANCE 93
B3-4 DOCUMENTATION 98
CLASS (A1): 102
A1-1 SECURITY POLICY 102
A1-2 ACCOUNTABILITY 104
A1-3 ASSURANCE 106
A1-4 DOCUMENTATION 112

APPENDIX B 117

1. PERSPECTIVE ON ASSURANCE 119
2. PROCUREMENT OPTIONS 120
3. ALTERATION OF PREVIOUSLY EVALUATED TCB 122
4. SATISFYING RVM REQUIREMENTS 125
5. SUBSET DEPENDENCY 127
6. TAMPER RESISTANCE ARGUMENTS 131
7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS 132
8 CONTENT-DEPENDENT AND CONTEXT-DEPENDENT
ACCESS CONTROL 136
9. BULK LOADING OF A DATABASE 137
10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT 137
11. RATING MORE COMPLEX SYSTEMS 139

GLOSSARY 141


BIBLIOGRAPHY 145



INTRODUCTION



HISTORICAL PERSPECTIVE

The Department of Defense Trusted Computer System
Evaluation Criteria (TCSEC), published in 1983 as
CSC-STD-001-83, consolidates knowledge about the degree
of trust one can place in a computer system to protect
sensitive information and organizes this knowledge into
usable criteria for system evaluation. The TCSEC was
republished as a DoD standard, DoD-5200.28-STD, in
December 1985 to provide a means of evaluating specific
security features and assurances available in "trusted,
commercially available automatic data processing system

The TCSEC's rating scale extends from a
minimal to a high level of trust with advanced security
features and sophisticated assurance measures.
Specific criteria determine each rating level and guide
system builders and evaluators in determining the level
of trust provided by specific systems. When the rating
levels are combined with environmental guidelines and
minimum security protection requirements, accreditation
decisions for specific installations can be made.

The philosophy of protection embodied in the
TCSEC requires that the access of subjects (i.e.,
processes in a domain) to objects (i.e., containers of
information) be mediated in accordance with an explicit
and well-defined security policy. At the higher
criteria classes, the "reference monitor concept" [1]
is an essential part of the system and the security
policy is modeled. There are several security policy
models that represent the desired behavior of a
reference monitor. The Bell-La Padula model [4-6] and
its Multics interpretation [3] are commonly used, but
not mandated.

The computer security research and
development that underpin the TCSEC began in the late
1960s and concentrated on secure operating systems. By
the early 1970s initial worked examples had provided a
substantial amount of information about building trust
into operating systems. Research continued throughout


the 1970s to refine mechanisms, features, and
assurances needed to provide trusted operating systems.

Multilevel database management security
received far less research and development attention
than did secure operating systems. This was primarily
due to the perception that one could not credibly
implement a multilevel secure database management
system (DBMS) on top of an untrusted operating system
base. However, some research in multilevel secure
DBMSs (mostly theoretical) was conducted during the
1970s [15-16], and research has continued to the
present [9-14, 17-19, 22, 25-28]. By the mid 1980s,
commercially developed, trusted operating systems were
becoming available that could provide the basis for
hosting secure applications such as multilevel secure
DBMSs.

In June 1986, the National Computer Security
Center (NCSC) initiated its efforts to address the
evaluation of trusted database management systems with
an Invitational Workshop in Baltimore, Maryland.
Representatives from the research, database vendor,
commercial, and government communities met to address
issues of database management security. The attendees
met to discuss aspects of trust (defined by the TCSEC)
that were sufficiently well defined and capable of
producing repeatable and objective assessments. The
NCSC invited issue papers and prepared a discussion
agenda. The issue papers and the subcommittee
summaries were published as the Proceedings of the
National Computer Security Center Invitational Workshop
on Database Security [20].

As an outgrowth of this workshop, the NCSC
undertook the task of preparing this Trusted Database
Management System Interpretation (TDI) of the TCSEC to
focus on the special problems posed by DBMSs. A
working group was assembled to draft this
Interpretation. Three drafts were produced, with
extensive community review and public discussion. This
Interpretation is the result of the interaction within


the general computer security and database management
communities.


SCOPE

The interpretations in this document are
intended to be used in conjunction with the TCSEC
itself; they apply to application-oriented software
systems in general, and database management systems
(DBMSs) in particular. Although the interpretations,
as noted, are general enough to apply to any software
system which supports sharing and needs to enforce
access control (e.g., transaction processing systems,
electronic mail systems), in the interest of
simplicity, the discussion, and thus the terminology,
will be directed toward DBMSs.

The interpretations are intended to be
applied primarily to commercially developed trusted
DBMSs, but can also be applied to the evaluation of
existing non-commercial DBMSs and to the specification
of security requirements for DBMS acquisitions.


PURPOSE

This Interpretation of the TCSEC has been
prepared for the following purposes:

To provide a standard to manufacturers for
security features to build into their new and planned commercial
products in order to provide widely available systems that satisfy
trust requirements (with particular emphasis on preventing the
disclosure of data) for sensitive applications,



To provide a metric with which to evaluate
the degree of trust that can be placed in computer systems for the
secure processing of classified and other sensitive information,
and

To provide a basis for specifying security
requirements in acquisition specifications.

With respect to the second purpose for
development of the criteria, i.e., providing a security
evaluation metric, evaluations can be delineated into
two types: (1) evaluations performed on a computer
product from a perspective that excludes the
application environment; or, (2) evaluations to assess
whether appropriate security measures have been taken
to permit the system to be used operationally in a
specific environment. The former type of evaluation is
done by the National Computer Security Center (NCSC)
through the Trusted Product Evaluation Program and is
called "formal product evaluation."

The latter type of evaluation, that is, one
done for the purpose of assessing a system's security
attributes with respect to a specific operational
mission, is known as a "certification evaluation." A
formal product evaluation does not constitute
certification or accreditation for the system to be
used in any specific application environment. The
system security certification and the formal
approval/accreditation procedure, done in accordance
with the applicable policies of the issuing agencies,
must still be followed before a system can be approved
for use in processing or handling sensitive or
classified information. Designated Approving
Authorities (DAAs) remain ultimately responsible for
specifying the security of systems they accredit.
3


The TCSEC and this Interpretation will be
used directly and indirectly in the certification
process. Along with applicable policy, they will be
used directly as technical guidance for evaluation of
the total system and for specifying system security and
certification requirements for new acquisitions. Where
a system being evaluated for certification employs a
product that has undergone a formal product evaluation,
reports from that process will be used as input to the
certification evaluation. Moreover, the National
Security Agency plans to publish additional guidelines
to assist certifiers and help ensure consistency in
certifications of systems processing national security
informantion.


STRUCTURE OF THE DOCUMENT

The remainder of the TDI is divided into two
parts, plus two appendices and a glossary.

PART 1, "TECHNICAL CONTEXT," presents general
information about the evaluation of trusted systems
that are constructed of several parts. This discussion
is critical to trusted DBMSs built upon trusted
operating systems, but is not limited to DBMSs only.
It is included in the TDI because it is not currently
available in any previously published document. This
section reviews the central reference monitor concept,
explains the need to evaluate a system built of
well-defined parts, and develops the concept of TCB
subsets. TCB subsets provide a way of splitting a
total TCB along access control policy lines such that
an evaluation by parts can be undertaken. PART 1
concludes with an interpretation of those TCSEC
requirements which are relevant to an evaluation by
parts, and a description of the process of evaluation
by parts.

PART 2, "INTERPRETED REQUIREMENTS," provides
interpretions of those TCSEC requirements that are
either specific to DBMSs (or applications in general),


or are particularly relevant to DBMSs. The number of
requirements that are treated explicitly is relatively
small, because many of the TCSEC requirements apply as
stated to database management systems. The
requirements treated explicitly are labels, audit,
system architecture, design specification and
verification, and design documentation.

Appendix A summarizes the interpreted
requirements for each TCSEC class and is intended to
provide an easy reference for those requiring a listing
of requirements for a specific class (e.g., B2).
Appendix B provides discussion of several topics not
directly tied to the requirements levied on trusted
DBMSs by the interpretation of the TCSEC requirements.

The TDI proper will be supplemented by a
Companion Document Series (CDS). The CDS will address
a wide spectrum of issues related to trusted DBMSs but
which are beyond the scope of this document. Community
debate about on-going topics of interest will probably
result in gradual extensions of what is known about
trusted DBMSs. Thus, volumes in the CDS will be issued
both regularly (to document the state of the community
debate) and by exception (to record new problems and
new solutions).

PART 1

TECHNICAL CONTEXT

7


TC-1 INTRODUCTION

Modern computing systems are rarely conceived
and built by a single organization. Rather, the rule
is that systems are constructed by assembling
parts?hardware, firmware, and software?produced
independently by various organizations or vendors.
This fact introduces a fundamental difficulty into the


task of evaluating a "system" for conformance to the
trust requirements of the Trusted Computer System
Evaluation Criteria (TCSEC). [8] This difficulty stems
from the fact that assessment (either evaluation of a
product or certification of a system) entails a global
perspective of the entire system under consideration.
There are not yet widely accepted methods of factoring
the various aspects of a trust assessment and then
reassembling the results into a statement about the
whole.


These conflicting perspectives of local
production and global evaluation analysis are
particularly evident in the field of database
management, but they are by no means limited to that
field. Thus the publication of this Interpretation
requires consideration of how to deal with systems
built in parts in the absence of a general treatment of
the topic. On the other hand, any treatment of the
issue in the context of trusted database management
will have significant influence in other fields where
the same or similar problems arise, just because of
community review and NCSC publication. The approach
taken in this document is to address the issues of
evaluating systems built of parts in a way that is
independent of the field of trusted database
management. This conscious attitude of generality is
intended to make clear the distinction between the
larger system-of-parts issues and the more specific
DBMS issues.

PART 1, "TECHNICAL CONTEXT," is divided into
six sections. Section TC-2, "Reference Monitor
Perspective," summarizes the role of the reference
monitor concept in both the TCSEC and the assessing of
a system for its trust characteristics. Section TC-3,
"Need for Evaluation by Parts," deals with the need to
extend the reference monitor perspective slightly to
begin to address the evaluation of systems constructed
of separate parts. Section TC-4, "TCB Subsets," is the
heart of PART 1. That section introduces a


conservative extension to the reference validation
mechanism, TCB subsets. This extension provides the
basis for being able to undertake evaluation of systems
built in parts in a way that allows re-use of the
results of separate evaluations (whether those
evaluations were performed before the current
evaluation was begun or whether the separate
evaluations overlap in time). Section TC-5, "General
Interpreted Requirements," outlines the application of
the TCSEC requirements to individual TCB subsets when
an evaluation by parts is being done. Section TC-6,
"Design Choices" describes the general process of
applying TCB subsets and meeting the conditions for
evaluation by parts. The treatment in this section is
general and not limited to DBMSs; DBMS-specific issues
are discussed in the appendices.


TC-2 REFERENCE MONITOR PERSPECTIVE

Building or evaluating a system for
compliance with the requirements of a particular class
in the TCSEC is based on the perspective of the Trusted
Computing Base (TCB). The notion of the TCB is central
to the entire concept of assessing systems for trust.
The reference monitor described in the Anderson report
[1] is the basis of the notion of a TCB, as described
in the TCSEC:

For convenience, these evaluation criteria
use the term Trusted Computing Base to refer to the
reference validation mechanism, be it a security
kernel, front-end security filter, or the entire
trusted computer system. [8, p. 67]

Even in those lower classes (below B2) where
the reference monitor concept and reference validation
mechanisms are not mentioned explicitly, the
perspective of the reference monitor and its
implementation as a reference validation mechanism is
present. Specifically, there are requirements for (1)
identifying the policy being enforced, (2) identifying


subjects and objects, (3) providing evidence that the
operation of the reference validation mechanism matches
the high-level description of the user interface, and
(4) demonstrating isolation of the TCB.

Therefore, all TCSEC evaluations share the
initial conceptual steps of identifying the mediation
policy, the subjects, and the objects. Starting from a
global system perspective, the initial step is to
identify the access mediation policy that will be
enforced. One must then identify those active system
entities that are candidates for being the "subjects"
whose access to objects the TCB will mediate.
Similarly, one must identify those passive entities,
those data repositories, that are candidates for being
the "objects," access to which the TCB will mediate.

As usual, the existence of an abstraction
within a system does not make it necessarily a
reference-monitor object, i.e., one visible at the TCB
interface. This is because the TCB will make use of
system abstractions for both its internal processes and
its storage requirements. Those entities, while being
stored in system "objects," will not be available to
untrusted processes (that is, they are not exported by
the TCB). Thus the analytical, iterative step is the
separation of candidate subjects and objects into those
that are mediated by the TCB and those that are not.

The various trust classes include
requirements, at varying levels of completeness and
rigor, that the basic reference monitor perspective of
mediating access of subjects to objects be implemented
in a correct, self-protecting, and non-bypassable
manner. The core requirements of the TCSEC classes
focus on these reference monitor imperatives. The
increasingly strict requirements for visibility into
the system design and implementation (structure,
documentation, testing, configuration, and distribution
requirements) all support the notion of checking the
system's conformance to its identified intent with
regard to the subjects, objects, and policy.


TC-3 NEED FOR EVALUATION BY PARTS

The need to be able to evaluate and certify
systems built in parts is increasingly evident. This
need is seen in a variety of contexts:

The need to evaluate and certify systems
built out of parts sold by different vendors, a
situation especially prevalent in the field of trusted
DBMSs.

The need to re-assess systems that have
undergone either small- or large-scale improvements and
are already evaluated and placed on the Evaluated
Products List (EPL).

The general problem of "families of
systems," systems that exist on a spectrum of hardware
bases or that can be customized for a user's specific
needs.

In all such cases, two related versions of a
system are largely similar. It should be possible to
undertake evaluations and certifications in such a way
that the entire assessment does not have to be re-done
for every slight variation that appears. The current
state of technology, however, places limitations on
what can be accomplished in this regard; it is not
currently possible to determine the trust
characteristics of a system on the basis of an
arbitrary collection of subparts. The overall task of
trust assessment entails so many interrelated subtasks
that the ability to separate and reassemble is not well
understood.

In this circumstance of needing to be able to
accommodate evaluation of a system built in parts and
the lack of consensus about how this can be done in a
technically sound fashion, a conservative approach must
be adopted. The following are required: (1) a clear
description of what "parts" will be considered for
separate evaluation; (2) a clear description of the


conditions under which such an evaluation by parts will
be undertaken; and (3) a general interpretation of
TCSEC requirements as they would apply when a system is
being evaluated by parts. The "parts" that will be
considered by separate evaluation are called "TCB
subsets," the topic of Section TC-4 below.


TC-4 TCB SUBSETS


TC-4.1 INTRODUCTION

To attempt an evaluation of a TCB by
splitting it into parts, there must be available a
precise definition of what parts are candidates for
separate evaluation (that is, for evaluation by parts)
as well as any other conditions that must be satisfied
before an evaluation by parts will be undertaken. This
section defines "TCB subset" as a strict and
conservative extension of the traditional concept of
the reference validation mechanism (RVM) as a method of
delineating which parts of a TCB can be candidates for
separate evaluation. The definition of TCB subsets, as
well as explanatory and motivational material, is
included below in Section TC-4.2, "TCB Subsets
Context." Section TC-4.3 addresses the conditions that
must be satisfied by a TCB divided into a set of TCB
subsets before evaluation by parts will be undertaken.
These conditions assure that the structure of and
relationships among TCB subsets will satisfy TCSEC
requirements, especially those derived from the
reference monitor concept.


TC-4.2 TCB SUBSETS CONTEXT


TC-4.2.1 DEFINITION OF TCB SUBSETS

A TCB subset M is a set of software,
firmware, and hardware (where any of these three could


be absent) that mediates the access of a set S of
subjects to a set O of objects on the basis of a stated
access control policy P and satisfies the properties:

1) M mediates every access to objects in O by
subjects in S;
2) M is tamper resistant; and
3) M is small enough to be subject to
analysis and tests, the completeness of which can be
assured.

M uses resources provided by an explicit set
of more primitive TCB subsets to create the objects of
O, create and manage its data structures, and enforce
the policy P. If there are no TCB subsets more
primitive than M, then M uses only hardware resources
to instantiate its objects, to create and manage its
own data structures, and to enforce its policy.

The above definition does not explicitly
prohibit an access control policy P that allows trusted
subjects. The implications for the evaluation process
when a TCB subset's policy allows or does not allow
such trusted subjects are substantial and are discussed
in Section TC-6.4. As described in TC-4.3, one of the
conditions for an evaluation by parts of a TCB made up
of TCB subsets is that all the trusted subjects of each
TCB subset be included in that TCB subset.

TC-4.2.2 MOTIVATION

The definition of "TCB subset" is intended to
parallel the definitions of the reference monitor and
reference validation mechanism found in the Anderson
report [1] and included in the TCSEC itself. "The term
Trusted Computing Base [refers] to the reference
validation mechanism, be it security kernel, front-end
security filter, or the entire trusted computer
system." [8, p. 67] "TCB subset" is defined exactly
like a reference validation mechanism, with only one
difference, that it does not necessarily extend to the
hardware. Rather, a TCB subset uses either hardware


resources or the resources provided by other, more
primitive TCB subsets. Thus TCB subsets build on
abstract machines, either physical hardware machines or
other TCB subsets. Just like reference validation
mechanisms, a TCB subset must enforce a defined access
control policy.


TC-4.3 CONDITIONS FOR EVALUATION BY PARTS

Building or evaluating a system using the
definition of TCB subsets in the section above requires
meeting six conditions in addition to demonstrating
that the candidate TCB subsets satisfy the properties
appropriate to the evaluation target class. The
conditions are as follows:

The candidate TCB subsets are
identified;
The system policy is allocated to
the candidate TCB subsets;
Each candidate TCB subset M[i]
includes all the trusted subjects with respect to
its technical policies P[i];
The TCB subset structure or
architecture is explicitly described;
Each TCB subset occupies distinct
subset-domains; and
The more primitive TCB subsets
provide support for the RVM arguments for less primitve TCB
subsets.

These conditions are described below.

TC-4.3.1 CANDIDATE TCB SUBSETS

The first condition is that the relevant
elements of each candidate TCB subset M[i] be


identified. The hardware, firmware, and software which
compose the TCB subset need to be clearly identified,
along with the subjects and objects. In terms of
Section TC-4.2.1, this condition is the identification
of M[i], S[i], and O[i]. There may be no objects
mediated by more than one TCB subset. That is, there
cannot be an object O that is both in O[i] and O[j].

TC-4.3.2 POLICY ALLOCATION

The next condition is policy allocation, the
description of the technical policy P[i] for each
identified M[i] along with the relation of these
policies to the system policy P. The policies P[i]
will be expressed in terms of subjects in S[i] and
objects in O[i]. Thus, to satisfy the TCSEC
requirement that the (composite) TCB enforce its stated
policy P, each rule in P must be traceable through the
structure of the candidate TCB subsets to the TCB
subset(s) where that enforcement occurs. See Sections
TC-5.2.1.1 and TC-5.2.1.4.

TC-4.3.3 TRUSTED SUBJECTS INCLUDED

Every trusted subject with respect to P[i]
must be part of the TCB subset M[i]. This condition
makes possible separate evaluation of TCB subsets with
respect to "local" requirements. When this condition
is not met, evaluation of candidate TCB subsets cannot
be guaranteed on an evaluation by parts basis. This
situation is treated in Section 6.4.

TC-4.3.4 TCB SUBSET STRUCTURE

The TCB subsets will exhibit a structure
based on the ordering implied by dependency. TCB
subset A is less primitive than TCB subset B if (a) A
directly depends on B or (b) a chain of TCB subsets
from A to B exists such that each element of the chain
directly depends on its successor in the chain. In
this case we use the phrase "TCB subset B is more
primitive than TCB subset A" synonymously.


The sense of "directly depend" in (a) is
exactly the following: it is not possible to verify
the implementation of A with respect to its
specification without a statement about the
specification of B.


More precisely, for a candidate TCB subset M,
let sM denote the specification of M. The
specification will include, as a minimum, the statement
of the technical policy P of M. Further, let vM denote
the (engineering) demonstrations of the correct
implementation of M with respect to its specification.
A (candidate) TCB subset A "depends (for its
correctness)" on (candidate) TCB subset B if and only
if the arguments of vA assume, wholly or in part, that
sB has been implemented correctly. (See Appendix B,
item 5 for additional discussion.)

The proposed structure of TCB subsets has to
be identified. The order must be a partial order.
(Without a partial order, there could be circular
chains of dependencies that would inhibit separate
evaluations of the TCB subsets.)

TC-4.3.5 SEPARATE SUBSET-DOMAINS

The candidate TCB subsets must operate in
near isolation from each other, with the only
interaction between them being that explicitly asserted
as part of the interface. In the case of reference
monitors, many existing implementations have relied on
the domain concept [23] which supports the assertions
of non-bypassability and self protection. A natural
extension of the domain concept will be required for
isolation of TCB subsets from each other and from
non-TCB entities.

A subset-domain is a set of system domains.
Each candidate TCB subset must occupy a distinct
subset-domain such that modify-access to a TCB subset's
subset-domain is permitted only to that TCB subset and


(possibly) to more primitive TCB subsets. This
requirement ensures that the structure of
subset-domains with respect to access is consonant with
the dependency relation among TCB subsets.

TC-4.3.6 SUPPORT FOR RVM ARGUMENTS

Candidate TCB subsets must satisfy the three
RVM properties included in the definition in TC-4.2.1
in order to complete evaluation by parts successfully.
TCB subsets that build on resources and functionality
provided by more primitive TCB subsets must rely on
assured and evaluatable characteristics of those more
primitive TCB subsets. A convincing argument must be
advanced that the features, characteristics, and
assurances provided by the more primitive TCB subsets
are capable of supporting RVM arguments for the less
primitive TCB subsets.

The first property (mediating every access)
requires that there is no way of bypassing the
mediation provided by TCB subset M for its objects,
either directly or by unexpected side-effects of
interactions with other TCB subsets. A variety of
approaches could suffice for demonstrating this
property.

The second property (tamper resistance)
requires that the policy-critical code and data for the
less primitive TCB subset be protected from any
alteration not specifically allowed by the TCB subset.
A variety of approaches could suffice for demonstrating
this property.

The third property (completeness of testing
and analysis for correctness) requires the
(engineering) demonstrations vM[i] of the correctness
of each less primitive candidate TCB subset M[i]. A
convincing argument must therefore be advanced that the
specifications sM[k] for all of the more primitive TCB
subsets M[k] on which M[i] depends will suffice for
establishing vM[i].


TC-4.4 EVALUATION ALTERNATIVES

As noted earlier, the need to evaluate
systems whose elements are developed separately,
possibly by independent developers, results in the need
to define TCB subsets. That is not to say, however,
that design by TCB subsetting and the subsequent
evaluation by parts are the only alternatives. Rather,
there are three distinct possibilities.

A system TCB, regardless of any internal
structure, may be viewed as a single entity. In such a
case, the evaluation may proceed essentially as an
evaluation against the TCSEC. This case is examined in
Section TC-6.2.

A system TCB may be presented as a subsetted
architecture composed of a number of candidate TCB
subsets. Given that each of the candidate TCB subsets
satisfies the conditions set forth in Section TC-4.3,
an evaluation by parts is possible. This case is
described in Section TC-6.3.

It may be possible to satisfy only some of
the conditions for evaluation by parts. This situation
might arise when a previously evaluated TCB or TCB
subset is modified to accommodate the policy-enforcing
elements of a new application layer. A special case of
this situation is described in Section TC-6.4. In such
cases, depending upon the particulars, it may be
possible to realize some of the savings in evaluation
effort. However, no general statements can be made for
these cases.


TC-5 GENERAL INTERPRETED REQUIREMENTS


TC-5.1 OVERVIEW

This section provides specific
interpretations of those TCSEC requirements that are


particularly relevant for subsetted architectures and
evaluation by parts. Its organization is derived from
the structure of the TCSEC requirements. For each
relevant TCSEC requirement there is a discussion of how
that requirement is interpreted in an evaluation by
parts.

For conciseness, only the requirements
headings applicable for A1 systems are included below.
Thus, the interpretation guidance below should be
applied only as demanded by the requirements for the
target class of the candidate trusted system. For a
system targeted at an evaluation class below A1, only
those requirements that pertain to the target class
apply to the TCB subsets making up that system.

A listing of the requirements and
interpretations by TCSEC class is presented in Appendix
A. The rationale for the applicability of the TCSEC
requirements to TCB subsets alone or to the TCB as an
entirety is described in Appendix B, item 7.


TC-5.2 DETAILED REQUIREMENTS

TC-5.2.1 SECURITY POLICY

TC-5.2.1.1 Discretionary Access Control

The discretionary access control requirements
apply as stated in the TCSEC to every TCB subset whose
policy includes discretionary access control of its
subjects to its objects. Any TCB subset whose policy
does not include such discretionary access control is
exempt from this requirement.

TC-5.2.1.2 Object Reuse

This requirement applies as stated in the
TCSEC to every TCB subset in the TCB.

TC-5.2.1.3 Labels


This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

Label Integrity


This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

Exportation of Labeled Information


This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

Subject Sensitivity Labels


This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

Device Labels


This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its objects
and has attached physical or virtual devices. Any TCB


subset whose policy does not include such mandatory
access control or has no attached physical or virtual
devices is exempt from this requirement. This
requirement can be satisifed by the cooperative action
of more than one TCB subset.

TC-5.2.1.4 Mandatory Access Control

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

TC-5.2.2 ACCOUNTABILITY

TC-5.2.2.1 Identification and Authentication

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

If the TCB is composed of TCB subsets, one
TCB subset may either rely on a mechanism in another
TCB subset to provide identification and authentication
services or provide the services directly. Similarly,
that TCB subset may rely on a mechanism in another more
primitive TCB subset to ensure that the security level
of subjects external to the TCB that may be created to
act on behalf of the individual user are dominated by
the clearance and authorization of that user. Each TCB
subset may maintain its own identification and
authentication data or one central repository may be
maintained. If each TCB subset has its own data, then
the information for each individual user must be
consistent among all subsets.

Trusted Path



This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

When TCB subsets are used, the requirement
for trusted path at levels B2 and above remains
applicable to the entire TCB. The need for trusted
path "when positive TCB-to-user connection is required
(e.g., login, change subject security level)" can
require user interaction with virtually any TCB subset
within the TCB. The implementation of trusted path
could be localized in a single TCB subset.
Alternatively, it could be implemented in more than one
TCB subset if the separate implementations together
comply with the system security policy.

TC-5.2.2.2 Audit

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

A TCB subset may maintain its own security
audit log, distinct from that maintained by more
primitive TCB subsets, or it may use an audit interface
provided by a different TCB subset allowing the audit
records it generates to be processed by that TCB
subset.

If the TCB subset uses different user
identifications than a more primitive TCB subset, there
shall be a means to associate audit records generated
by different TCB subsets for the same individual with
each other, either at the time they are generated or
later.

Any TCB subset wherein events may occur that
require notification of the security administrator
shall be able to do the following: (1) detect the
occurrence of these events, (2) initiate the recording


of the audit trail entry, and (3) initiate the
notification of the security administrator. The
ability to terminate events (2) and (3) above may be
provided either in the TCB subset within which they
occur, or in the TCB subset(s) where actions that lead
to the event were initiated.

The monitoring and notification requirements
may require cooperation between multiple distinct TCB
subsets or multiple instantiations of the same TCB
subset. For example, to detect the accumulation of
events for a single user it may be necessary to collect
events from several subjects in distinct processes that
are surrogates for the same user. As another example,
there may be a single TCB subset that collects events
from a number of other TCB subset instantiations and,
based on its analysis of them, notifies the security
administrator.

TC-5.2.3 ASSURANCE

TC-5.2.3.1 Operational Assurance

System Architecture

This requirement applies as stated in the
TCSEC to every TCB subset, with the following
additional interpretations.

The TCB must provide domains for execution
that are allocated to and used by TCB subsets according
to the subset-domain condition for evaluation by parts.
A most primitive TCB subset must provide domains for
execution. A less primitive TCB subset must make use
of domains provided by a more primitive TCB subset. A
less primitive TCB subset may provide further execution
domains but is not required to do so.

Similarly, the TCB must provide distinct
address spaces for untrusted processes. A most
primitive TCB subset must provide distinct address
spaces for its subjects. A less primitive TCB subset


must make use of the distinct address space provided by
a more primitive TCB subset. A less primitive TCB
subset may provide more fine-grained distinct address
spaces, but is not required to do so.

In general, requirements specifically
referring to hardware or firmware apply only to TCB
subsets that include hardware or firmware. The
exception is the requirement that the TCB make
effective use of available hardware. This requirement
applies to those TCB subsets that use resources
provided by more primitive TCB subsets in lieu of
hardware. Those TCB subsets are required to make
effective use of the protection-relevant features
exported to it by the more primitive TCB subsets (e.g.,
execution domains, support for distinct address spaces)
to separate those elements that are protection-critical
from those that are not.

System Integrity


This requirement applies as stated in the
TCSEC to every TCB subset that includes hardware or
firmware. Any TCB subset that does not include
hardware or firmware is exempt from this requirement.

Covert Channel Analysis


This requirement applies as stated in the
TCSEC to the entire TCB. When the TCB is made up
entirely of TCB subsets meeting the conditions for
evaluation by parts, analysis of the individual TCB
subsets satisfies this requirement. Otherwise, covert
channel analysis of the entire TCB must be performed
(even if the results of covert channel analysis of the
individual TCB subsets were available).

Trusted Facility Management



This requirement applies as stated in the
TCSEC to the entire TCB. Any "operator" or
"administrator" functions intrinsic to an individual
TCB subset must be supported by that TCB subset or by a
more primitive TCB subset.

Trusted Recovery


This requirement applies as stated in the
TCSEC to the entire TCB and to the individual TCB
subsets. The cooperative recovery actions of the TCB
subsets making up the TCB must provide trusted recovery
for the overall TCB. Otherwise, trusted recovery
evaluation must address the entire TCB (even if the
individual TCB subsets meet the trusted recovery
requirements).

TC-5.2.3.2 Life-Cycle Assurance

Security Testing


This requirement applies as stated in the
TCSEC to the entire TCB. If a TCB consists of TCB
subsets meeting the conditions for evaluation by parts,
the satisfaction of the requirements by each TCB subset
satisfies the requirement for the entire TCB.
Otherwise, security testing of the entire TCB must be
performed (even if the results of testing the
individual TCB subsets were available).

Design Specification and Verification


This requirement applies as stated in the
TCSEC to every TCB subset, with the following specific
additional interpretations.

It must be demonstrated that the security
policy enforced by the composite TCB is represented by


the collection of policy models for the individual TCB
subsets.

The argument that the descriptive top level
specification (DTLS) and formal top level specification
(FTLS) are consistent with the TCB interface applies to
the entire TCB. There is required an explicit and
convincing description of how the set of top level
specifications (one for each TCB subset) describes the
TCB interface in terms of exceptions, errors, and
effects.

Configuration Management


This requirement applies as stated in the
TCSEC to every TCB subset in the TCB, with the
following additional interpretation.

Because subsets of the TCB may be developed
independently, a single configuration management system
may not be feasible. However, the combination of
configuration management systems used to support all
the TCB subsets must meet all the stated requirements.
The information describing the interrelations between
separate TCB subsets and separate security policy
models falls into the category of "all documentation
and code associated with the current version of the
TCB" in the TCSEC requirements.

Trusted Distribution


This requirement applies as stated in the
TCSEC to the entire TCB. It can be met by satisfying
the requirements for each TCB subset if procedures
exist for assuring that all TCB subsets upon which a
particular TCB subset depends (that is, the more
primitive TCB subsets) are exactly the same version as
specified for the TCB subset in question.

TC-5.2.4 DOCUMENTATION


TC-5.2.4.1 Security Features User's Guide

This requirement applies as stated in the
TCSEC to every TCB subset in the TCB. This collection
of guides must include descriptions of every TCB subset
in the TCB and explicit cross-references to other
related user's guides to other TCB subsets, as
required. In addition, interactions between mechanisms
within different TCB subsets must be clearly described.

TC-5.2.4.2 Trusted Facility Manual

This requirement applies as stated in the
TCSEC to the TCB and to every TCB subset in the TCB.

This requirement can be met by providing a
set of manuals, one for each distinct (non-replicated)
TCB subset. Each manual shall address the functions
and privileges to be controlled for the associated TCB
subset. Additionally, it must clearly show the
interfaces to, and the interaction with, more primitive
TCB subsets. The manual for each TCB subset shall
identify the functions and privileges of the TCB
subsets on which the associated TCB subset depends.
Also, the TCB subset's manual shall identify which, if
any, configuration options of the more primitive TCB
subsets are to be used for the composite TCB to operate
securely.

Any pre-defined roles supported (e.g.,
database administrator) by the TCB subset shall be
addressed.

The means for correlating multiple audit logs
and synonymous user identifications from multiple TCB
subsets (if such exist) shall also be addressed.

The trusted facility manual shall describe
the composite TCB so that the interactions among the
TCB subsets can be readily determined. Other manuals
may be referenced in this determination. The manuals
that address the distinct modules of the TCB and the


generation of the TCB need to be integrated with the
other trusted facility manuals only to the extent that
they are affected by the use and operation (versus the
development) of the composite TCB.

The TCB modules that contain the reference
validation mechanism must be associated with the TCB
subset to which they belong. The procedure for
generating a new TCB after modifying only one (or
several) TCB subsets must be described. This may be
accommodated by independent regeneration of the
individual TCB subsets or by regeneration of only the
affected TCB subsets.

TC-5.2.4.3 Test Documentation

This requirement applies as stated in the
TCSEC to the composite TCB.

TC-5.2.4.4 Design Documentation

This requirement applies as stated in the
TCSEC to the composite TCB, with the following specific
additional interpretations:

Requirements concerning models, FTLS and
DTLS, apply to individual TCB subsets.

The requirement concerning the description
of interfaces between modules of the TCB includes the
interfaces between TCB subsets.

The documentation of the implementation of
a reference validation mechanism must include
justification for meeting the conditions for evaluation
by parts.

The A1 requirement to describe
clearly non-FTLS internals of the TCB applies to TCB
subsets.



TC-5.3 SUMMARY OF THE REQUIREMENTS

The requirements interpretations in Section
TC-5.2 above can be grouped into two categories: those
that apply to individual TCB subsets and those that
apply totally or in part to the overall TCB. For
purposes of exposition, the former category will be
termed "local requirements," that is, those for which
separate analysis of the individual TCB subsets
suffices to determine compliance for the composite TCB.
The latter are termed "global requirements," that is,
those which require analysis of the entire system and
for which separate analysis of the individual TCB
subsets does not suffice.

TC-5.3.1 LOCAL REQUIREMENTS

Discretionary Access Control;
Object Reuse;
Labels (except Subject Sensitivity Labels);
Mandatory Access Control;
System Architecture (except domains for
execution and distinct address spaces);
System Integrity;
Configuration Management;
Security Features User's Guide;
Design Documentation
models,
DTLSs,
FTLSs, and
non-FTLS internals.

TC-5.3.2 GLOBAL REQUIREMENTS

Subject Sensitivity Labels;
Identification and Authentication;
Trusted Path;
Audit;
System Architecture domains for execution, and distinct
address spaces;
Covert Channel Analysis;
Trusted Facility Management;
Trusted Recovery (also applies to
individual TCB subsets);
Security Testing;
Design Specification and Verification
correspondence between system
policy and the set of TCB subset models

consistency of TCB interface with the
set of TCB subset DTLSs, and

consistency ofTCB interface with the
set of TCB subset FTLSs;
Trusted Distribution;
Trusted Facility Manual (also applies to individual TCB
subsets);
Test Documentation; and
Design Documentation (except models, DTLSs, FTLSs, and
non-FTLS internals).


TC-6 DESIGN CHOICE


TC-6.1 OVERVIEW

This section examines the several design
choices available for constructing systems in parts and
the consequences of each when attempting to perform an
evaluation by parts. The first case described is that
of a TCB evaluated under the TCSEC without benefit of
TCB subset structuring. This case is of value for
several reasons: it serves as a reference point; it
can be considered the degenerate case of subsetting;
and it is always an option to evaluate any TCB,
regardless of internal structure, as a monolith. The
second and third cases are presented in terms of a
configuration of exactly two subsets; the
generalization to more than two TCB subsets is
straightforward. The second case is that of a
subsetted architecture that exactly satisfies the
conditions for evaluation by parts. The third case
represents a special case of an altered TCB, one which
is implemented using trusted subjects.

Note that no evaluation using TCB subsets and
evaluation by parts results in a TCB subset receiving
an evaluation rating. Rather, the entire system, with
its composite TCB, is evaluated and receives a rating.
However, evaluation by parts is intended to allow the


results of local analysis of individual TCB subsets to
be distinguishable and separately referencable. For
further discussion of this topic, see Appendix B, item
10.


TC-6.2 A SINGLE TCB SUBSET

The evaluation of a TCB consisting of a
single TCB subset is equivalent to a straightforward
evaluation against the TCSEC. The conditions for
evaluation by parts (Section TC-4.3) reduce to
requirements found in the TCSEC itself.

TC-6.2.1 ANALYSIS OF THE CONDITIONS

TC-6.2.1.1 Condition 1: Candidate TCB
Subsets

The TCB (hardware, software, and firmware),
as distinguished from the rest of the computing system,
must be identified. This is a basic requirement for
TCSEC evaluation. Similarly, the subjects and objects
within the system must be identified. The requirement
that no more than one TCB subset mediate access to any
particular object is satisfied, because there is only
one TCB subset.

TC-6.2.1.2 Condition 2: Policy Allocation

The policy P enforced by the TCB (subset)
must be identified. The demonstration that the TCB
(subset) enforces that policy will be a description of
how the TCB performs access mediation between the
system's subjects and objects according a system-level
description of limitations on access (the technical
policy P[i] of the definition). The tracing of the
policy to the system design and behavior is part of the
stated TCSEC requirements.

?TC-6.2.1.3 Condition 3: Trusted Subjects
Included


This condition is satisfied in the same
manner as it is in evaluations under the TCSEC.
Specifically, the TCB boundary is shown to be the
interface that is presented to untrusted subjects.

TC-6.2.1.4 Condition 4: TCB Subset Structure

Satisfaction of this condition (TC-4.3.4) is
immediate, because there is only one TCB subset.

TC-6.2.1.5 Condition 5: Separate
Subset-Domains

Satisfaction of the separate subset-domain
condition (TC-4.3.5) is identical to the C1 through A1
requirement that "the TCB maintain a domain for its own
execution that protects it from external interference
or tampering." [8, p. 13 et al.]

TC-6.2.1.6 Condition 6: Support for RVM
Arguments

Satisfaction of this condition (TC-4.3.6) is
immediate, inasmuch as there are no less primitive TCB
subsets that must be demonstrated to satisfy RVM
requirements.

TC-6.2.2 EVALUATION CONSEQUENCES

In this case, the evaluation of the (single)
TCB subset proceeds exactly like an evaluation under
the TCSEC. Demonstration that the candidate system
meets all the global and local requirements (as they
apply to the target evaluation class) includes the
consideration of each requirement as it applies
system's philosophy of protection, design,
documentation, and implementation. The system must be
shown to exhibit the properties of a reference
validation mechanism, appropriate to the target class.


TC-6.3 TWO TCB SUBSETS, MEETING THE CONDITIONS


This case is of a TCB that consists of two
candidate TCB subsets, A and B, where A is the most
primitive TCB subset. That is, B uses the abstractions
provided by A (the objects, in particular) as its
resource for the construction and exportation of its
own abstractions. B also uses the abstractions
provided by A for its metadata (that is, internal data
structures) that make it possible for B to instantiate
its exported abstractions as well as keep records that
enable it to correctly enforce its stated policy. In
terms of the discussion of Section TC-4.3.4, TCB subset
B directly depends on TCB subset A. It will be assumed
that TCB subset A enforces mandatory and discretionary
policies on its objects and that TCB subset B enforces
a discretionary policy on the objects it exports.
Additionally, all trusted subjects of A are contained
within A. Thus, every subject of A (including all the
active entities that make up the logic of B) operates
at a single sensitivity level. It will further be
assumed for th is example that the mechanisms for
domains and thus for subset-domains are independent of
the mandatory and discretionary access control policy
enforcement mechanisms.

TC-6.3.1 ANALYSIS OF THE CONDITIONS

TC-6.3.1.1 Condition 1: Candidate TCB
Subsets

The TCB (hardware, software, and firmware),
as distinguished from the rest of the computing system,
must be identified. This is a basic requirement for
TCSEC evaluation. Similarly, the subjects and objects
within the system must be identified.

In this case, all the hardware, software, and
firmware that make up the TCB must be identified as
being part of either TCB subset A or TCB subset B. The
subjects and objects mediated by A (call them the
"A-subjects" and "A-objects" for this discussion) must
be identified. Similarly the B-subjects and B-objects
must also be identified.


The additional requirement in Section
TC-4.3.1 that "there may not be any objects mediated by
more than one TCB subset" means that there can be no
B-object that is also an A-object.

TC-6.3.1.2 Condition 2: Policy Allocation

The policy P enforced by the whole TCB must
be identified. In addition, the policy enforced by A
(call it the A-policy), stated in terms of the
A-subjects and the A-objects, must be identified.
Similarly, the B-policy, stated in terms of the
B-subjects and the B-objects, must be identified.

TC-6.3.1.3 Condition 3: Trusted Subjects
Included

As was stated above, TCB Subset A contains
all its own trusted subjects. There may be trusted
subjects with respect to the policy of A, but all such
subjects execute in the subset-domain of A.

TC-6.3.1.4 Condition 4: TCB Subset Structure

Because B directly uses the A-objects and its
logic is embodied in A-subjects, the structure of the
TCB subsets is precisely "TCB subset A is more
primitive than TCB subset B." This is a partial order.

TC-6.3.1.5 Condition 5: Separate
Subset-Domains

Satisfaction of the separate subset-domain
condition requires that a set of domains provided by
the system be identified as being the domains
"occupied" by A and B. The domain, or domains,
occupied by A is exactly the "domain for its own
execution" found in the TCSEC requirements. The domain
or domains occupied by TCB subset B must not be
modifiable by any code or other system entity except
possibly by TCB subset A.


TC-6.3.1.6 Condition 6: Support for RVM
Arguments

Satisfying the condition for RVM arguments
requires demonstrating the plausibility of being able
to establish the three requisite properties of an RVM.
The first property requires that no B-subject be
allowed to access B-objects without those accesses
being mediated by TCB subset B. The tamper resistance
property requires that TCB subset A provide a way that
TCB subset B can be designed and implemented such that
A-subjects that are not part of B's implementation
cannot tamper with B's policy-critical code or data.
The third RVM property must be satisfied by the
individual TCB subsets. The degree to which each TCB
subset must satisfy this property is commensurate with
the evaluation class of the TCB.

TC-6.3.2 EVALUATION CONSEQUENCES

In this case, the evaluation of the two TCB
subsets requires that each meet TCSEC requirements
applicable to each TCB subset viewed individually and
that the two TCB subsets combine in a way to meet all
the TCSEC requirements stated for the target class.

All local requirements are imposed on the two
TCB subsets, A and B, individually. If each TCB subset
can meet the requirements of the target class, viewed
as if it were a separate TCB, the only areas where
additional evaluation or accreditation work might be
required are those areas where the sum of the analysis
of the parts is not necessarily complete and
convincing. Those areas requiring additional work are
exactly the set of global requirements described in
Section TC-5.3.2.

Demonstrating that the candidate system meets
the TCSEC requirements (as they apply to the target
evaluation class) requires that both A and B be
evaluated with respect to the local requirements of the
target class and that the composite TCB be evaluated


for global requirements. In this case, full testing of
TCB subset A against all the requirements (both local
and global) simplifies the task of demonstrating
satisfaction of the global requirements, both for B and
for the entire TCB.

Suppose, for example, that TCB subset A has
been subjected to security testing appropriate to the
target class and has been shown to be adequately
resistant to penetration attacks. This means that
within the confidence level provided by the testing
requirement, no A-subject can subvert A's enforcement
of its policy. In this situation, every active entity
in B is an A-subject and hence B can neither penetrate
A nor be induced to do so by any B-subject. Thus, no
further testing of A will be required to determine
whether the entire TCB is resistant to penetration; any
additional penetration testing can be limited to
determining the ability of B to withstand assault.

Similarly, if A has been searched for covert
channels (as required for its target class
requirements), then no further search for covert
channels will be required, either in the analysis of B
or in the overall consideration of the entire TCB.
Note that if B implements a mandatory access control
policy (e.g., integrity), then it would be necessary to
perform a covert channel analysis on B, but no further
covert channel analysis of A would be required.

The ability of users to determine the current
sensitivity level of B-subjects operating on their
behalf will have to be shown by considering the TCB
subsets A and B together. This requirement is
satisfied immediately if the argument relies
exclusively on A meeting the requirement.



TC-6.4 TWO TCB SUBSETS, NOT MEETING THE
CONDITIONS


This case also concerns a TCB that consists
of two candidate TCB subsets, C and D. C is the most
primitive TCB subset. That is, D uses the abstractions
provided by C (the objects, in particular) as its
resource for the construction and exportation of its
own abstractions. D also uses the abstractions
provided by C for its metadata (that is, internal data
structures) that make it possible for D to instantiate
its exported abstractions as well as keep records that
enable it to correctly enforce its stated policy. In
terms of the discussion of Section TC-4.3.4, TCB subset
D directly depends on TCB subset C. Additionally, D is
trusted with respect to C. That is, some of the
C-subjects which make up TCB subset D execute as
trusted processes of C. Here also, as in the previous
example, it is assumed that C implements mandatory and
discretionary policies over its objects. Further, the
intent of D is to implement a discretionary policy over
the objects it exports. However, because D includes
subjects which are trusted relative to C's policy
demonstration of the full and correct enforcement of
the mandatory policy requires analysis of both C and D
and is no longer localized to TCB subset C. It will be
assumed that the mechanisms for domains and thus for
subset-domains are independent of the mandatory and
discretionary access control policy enforcement
mechanisms.

This case can be viewed as a special case of
a previously evaluated TCB which has been altered.
However, the alteration takes the form of a less
primitive subset which is implemented, at least in
part, with trusted subjects (i.e., some of the
C-subjects are trusted subjects which execute in the
subset-domain of D). Although this case may appear,
intuitively, to be different from that of arbitrary
alteration of a previously evaluated TCB, the example
demonstrates that such an approach makes it impossible
to perform an evaluation by parts.

TC-6.4.1 ANALYSIS OF THE CONDITIONS


TC-6.4.1.1 Condition 1: Candidate TCB
Subsets

The identification of the TCB (hardware,
software, and firmware) as distinguished from the rest
of the computing system is a basic requirement for
TCSEC evaluation. Likewise, the subjects and objects
within the system must be identified.

In this case, all the hardware, software, and
firmware that make up the TCB must be identified as
being part of either TCB subset C or TCB subset D. The
C-subjects and C-objects mediated by C have to be
identified. Similarly the D-subjects and D-objects
must also be identified.

The additional requirement in Section
TC-4.3.1 that "there may not be any objects mediated by
more than one TCB subset" means there can be no
D-object that is also a C-object.

TC-6.4.1.2 Condition 2: Policy Allocation

The policy P enforced by the whole TCB must
be identified. In addition, the individual policy
enforced by C (call it the C-policy) must be identified
in terms of the C-subjects and the C-objects.
Similarly, the D-policy, stated in terms of the
D-subjects and the D-objects, must be stated. In this
case, the C-policy will include the strict enforcement
of a mandatory access control policy that allows
trusted subjects to execute in the subset-domains which
compose TCB subset D.

TC-6.4.1.3 Condition 3: Trusted Subjects
Included

This condition is not satisfied because D
includes at least one subject that is trusted with
respect to C. Hence a subject that is trusted with
respect to the policy of C is outside C, and evaluation
by parts is not an option. If TCB subset C had


previously been evaluated, then this is an example of
an altered TCB, albeit a special case. The change
consists of the addition of one or more trusted
C-subjects in D whose effect on the behavior of C
cannot be predicted a priori. An assessment of the
impact of D on the behavior of C cannot be made
strictly by an examination of the trusted subjects and
the definition of C's interface. A global assessment
of C and D is required.

TC-6.4.1.4 Condition 4: TCB Subset Structure

Because D directly uses the C-objects and its
logic is embodied in C-subjects, the structure of the
TCB subsets is precisely "TCB subset C is more
primitive than TCB subset D." This is a partial order.

TC-6.4.1.5 Condition 5: Separate
Subset-Domains

Satisfying the separate subset-domain
condition (TC-4.3.5) requires identifying the set of
system domains (likely administered by the most
primitive TCB subset C) as the domains "occupied" by C
and D. The domain, or domains, occupied by C is
exactly the "domain for its own execution" found in the
TCSEC requirements. The domain or domains occupied by
TCB subset D must not be modifiable by any code or
other system entity except possibly by a part of TCB
subset C.

TC-6.4.1.6 Condition 6: Support for RVM
Arguments

Satisfying the condition for RVM arguments
requires demonstrating the plausibility of being able
to establish the three requisite properties of an RVM.
The first property requires that no B-subject be
allowed to access B-objects without those accesses
being mediated by TCB subset B. The tamper resistance
property requires that TCB subset A provide a way that
TCB subset B can be designed and implemented such that


A-subjects that are not part of B's implementation
cannot tamper with B's policy-critical code or data.
The third RVM property must be satisfied by the
individual TCB subsets. The degree to which each TCB
subset must satisfy this property is commensurate with
the evaluation class of the TCB.

TC-6.4.2 EVALUATION CONSEQUENCES

In this example, the conditions for
evaluation by parts are not satisfied and thus, the
full potential for savings in evaluation effort cannot,
in general, be realized. A clear option in such cases
is to view the system as a monolithic TCB and proceed
accordingly. However, because this case represents an
example of an altered TCB, it admits of a wide spectrum
of specific sub-cases. Thus, if the analysis of the
system proceeds in parallel to that required for
evaluation by parts it may be possible, in special
cases, to identify elements of the analysis of the more
primitive candidate TCB subset which can be
successfully argued to be unaffected by the
alterations. Some evaluation effort, often
significant, can be saved, but unlike evaluation by
parts, how much can only be estimated by consideration
of the implementation specifics. For example, in this
specific case, the local analysis of TCB subset C
represents a reasonable candidate for analysis that
need not be redone.


TC-6.5 SUMMARY

The three cases described above illustrate
the effects of various TCB subsetting situations as
they relate to the evaluation requirements.

A monolithic evaluation proceeds exactly as
described in the TCSEC, with requirements being applied
to the entire TCB.
When all the conditions for evaluation by
parts are satisfied, considerable savings in evaluation


effort are realized. The evaluation of a new system
configuration that includes exactly the same TCB subset
that was previously evaluated (such as the TCB subsets
A and B in the Section TC-6.3) is limited to (a) local
analysis of the individual TCB subsets (by reference to
earlier analysis, if available) and (b) a simpler
global analysis, because each TCB subset is an exact
analog of a TCB.
When the conditions for evaluation by parts
are not satisfied, no general statements can be made
about the factorability of analysis or the reusability
of previous analysis. The extent to which previous
evaluation evidence and results remain valid can be
determined only on a case-by-case basis.















PART 2


INTERPRETED REQUIREMENTS





IR-1 OVERVIEW AND CONTEXT

Part 2, "INTERPRETED REQUIREMENTS," provides
specific interpretations of those TCSEC requirements
which are deemed to be either DBMS-specific (or, more
generally, application-specific) or particularly
relevant to DBMSs. All of the requirements in the
TCSEC apply in any case.

For the topics included below, the
interpretations provide clarification of the TCSEC
requirements. As is the case for the TCSEC, the
interpreted requirements at any class include those
specified for that class in addition to interpretations
for lower classes that have not been superseded or
altered.

Section IR-2 presents an overall summary of
the TCSEC requirements, as interpreted in the more
detailed sections that follow. Sections IR-3 through
IR-7 address individual requirements interpretations
for labels, audit, system architecture, design
specification and verification, and design
documentation, respectively. The format is an initial
discussion of the topic in general, followed by
specific requirements and interpretations that apply to
database management systems. A listing of the
requirements and interpretations organized by TCSEC
class is presented in Appendix A.


IR-2 SUMMARY OF THE INTERPRETATIONS

This section provides specific
interpretations of those TCSEC requirements that are
particularly relevant for subsetted architectures and
evaluation by parts. Its organization is derived from
the structure of the TCSEC requirements. For each
relevant TCSEC requirement there is a discussion of how
that requirement is interpreted for a DBMS.



IR-2.1 SECURITY POLICY

IR-2.1.1 DISCRETIONARY ACCESS CONTROL

The requirement for discretionary access
control is not changed in the context of this document
and therefore applies as stated in the TCSEC.

IR-2.1.2 OBJECT REUSE


The requirement for object reuse is not
changed in the context of this document and therefore
applies as stated in the TCSEC.

IR-2.1.3 LABELS

The requirement for labels is treated in
Section IR-3 of this document.

IR-2.1.4 MANDATORY ACCESS CONTROL

The requirement for mandatory access control
is not changed in the context of this document and
therefore applies as stated in the TCSEC. However,
there are several subtle ramifications of this
requirement of which a developer or evaluator should be
aware. A brief discussion can be found in Appendix B,
item 8, "Content-Dependent and Context-Dependent Access
Control."


IR-2.2 ACCOUNTABILITY

IR-2.2.1 IDENTIFICATION AND AUTHENTICATION

The requirement for identification and
authentication is not changed in the context of this
document and therefore applies as stated in the TCSEC.

IR-2.2.2 AUDIT


The requirement for audit is treated in
Section IR-4 of this document.


IR-2.3 ASSURANCE

IR-2.3.1 OPERATIONAL ASSURANCE

IR-2.3.1.1 System Architecture

The requirement for system architecture is
treated in Section IR-5 of this document.

IR-2.3.1.2 System Integrity

The requirement for system integrity is not
changed in the context of this document and therefore
applies as stated in the TCSEC.

IR-2.3.1.3 Covert Channel Analysis

The requirement for covert channel analysis
is not changed in the context of this document and
therefore applies as stated in the TCSEC.

IR-2.3.1.4 Trusted Facility Management

The requirement for trusted facility
management is not changed in the context of this
document and therefore applies as stated in the TCSEC.

IR-2.3.1.5 Trusted Recovery

The requirement for trusted recovery is not
changed in the context of this document and therefore
applies as stated in the TCSEC.

IR-2.3.2 LIFE CYCLE ASSURANCE

IR-2.3.2.1 Security Testing


The requirement for security testing is not
changed in the context of this document and therefore
applies as stated in the TCSEC.

IR-2.3.2.2 Design Specification and
Verification

The requirement for design specification and
verification is treated in Section IR-6 of this
document.

IR-2.3.2.3 Configuration Management

The requirement for configuration management
is not changed in the context of this document and
therefore applies as stated in the TCSEC.

IR-2.3.2.4 Trusted Distribution

The requirement for trusted distribution is
not changed in the context of this document and
therefore applies as stated in the TCSEC.


IR-2.4 DOCUMENTATION

IR-2.4.1 SECURITY FEATURES USER'S GUIDE

The requirement for a security features
user's guide is not changed in the context of this
document and therefore applies as stated in the TCSEC.

IR-2.4.2 TRUSTED FACILITY MANUAL

The requirement for a trusted facility manual
is not changed in the context of this document and
therefore applies as stated in the TCSEC.

IR-2.4.3 TEST DOCUMENTATION


The requirement for test documentation is not
changed in the context of this document and therefore
applies as stated in the TCSEC.

IR-2.4.4 DESIGN DOCUMENTATION

The requirement for design documentation is
treated in Section IR-7 of this document.


IR-3 LABELS


IR-3.1 GENERAL DISCUSSION

The labels requirements of the TCSEC are
entirely applicable to database management systems.
The basic difference between the TCSEC labeling
requirements as they apply to operating systems and
DBMSs involves which storage objects are labeled rather
than how the labels are handled. This section
discusses special considerations in implementing and
evaluating labeling mechanisms in database management
systems. Of particular importance is the selection of
the storage objects that are to be labeled.

Beginning at the B1 evaluation class, trusted
database management systems are required to associate
labels with all storage objects under their control.
The granularity of storage objects to be protected
shall be chosen by the DBMS designer.

Stored view definitions (that is, named query
commands) that are visible at the TCB boundary must be
stored in labeled objects. The TCB must mediate access
both to the view definition and to the view
instantiation (that is, the set of labeled objects
accessed as the result of executing the query command
contained in the view definition).

It has been proposed in several designs that
views be used as a mechanism to implement context- or


content-dependent labeling. The intuitive
attractiveness of this approach is undeniable, but the
implementation details must be carefully worked out to
achieve a sound implementation. A brief discussion of
this topic can be found in Appendix B, item 8,
"Content-Dependent and Context-Dependent Access
Control."

TCB designers and evaluators may make
distinctions between objects that are explicitly
labeled or implicitly labeled. Such distinctions are
meaningful only within the confines of the TCB; all
storage objects are explicitly labeled from a point of
view outside the TCB. For example, consider an object
of one type (e.g., table or file) within the TCB that
"contains" many (reference monitor) objects of another
type (e.g., tuples and records). The file could have
an explicit label associated with it, and some of the
records could have explicit labels associated with
them. Those records that have no explicit label would
be implicitly labeled by the label of the file.

For database management systems, the objects
that store the base data of the database (e.g., files,
records, relations, and tuples), as well as those
objects that store the metadata (e.g., directories,
indices, schemas, data dictionaries, discretionary
authorization tables, recovery logs, and transaction
logs), must be labeled. Objects that need not be
labeled include internal resources that are not user
visible (e.g., printer daemon scratch files and
resource allocation tables). The requirement for
importing data (labeled and unlabeled) is the same as
in the TCSEC. For additional information, see Appendix
B, item 9, "Bulk Loading of a Database."


IR-3.2 SPECIFIC INTERPRETATIONS

CLASS (B1): LABELED SECURITY PROTECTION

There are no interpretations for this class.


CLASS (B2): STRUCTURED PROTECTION

Statement from TCSEC

Sensitivity labels associated with each ADP
system resource . . . that is directly or indirectly
accessible by subjects external to the TCB shall be
maintained by the TCB.

Interpretation

Internal TCB variables that are not visible
to untrusted subjects need not be labeled, provided
that they are not directly or indirectly accessible by
subjects external to the TCB. However, it is important
to understand that such internal variables can function
as covert signaling channels when untrusted subjects
are able to detect changes in these variables by
observing system behavior.


CLASS (B3): SECURITY DOMAINS

There are no additional requirements.


CLASS (A1): VERIFIED DESIGN

There are no additional requirements.


IR-4 AUDIT


IR-4.1 GENERAL DISCUSSION

The audit requirements of the TCSEC apply to
database management systems. This section discusses
special considerations in designing and evaluating
audit mechanisms in database management systems.


The TCB must be capable of maintaining an
audit trail of accesses and attempted accesses to the
objects protected by the mandatory and discretionary
security policies. Two examples are given to
illustrate auditing techniques for discretionary access
control decisions.

Example 1. Consider a DBMS TCB providing discretionary
controls on defined views of the database. Because the
named object presented at the TCB interface is the view
definition (not the records instantiated through the
view), all that needs to be auditable is the use of the
view by any untrusted subject.

Example 2. Consider a DBMS TCB that enforces
discretionary access control on individual data
records. When a user enters a query, the construction
of a response may involve a search over many records
that are not returned to the user because they did not
satisfy the query. Records that do satisfy the query
but to which the user does not have access should be
auditable. Records that do not satisfy the query need
not be auditable. That is, in the context of audit,
access permission to the user and satisfaction of a
query are to be kept separate.

There is no need to audit operations that are
strictly internal to the TCB. Separate security audit
logs may be maintained by the operating system and the
database management system. Likewise, separate
identifications for the same user may be maintained by
the operating system and the database management
system. The correlation of separate audit logs may be
done either at the time they are generated or at some
later time.

The emphasis of the audit criterion is to
provide individual accountability for actions by users.
This goal is not the same as that for a backup and
recovery log. There is no requirement to integrate the
audit log with the backup and recovery log, although
such an integrated log is not prohibited.


At the designer's discretion, there may be a
selectable capability to reduce the number of audit
records generated in response to queries that involve
many access control decisions.


IR-4.2 SPECIFIC INTERPRETATIONS

CLASS (C2): CONTROLLED ACCESS PROTECTION

Statement from TCSEC

The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of accesses to the objects it protects.

Interpretation

Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of
the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to users. That is, each
discretionary access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.

CLASS (B1): LABELED SECURITY PROTECTION

Statement from TCSEC

The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of accesses to the objects it protects.

Interpretation


Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of
the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to the user. That is, each
discretionary access control policy decision and each
mandatory access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.

CLASS (B2): STRUCTURED PROTECTION

There is no interpretation for the additional
requirements.

CLASS (B3): SECURITY DOMAINS

There is no interpretation for the additional
requirements.

CLASS (A1): VERIFIED DESIGN

There are no additional requirements.


IR-5 SYSTEM ARCHITECTURE


IR-5.1 GENERAL DISCUSSION

The system architecture requirements of the
TCSEC apply to database management systems.

The interpretations provided are a
duplication of the general interpreted requirements
that apply to an evaluation by parts. They are


included because DBMS evaluations often involve
multiple TCB subsets.


IR-5.2 SPECIFIC INTERPRETATIONS

CLASS (C1): DISCRETIONARY SECURITY
PROTECTION

Statement from TCSEC

The TCB shall maintain a domain for its own
execution that protects it from external interference
or tampering.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to each TCB subset.

CLASS (C2): CONTROLLED ACCESS PROTECTION

There is no interpretation for the additional
requirements.

CLASS (B1): LABELED SECURITY PROTECTION

There is no interpretation for the additional
requirements.

CLASS (B2): STRUCTURED PROTECTION

Statement from TCSEC

The user interface to the TCB shall be
completely defined and all elements of the TCB
identified.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to the interface between the


TCB subsets as well as the user interface to the whole
TCB.

Statement from TCSEC

It shall make effective use of available
hardware to separate those elements that are
protection-critical from those that are not.

Interpretation

If the TCB is composed of multiple subsets,
each TCB subset must make use of facilities provided to
it by more primitive TCB subsets, such as support for
execution domains and for distinct address spaces, to
achieve the required separation.

CLASS (B3): SECURITY DOMAINS

There is no interpretation for the additional
requirements.

CLASS (A1): VERIFIED DESIGN


There are no additional requirements.


IR-6 DESIGN SPECIFICATION AND VERIFICATION


IR-6.1 GENERAL DISCUSSION

The design specification and verification
requirements of the TCSEC, with the related
documentation requirements, apply to database
management systems.

The interpretations provided include a
duplication of general interpreted requirements that
apply to an evaluation by parts. They are included


because of the likelihood that a DBMS evaluation will
involve multiple TCB subsets.

In the database context, the set of
candidates for "subject" and "object" can be larger
than normally encountered in trusted operating systems.
Where a database system builds on an underlying trusted
operating system, for example, the set of candidate
subjects for the two TCB subsets includes both the
active entities created by the operating system and
those active entities created by the trusted portion of
the DBMS. The set of candidates for objects is large.
Examples are files, segments, buffers, structures,
pages, relations, tables, tuples, rows, columns,
elements, entities, relationships, procedures,
metadata, system tables, query trees, query plans,
locking mechanisms, rollback mechanisms, indices,
recovery and backup mechanisms, precalculated
operations (such as joins), view definitions, view
instantiations, constraints, authorization tables, data
dictionary tables, and audit logs.

The requirements in the TCSEC for showing how
the various representations of the system being
evaluated fit together can be represented as in Figure
IR-1. For monolithic TCBs, the policy must be stated;
the model must be developed, maintained, and shown to
be sufficient to enforce the policy; and the DTLS (FTLS
for A1) must be constructed and shown to correspond
both to the model and to the TCB implementation. These
steps allow a chain of reasoning to proceed from the
stated policy to the assertion that the system in
question actually enforces the policy.

In the case of multiple TCB subsets, the
intent is the same. Tracing all policy requirements to
the actual system implementation must be possible, and
vice versa. The current dilemma is that the theory and
techniques for subdividing a model into a set of models
(or a top level specification into a set of top level
specifications) have not yet been established.
Likewise neither theory or techniques have been


established for composing a set of models or top level
specifications into a unified model or top level
specification. The absence of rigorous methods does
not preclude an evaluation using a subsetted TCB.

The process of mapping policy to
implementation is possible for each TCB subset, using
the same techniques required for a monolithic TCB. For
subsetted TCBs, designers and evaluators must
explicitly show how the policy, model and
specifications for each TCB subset meet the TCSEC
requirements. In addition, convincing informal
arguments must be given to show how the collection of
TCB subsets enforces the policy of the composite TCB.
Because more rigorous composition methods are
unavailable, convincing informal arguments are
appropriate for evaluation of TCBs up to and including
Class A1.

The TCSEC requirements concerning the mapping
from policy to implementation for a TCB composed of
multiple TCB subsets raise these crucial topics:

The allocation of policy to the TCB
subsets,

The relation of the models for the TCB
subsets to the overall system policy, and

The relation of the top level
specification for each TCB subset to the entire system.

Allocation of policy to the TCB subsets is a
precise division of the policy for the entire system,
as addressed in the policy allocation condition of
Section TC-4.3.

The second topic, above, requires that the
policy for each TCB subset be stated. Additionally, it
is required that there be an informal convincing
argument that the collection of models represents the
policy enforced by the entire system.


The third topic, the way in which the set of
top level specifications for the individual TCB subsets
describes the composite TCB interface with respect to
exceptions, errors and effects, is treated in a similar
fashion. The top level specifications for each TCB
subset must meet the requirement. There is, in
addition, a requirement for an informal, convincing
description of how the set of top level specifications
describes the TCB interface with respect to exceptions,
errors, and effects. At the A1 level, there is no
requirement for additional formal specification or
formal proofs beyond the specification and proofs
specific to the individual TCB subsets.

Rather than formally composing the policies,
models, and specifications and performing a single
monolithic evaluation, a series of separate evaluations
may be performed (one for each TCB subset). The
evaluations are then tied together by presentation of
sufficient informal arguments that the individual
policies collectively represent the policy enforced by
the entire system, that the individual models
collectively represent the system's policy, that the
individual specifications represent the TCB interface,
and that the source code of each TCB subset is
consistent with its top level specification.

Note that satisfactory completion of these
requirements is logically equivalent to demonstrating
that a "unified" model for the entire TCB is consistent
with the policy enforced by the system, that a
"unified" top level specification corresponds to the
model, and that the "unified" top level
specification(s) corresponds to the source code. These
interpreted requirements, which do not mandate a
"unified" top level specification, are technically
achievable interpretations of the policy-tracing
requirements in the case of multiple TCB subsets.


IR-6.2 SPECIFIC INTERPRETATIONS


CLASS (B1): LABELED SECURITY PROTECTION

Statement from TCSEC

An informal or formal model of the security
policy supported by the TCB shall be maintained over
the life cycle of the ADP system and demonstrated to be
consistent with its axioms.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to the security
policy of each TCB subset. An informal argument that
the set of policy models represents the "security
policy supported by the [composite] TCB" must be
provided.

CLASS (B2): STRUCTURED PROTECTION

Statement from TCSEC

A formal model of the security policy
supported by the TCB shall be maintained over the life
cycle of the ADP system and demonstrated to be
consistent with its axioms.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to the security
policy of each TCB subset. An informal argument that
the set of policy models represents the "security
policy supported by the [composite] TCB" must be
provided.

Statement from TCSEC

A descriptive top-level specification (DTLS)
of the TCB shall be maintained that completely and
accurately describes the TCB in terms of exceptions,
error messages, and effects.


Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to the DTLS of each
TCB subset. An informal argument that the set of DTLSs
accurately describes the TCB must be provided.

If there is a multifaceted policy (e.g., both
mandatory access control and discretionary access
control policies) in a particular TCB subset, then all
facets must be represented in the DTLS and in the TCB
subset's model.

Statement from TCSEC

The descriptive top-level specification
(DTLS) shall be shown to be an accurate description of
the TCB interface.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to the interface between the
TCB subsets as well as to the user interface of the
composite TCB. The TCB interface description shall
include an explanation of how to describe the total TCB
accurately, in the context of the multiple TCB subset
DTLSs.

CLASS (B3): SECURITY DOMAINS

Statement from TCSEC

A convincing argument shall be given that the
DTLS is consistent with the model.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to individual TCB
subsets. Enforcement of all policies must be shown to
occur in all situations (e.g., state transitions)


required by the formal security policy model. In the
case of a discretionary access control policy, the
presence of the access control check at all identified
state transitions is the total of what is required for
demonstrating consistency between the DTLS and the
model. This may be verified by inspection of the DTLS
(that is, by visually checking that exception checks
required by the model are present in the DTLS). For
the mandatory access control policy, the DTLS must be
shown by a convincing argument to be consistent with
the model.

CLASS (A1): VERIFIED DESIGN

Statement from TCSEC

A formal top-level specification (FTLS) of
the TCB shall be maintained that accurately describes
the TCB in terms of exceptions, error messages, and
effects.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to the FTLS of each
TCB subset. An informal argument that the set of FTLSs
accurately describes the TCB must be provided.

If there is a multifaceted policy (e.g., both
mandatory access control and discretionary access
control policies) in a particular TCB subset, then all
facets must be represented in the FTLS and in the TCB
subset's model.

Statement from TCSEC

The FTLS shall be shown to be an accurate
description of the TCB interface.

Interpretation


If the TCB is composed of multiple subsets,
this requirement applies to the interface between the
TCB subsets as well as to the user interface of the
composite TCB. The TCB interface description shall
include an explanation of how to describe the total TCB
accurately, in the context of the multiple TCB subset
DTLSs.

Statement from TCSEC

. . . a combination of formal and informal
techniques shall be used to show that the FTLS is
consistent with the model.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to individual TCB
subsets. Enforcement of all policies must be shown to
occur in all situations (e.g., state transitions)
required by the formal security policy model at the
required occasions. In the case of a discretionary
access control policy, the presence of the access
control check at all identified state transitions is
the total of what is required for demonstrating
consistency between the FTLS and the model. This may
be verified by inspection of the FTLS (that is, by
visually checking that exception checks required by the
model are present in the FTLS). For the mandatory
access control policy, the FTLS must be shown by a
combination of formal and informal techniques to be
consistent with the model.


IR-7 DESIGN DOCUMENTATION


IR-7.1 GENERAL DISCUSSION

The design documentation requirement of the
TCSEC applies to database management systems.


The interpretations provided are a
duplication of the general interpreted requirements
that apply to an evaluation by parts. They are
included because DBMS evaluations often involve
multiple TCB subsets.


IR-7.2 SPECIFIC INTERPRETATIONS

CLASS (C1): DISCRETIONARY SECURITY PROTECTION

Statement from TCSEC

If the TCB is composed of distinct modules,
the interfaces between these modules shall be
described.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.

CLASS (C2): CONTROLLED ACCESS PROTECTION

There are no additional requirements.

CLASS (B1): LABELED SECURITY PROTECTION

Statement from TCSEC

The specific TCB protection mechanisms shall
be identified and an explanation given to show that
they satisfy the model.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and shall
include the protection mechanisms which support the
conditions for TCB subset structure and separate
subset-domains.


CLASS (B2): STRUCTURED PROTECTION

Statement from TCSEC

The interfaces between the TCB modules shall
be described.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between different TCB subsets.

Statement from TCSEC

The descriptive top-level specification
(DTLS) shall be shown to be an accurate description of
the TCB interface.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to the interface between the
TCB subsets as well as to the user interface of the
composite TCB. The TCB interface description shall
include an explanation of how to describe the total TCB
accurately, in the context of the multiple TCB subset
DTLSs.

Statement from TCSEC

Documentation shall describe how the TCB
implements the reference monitor concept and give an
explanation of why it is tamper resistant, cannot be
bypassed, and is correctly implemented.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
each TCB subset with respect to its specific technical
policy. In addition, there must be documented an


informal argument that the cooperative action of the
TCB subsets makes the TCB itself tamper resistant,
non-bypassable, and correct.

Statement from TCSEC

Documentation shall describe how the TCB is
structured to facilitate testing and to enforce least
privilege.

Interpretation

If the TCB is composed of multiple subsets,
this requirement is interpreted to apply to individual
TCB subsets as well as to the overall TCB.

CLASS (B3): SECURITY DOMAINS

Statement from TCSEC

The TCB implementation shall be informally
shown to be consistent with the DTLS.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
individual TCB subsets.

CLASS (A1): VERIFIED DESIGN

Statement from TCSEC

The TCB implementation shall be informally
shown to be consistent with the FTLS.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement is interpreted to apply to
individual TCB subsets.
















APPENDIX A


SUMMARY OF THE

INTERPRETATIONS BY CLASS



This section is a presentation of all the
interpreted requirements organized by TCSEC class. It
includes all the requirements which are either relevant
to subsetted architectures or are DBMS-specific. Any
TCSEC requirements not explicitly identified herein
apply as stated in the TCSEC.

CLASS (C1): DISCRETIONARY SECURITY PROTECTION

C1-1 SECURITY POLICY


C1-1.1 DISCRETIONARY ACCESS CONTROL

The discretionary access control requirements
apply as stated in the TCSEC to every TCB subset whose
policy includes discretionary access control of its
subjects to its objects. Any TCB subset whose policy
does not include such discretionary access control is
exempt from this requirement.

C1-2 ACCOUNTABILITY

C1-2.1 IDENTIFICATION AND AUTHENTICATION

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

If the TCB is composed of TCB subsets, one
TCB subset may either rely on a mechanism in another
TCB subset to provide identification and authentication
services or provide the services directly. Each TCB
subset may maintain its own identification and
authentication data or one central repository may be
maintained. If each TCB subset has its own data, then
the information for each individual user must be
consistent among all subsets.

C1-3 ASSURANCE

C1-3.1 OPERATIONAL ASSURANCE

C1-3.1.1 SYSTEM ARCHITECTURE

This requirement applies as stated in the
TCSEC to every TCB subset, with the following
additional interpretations.

The TCB must provide domains for execution
that are allocated to and used by TCB subsets according
to the subset-domain condition for evaluation by parts.
A most primitive TCB subset must provide domains for


execution. A less primitive TCB subset must make use
of domains provided by a more primitive TCB subset. A
less primitive TCB subset may provide further execution
domains but is not required to do so.

Statement from TCSEC

The TCB shall maintain a domain for its own
execution that protects it from external interference
or tampering.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to each TCB subset.

C1-3.1.2 SYSTEM INTEGRITY

This requirement applies as stated in the
TCSEC to every TCB subset that includes hardware or
firmware. Any TCB subset that does not include
hardware or firmware is exempt from this requirement.

C1-3.2 LIFE CYCLE ASSURANCE

C1-3.2.1 SECURITY TESTING

This requirement applies as stated in the
TCSEC to the entire TCB. If a TCB consists of TCB
subsets meeting the conditions for evaluation by parts,
the satisfaction of the requirements by each TCB subset
satisfies the requirement for the entire TCB.
Otherwise, security testing of the entire TCB must be
performed (even if the results of testing the
individual TCB subsets were available).

C1-4 DOCUMENTATION

C1-4.1 SECURITY FEATURES USER'S GUIDE

This requirement applies as stated in the
TCSEC to every TCB subset in the TCB. This collection


of guides must include descriptions of every TCB subset
in the TCB and explicit cross-references to other
related user's guides to other TCB subsets, as
required. In addition, interactions between mechanisms
within different TCB subsets must be clearly described.

C1-4.2 TRUSTED FACILITY MANUAL

This requirement applies as stated in the
TCSEC to the TCB and to every TCB subset in the TCB.

This requirement can be met by providing a
set of manuals, one for each distinct (non-replicated)
TCB subset. Each manual shall address the functions
and privileges to be controlled for the associated TCB
subset. Additionally, it must clearly show the
interfaces to, and the interaction with, more primitive
TCB subsets. The manual for each TCB subset shall
identify the functions and privileges of the TCB
subsets on which the associated TCB subset depends.
Also, the TCB subset's manual shall identify which, if
any, configuration options of the more primitive TCB
subsets are to be used for the composite TCB to operate
securely.

Any pre-defined roles supported (e.g.,
database administrator) by the TCB subset shall be
addressed.

The means for correlating multiple audit logs
and synonymous user identifications from multiple TCB
subsets (if such exist) shall also be addressed.

The trusted facility manual shall describe
the composite TCB so that the interactions among the
TCB subsets can be readily determined. Other manuals
may be referenced in this determination. The manuals
that address the distinct modules of the TCB and the
generation of the TCB need to be integrated with the
other trusted facility manuals only to the extent that
they are affected by the use and operation (versus the
development) of the composite TCB.


C1-4.3 TEST DOCUMENTATION

This requirement applies as stated in the TCSEC to the
composite TCB.

C1-4.4 DESIGN DOCUMENTATION

This requirement applies as stated in the TCSEC to the
composite TCB.

Statement from TCSEC

If the TCB is composed of distinct modules,
the interfaces between these modules shall be
described.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.

CLASS (C2): CONTROLLED ACCESS PROTECTION

C2-1 SECURITY POLICY

C2-1.1 DISCRETIONARY ACCESS CONTROL

The discretionary access control requirements
apply as stated in the TCSEC to every TCB subset whose
policy includes discretionary access control of its
subjects to its objects. Any TCB subset whose policy
does not include such discretionary access control is
exempt from this requirement.

C2-1.2 OBJECT REUSE

This requirement applies as stated in the TCSEC to
every TCB subset in the TCB.

C2-2 ACCOUNTABILITY



C2-2.1 IDENTIFICATION AND AUTHENTICATION

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

If the TCB is composed of TCB subsets, one
TCB subset may either rely on a mechanism in another
TCB subset to provide identification and authentication
services or provide the services directly. Each TCB
subset may maintain its own identification and
authentication data or one central repository may be
maintained. If each TCB subset has its own data, then
the information for each individual user must be
consistent among all subsets.

C2-2.2 AUDIT

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

A TCB subset may maintain its own security
audit log, distinct from that maintained by more
primitive TCB subsets, or it may use an audit interface
provided by a different TCB subset allowing the audit
records it generates to be processed by that TCB
subset.

If the TCB subset uses different user
identifications than a more primitive TCB subset, there
shall be a means to associate audit records generated
by different TCB subsets for the same individual with
each other, either at the time they are generated or
later.

Statement from TCSEC


The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of access to the objects it protects.

Interpretation

Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of
the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to users. That is, each
discretionary access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.

C2-3 ASSURANCE

C2-3.1 OPERATIONAL ASSURANCE

C2-3.1.1 SYSTEM ARCHITECTURE

This requirement applies as stated in the
TCSEC to every TCB subset, with the following
additional interpretations.

The TCB must provide domains for execution
that are allocated to and used by TCB subsets according
to the subset-domain condition for evaluation by parts.
A most primitive TCB subset must provide domains for
execution. A less primitive TCB subset must make use
of domains provided by a more primitive TCB subset. A
less primitive TCB subset may provide further execution
domains but is not required to do so.

Statement from TCSEC


The TCB shall maintain a domain for its own
execution that protects it from external interference
or tampering.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to each TCB subset.

C2-3.1.2 SYSTEM INTEGRITY

This requirement applies as stated in the
TCSEC to every TCB subset that includes hardware or
firmware. Any TCB subset that does not include
hardware or firmware is exempt from this requirement.

C2-3.2 LIFE CYCLE ASSURANCE

C2-3.2.1 SECURITY TESTING

This requirement applies as stated in the
TCSEC to the entire TCB. If a TCB consists of TCB
subsets meeting the conditions for evaluation by parts,
the satisfaction of the requirements by each TCB subset
satisfies the requirement for the entire TCB.
Otherwise, security testing of the entire TCB must be
performed (even if the results of testing the
individual TCB subsets were available).

C2-4 DOCUMENTATION

C2-4.1 SECURITY FEATURES USER'S GUIDE


This requirement applies as stated in the
TCSEC to every TCB subset in the TCB. This collection
of guides must include descriptions of every TCB subset
in the TCB and explicit cross-references to other
related user's guides to other TCB subsets, as
required. In addition, interactions between mechanisms
within different TCB subsets must be clearly described.


C2-4.2 TRUSTED FACILITY MANUAL

This requirement applies as stated in the
TCSEC to the TCB and to every TCB subset in the TCB.

This requirement can be met by providing a
set of manuals, one for each distinct (non-replicated)
TCB subset. Each manual shall address the functions
and privileges to be controlled for the associated TCB
subset. Additionally, it must clearly show the
interfaces to, and the interaction with, more primitive
TCB subsets. The manual for each TCB subset shall
identify the functions and privileges of the TCB
subsets on which the associated TCB subset depends.
Also, the TCB subset's manual shall identify which, if
any, configuration options of the more primitive TCB
subsets are to be used for the composite TCB to operate
securely.

Any pre-defined roles supported (e.g.,
database administrator) by the TCB subset shall be
addressed.

The means for correlating multiple audit logs
and synonymous user identifications from multiple TCB
subsets (if such exist) shall also be addressed.

The trusted facility manual shall describe
the composite TCB so that the interactions among the
TCB subsets can be readily determined. Other manuals
may be referenced in this determination. The manuals
that address the distinct modules of the TCB and the
generation of the TCB need to be integrated with the
other trusted facility manuals only to the extent that
they are affected by the use and operation (versus the
development) of the composite TCB.

C2-4.3 TEST DOCUMENTATION

This requirement applies as stated in the
TCSEC to the composite TCB.


C2-4.4 DESIGN DOCUMENTATION

This requirement applies as stated in the
TCSEC to the composite TCB.

Statement from TCSEC

If the TCB is composed of distinct modules,
the interface between these modules shall be described.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.

CLASS (B1): LABELED SECURITY PROTECTION

B1-1 SECURITY POLICY

B1-1.1 DISCRETIONARY ACCESS CONTROL

The discretionary access control requirements
apply as stated in the TCSEC to every TCB subset whose
policy includes discretionary access control of its
subjects to its objects. Any TCB subset whose policy
does not include such discretionary access control is
exempt from this requirement.

B1-1.2 OBJECT REUSE

This requirement applies as stated in the
TCSEC to every TCB subset in the TCB.

B1-1.3 LABELS

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.


B1-1.3.1 LABEL INTEGRITY

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

B1-1.3.2 EXPORTATION OF LABELED INFORMATION

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

B1-1.4 MANDATORY ACCESS CONTROL

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

B1-2 ACCOUNTABILITY

B1-2.1 IDENTIFICATION AND AUTHENTICATION

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

If the TCB is composed of TCB subsets, one
TCB subset may either rely on a mechanism in another
TCB subset to provide identification and authentication
services or provide the services directly. Similarly,
that TCB subset may rely on a mechanism in another more
primitive TCB subset to ensure that the security level


of subjects external to the TCB that may be created to
act on behalf of the individual user are dominated by
the clearance and authorization of that user. Each TCB
subset may maintain its own identification and
authentication data or one central repository may be
maintained. If each TCB subset has its own data, then
the information for each individual user must be
consistent among all subsets.

B1-2.2 AUDIT

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

A TCB subset may maintain its own security
audit log, distinct from that maintained by more
primitive TCB subsets, or it may use an audit interface
provided by a different TCB subset allowing the audit
records it generates to be processed by that TCB
subset.

If the TCB subset uses different user
identifications than a more primitive TCB subset, there
shall be a means to associate audit records generated
by different TCB subsets for the same individual with
each other, either at the time they are generated or
later.

Statement from TCSEC

The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of access to the objects it protects.

Interpretation

Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of


the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to users. That is, each
discretionary access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.

Statement from TCSEC

The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of accesses to the objects it protects.

Interpretation

Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of
the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to the user. That is, each
discretionary access control policy decision and each
mandatory access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.

B1-3 ASSURANCE

B1-3.1 OPERATIONAL ASSURANCE

B1-3.1.1 SYSTEM ARCHITECTURE

This requirement applies as stated in the
TCSEC to every TCB subset, with the following
additional interpretations.


The TCB must provide domains for execution
that are allocated to and used by TCB subsets according
to the subset-domain condition for evaluation by parts.
A most primitive TCB subset must provide domains for
execution. A less primitive TCB subset must make use
of domains provided by a more primitive TCB subset. A
less primitive TCB subset may provide further execution
domains but is not required to do so.

Similarly, the TCB must provide distinct
address spaces for untrusted processes. A most
primitive TCB subset must provide distinct address
spaces for its subjects. A less primitive TCB subset
must make use of the distinct address space provided by
a more primitive TCB subset. A less primitive TCB
subset may provide more fine-grained distinct address
spaces, but is not required to do so.

Statement from TCSEC

The TCB shall maintain a domain for its own
execution that protects it from external interference
or tampering.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to each TCB subset.

B1-3.1.2 SYSTEM INTEGRITY

This requirement applies as stated in the
TCSEC to every TCB subset that includes hardware or
firmware. Any TCB subset that does not include
hardware or firmware is exempt from this requirement.

B1-3.1 LIFE CYCLE ASSURANCE

B1-3.2.1 SECURITY TESTING

This requirement applies as stated in the
TCSEC to the entire TCB. If a TCB consists of TCB


subsets meeting the conditions for evaluation by parts,
the satisfaction of the requirements by each TCB subset
satisfies the requirement for the entire TCB.
Otherwise, security testing of the entire TCB must be
performed (even if the results of testing the
individual TCB subsets were available).

B1-3.2.2 DESIGN SPECIFICATION AND VERIFICATION

This requirement applies as stated in the
TCSEC to every TCB subset, with the following specific
additional interpretations.

It must be demonstrated that the security
policy enforced by the composite TCB is represented by
the collection of policy models for the individual TCB
subsets.

Statement from TCSEC

An informal or formal model of the security
policy supported by the TCB shall be maintained over
the life cycle of the ADP system and demonstrated to be
consistent with its axioms.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to the security
policy of each TCB subset. An informal argument that
the set of policy models represents the "security
policy supported by the [composite] TCB" must be
provided.

B1-4 DOCUMENTATION

B1-4.1 SECURITY FEATURES USER'S GUIDE

This requirement applies as stated in the
TCSEC to every TCB subset in the TCB. This collection
of guides must include descriptions of every TCB subset
in the TCB and explicit cross-references to other


related user's guides to other TCB subsets, as
required. In addition, interactions between mechanisms
within different TCB subsets must be clearly described.

B1-4.2 TRUSTED FACILITY MANUAL

This requirement applies as stated in the
TCSEC to the TCB and to every TCB subset in the TCB.

This requirement can be met by providing a
set of manuals, one for each distinct (non-replicated)
TCB subset. Each manual shall address the functions
and privileges to be controlled for the associated TCB
subset. Additionally, it must clearly show the
interfaces to, and the interaction with, more primitive
TCB subsets. The manual for each TCB subset shall
identify the functions and privileges of the TCB
subsets on which the associated TCB subset depends.
Also, the TCB subset's manual shall identify which, if
any, configuration options of the more primitive TCB
subsets are to be used for the composite TCB to operate
securely.

Any pre-defined roles supported (e.g.,
database administrator) by the TCB subset shall be
addressed.

The means for correlating multiple audit logs
and synonymous user identifications from multiple TCB
subsets (if such exist) shall also be addressed.

The trusted facility manual shall describe
the composite TCB so that the interactions among the
TCB subsets can be readily determined. Other manuals
may be referenced in this determination. The manuals
that address the distinct modules of the TCB and the
generation of the TCB need to be integrated with the
other trusted facility manuals only to the extent that
they are affected by the use and operation (versus the
development) of the composite TCB.

B1-4.3 TEST DOCUMENTATION


This requirement applies as stated in the TCSEC to the
composite TCB.

B1-4.4 DESIGN DOCUMENTATION

This requirement applies as stated in the
TCSEC to the composite TCB, with the following specific
additional interpretation:

Requirements concerning models and DTLSs
apply to individual TCB subsets.

Statement from TCSEC

If the TCB is composed of distinct modules,
the interface between these modules shall be described.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and the
interfaces between TCB subsets.

Statement from TCSEC

The specific TCB protection mechanisms shall
be identified and an explanation given to show that
they satisfy the model.

Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to each TCB subset and shall
include the protection mechanisms which support the
conditions for TCB subset structure and separate
subset-domains.

CLASS (B2): STRUCTURED PROTECTION

B2-1 SECURITY POLICY

B2-1.1 DISCRETIONARY ACCESS CONTROL


The discretionary access control requirements
apply as stated in the TCSEC to every TCB subset whose
policy includes discretionary access control of its
subjects to its objects. Any TCB subset whose policy
does not include such discretionary access control is
exempt from this requirement.

B2-1.2 OBJECT REUSE

This requirement applies as stated in the TCSEC to
every TCB subset in the TCB.

B2-1.3 LABELS

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

Statement from TCSEC

Sensitivity labels associated with each ADP
system resource . . . that is directly or indirectly
accessible by subjects external to the TCB shall be
maintained by the TCB

Interpretation

Internal TCB variables that are not visible
to untrusted subjects need not be labeled, provided
that they are not directly or indirectly accessible by
subjects external to the TCB. However, it is important
to understand that such internal variables can function
as covert signaling channels when untrusted subjects
are able to detect changes in these variables by
observing system behavior.

B2-1.3.1 LABEL INTEGRITY


This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

B2-1.3.2 EXPORTATION OF LABELED INFORMATION

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include
such mandatory access control is exempt from this
requirement.

B2-1.3.3 SUBJECT SENSITIVITY LABELS

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

B2-1.3.4 DEVICE LABELS

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its objects
and has attached physical or virtual devices. Any TCB
subset whose policy does not include such mandatory
access control or has no attached physical or virtual
devices is exempt from this requirement. This
requirement can be satisifed by the cooperative action
of more than one TCB subset.

B2-1.4 MANDATORY ACCESS CONTROL

This requirement applies as stated in the
TCSEC to every TCB subset whose policy includes
mandatory access control of its subjects to its
objects. Any TCB subset whose policy does not include


such mandatory access control is exempt from this
requirement.

B2-2 ACCOUNTABILITY

B2-2.1 IDENTIFICATION AND AUTHENTICATION

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

If the TCB is composed of TCB subsets, one
TCB subset may either rely on a mechanism in another
TCB subset to provide identification and authentication
services or provide the services directly. Similarly,
that TCB subset may rely on a mechanism in another more
primitive TCB subset to ensure that the security level
of subjects external to the TCB that may be created to
act on behalf of the individual user are dominated by
the clearance and authorization of that user. Each TCB
subset may maintain its own identification and
authentication data or one central repository may be
maintained. If each TCB subset has its own data, then
the information for each individual user must be
consistent among all subsets.

B2-2.1.1 TRUSTED PATH

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

When TCB subsets are used, the requirement
for trusted path at levels B2 and above remains
applicable to the entire TCB. The implementation of
trusted path could be localized in a single TCB subset.
Alternatively, it could be implemented in more than one
TCB subset if the separate implementations together
comply with the system security policy.


B2-2.2 AUDIT

This requirement applies as stated in the
TCSEC to the entire TCB. The cooperative action of the
TCB subsets making up the TCB must satisfy the
requirement.

A TCB subset may maintain its own security
audit log, distinct from that maintained by more
primitive TCB subsets, or it may use an audit interface
provided by a different TCB subset allowing the audit
records it generates to be processed by that TCB
subset.

If the TCB subset uses different user
identifications than a more primitive TCB subset, there
shall be a means to associate audit records generated
by different TCB subsets for the same individual with
each other, either at the time they are generated or
later.

Any TCB subset wherein events may occur that
require notification of the security administrator
shall be able to: (1) detect the occurrence of these
events, (2) initiate the recording of the audit trail
entry, and (3) initiate the notification of the
security administrator. The ability to terminate
events (2) and (3) above may be provided either in the
TCB subset within which they occur, or in the TCB
subset(s) where actions that lead to the event were
initiated.

The monitoring and notification requirements
may require cooperation between multiple distinct TCB
subsets or multiple instantiations of the same TCB
subset. For example, to detect the accumulation of
events for a single user it may be necessary to collect
events from several subjects in distinct processes that
are surrogates for the same user. As another example,
there may be a single TCB subset that collects events
from a number of other TCB subset instantiations and,


based on its analysis of them, notifies the security
administrator.


Statement from TCSEC

The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of accesses to the objects it protects.

Interpretation

Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, inserts), not just the invocation of the
database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to the user. That is, each
discretionary access control policy decision and each
mandatory access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.

Statement from TCSEC

The TCB shall be able to create, maintain,
and protect from modification . . . an audit trail
of accesses to the objects it protects.

Interpretation

Auditable events, in the case of a database
management system, are the individual operations
initiated by untrusted users (e.g., updates,
retrievals, and inserts), not just the invocation of
the database management system. The auditing mechanism
shall have the capability of auditing all mediated
accesses which are visible to the user. That is, each


discretionary access control policy decision and each
mandatory access control policy decision shall be
auditable. Individual operations performed by trusted
software, if totally transparent to the user, need not
be auditable. If the total audit requirement is met by
the use of more than one audit log, a method of
correlation must be available.

B2-3 ASSURANCE

B2-3.1 OPERATIONAL ASSURANCE

B2-3.1.1 SYSTEM ARCHITECTURE

This requirement applies as stated in the
TCSEC to every TCB subset, with the following
additional interpretations.

The TCB must provide domains for execution
that are allocated to and used by TCB subsets according
to the subset-domain condition for evaluation by parts.
A most primitive TCB subset must provide domains for
execution. A less primitive TCB subset must make use
of domains provided by a more primitive TCB subset. A
less primitive TCB subset may provide further execution
domains but is not required to do so.

Similarly, the TCB must provide distinct
address spaces for untrusted processes. A most
primitive TCB subset must provide distinct address
spaces for its subjects. A less primitive TCB subset
must make use of the distinct address space provided by
a more primitive TCB subset. A less primitive TCB
subset may provide more fine-grained distinct address
spaces, but is not required to do so.

In general, requirements specifically
referring to hardware or firmware apply only to TCB
subsets that include hardware or firmware. The
exception is the requirement that the TCB make
effective use of available hardware. This requirement
applies to those TCB subsets that use resources


provided by more primitive TCB subsets in lieu of
hardware. Those TCB subsets are required to make
effective use of the protection-relevant features
exported to it by the more primitive TCB subsets (e.g.,
execution domains, support for distinct address spaces)
to separate those elements that are protection-critical
from those that are not.

Statement from TCSEC

The TCB shall maintain a domain for its own
execution that protects it from external interference
or tampering.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to each TCB subset.

Statement from TCSEC

The user interface to the TCB shall be
completely defined and all elements of the TCB
identified.


Interpretation

If the TCB is composed of multiple subsets,
this requirement applies to the interface between the
TCB subsets as well as the user interface to the whole
TCB.

Statement from TCSEC

It shall make effective use of available
hardware to separate those elements that are
protection-critical from those that are not.

Interpretation


If the TCB is composed of multiple subsets,
each TCB subset must make use of facilities provided to
it by more primitive TCB subsets, such as support for
execution domains and for distinct address spaces, to
achieve the required separation.

B2-3.1.2 SYSTEM INTEGRITY

This requirement applies as stated in the
TCSEC to every TCB subset that includes hardware or
firmware. Any TCB subset that does not include
hardware or firmware is exempt from this requirement.

B2-3.1.3 COVERT CHANNEL ANALYSIS

This requirement applies as stated in the
TCSEC to the entire TCB. When the TCB is made up
entirely of TCB subsets meeting the conditions for
evaluation by parts, analysis of the individual TCB
subsets satisfies this requirement. Otherwise, covert
channel analysis of the entire TCB must be performed
(even if the results of covert channel analysis of the
individual TCB subsets were available).

B2-3.1.4 TRUSTED FACILITY MANAGEMENT

This requirement applies as stated in the
TCSEC to the entire TCB. Any "operator" or
"administrator" functions intrinsic to an individual
TCB subset must be supported by that TCB subset or by a
more primitive TCB subset.

B2-3.2 LIFE CYCLE ASSURANCE

B2-3.2.1 SECURITY TESTING

This requirement applies as stated in the
TCSEC to the entire TCB. If a TCB consists of TCB
subsets meeting the conditions for evaluation by parts,
the satisfaction of the requirements by each TCB subset
satisfies the requirement for the entire TCB.
Otherwise, security testing of the entire TCB must be


performed (even if the results of testing the
individual TCB subsets were available).

B2-3.2.2 DESIGN SPECIFICATION AND VERIFICATION

This requirement applies as stated in the
TCSEC to every TCB subset, with the following specific
additional interpretations.

It must be demonstrated that the
security policy enforced by the composite TCB is
represented by the collection of policy models for the
individual TCB subsets.

The argument that the descriptive top level
specification (DTLS) is consistent with the TCB
interface applies to the entire TCB. There is required
an explicit and convincing description of how the set
of top level specifications (one for each TCB subset)
describes the TCB interface in terms of exceptions,
errors, and effects.

Statement from TCSEC

A formal model of the security policy
supported by the TCB shall be maintained over the life
cycle of the ADP system and demonstrated to be
consistent with its axioms.

Interpretation

If the TCB is composed of multiple TCB
subsets, this requirement applies to the security
policy of each TCB subset. An informal argument that
the set of policy models represents the "security
policy supported by the [composite] TCB" must be
provided.

Statement from TCSEC

A descriptive top-level specification (DTLS)
of the TCB shall be maintained that completely and

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close