Trusted Database Management System Interpretation

NCSC-TG-021

Library

No. S235,625

FOREWORD

The National Computer Security Center is issuing the Trusted Database Management System Interpretation as part of the Technical Guidelines Program, through which we produce the "Rainbow Series."

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

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

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

PATRICK R. GALLAGHER, JR.

April 1991

Director National Computer Security Center

ACKNOWLEDGMENTS

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

FOREWORD i

ACKNOWLEDGMENTS iii

INTRODUCTION 1

HISTORICAL PERSPECTIVE 1

SCOPE 2

PURPOSE 2

STRUCTURE OF THE DOCUMENT 4

PART 1 TECHNICAL CONTEXT 7

TC-1 INTRODUCTION 9

TC-2 REFERENCE MONITOR PERSPECTIVE 10

TC-3 NEED FOR EVALUATION BY PARTS 11

TC-4 TCB SUBSETS 11

TC-4.1 INTRODUCTION 12

TC-4.2 TCB SUBSETS CONTEXT 13

TC-4.2.1 DEFINITION OF TCB SUBSETS 13

TC-4.2.2 MOTIVATION 13

TC-4.3 CONDITIONS FOR EVALUATION BY PARTS 14

TC-4.3.1 CANDIDATE TCB SUBSETS 14

TC-4.3.2 POLICY ALLOCATION 15

TC-4.3.3 TRUSTED SUBJECTS INCLUDED 15

TC-4.3.4 TCB SUBSET STRUCTURE 15

TC-4.3.5 SEPARATE SUBSET-DOMAINS 16

TC-4.3.6 SUPPORT FOR RVM ARGUMENTS 16

TC-4.4 EVALUATION ALTERNATIVES 17

TC-5 GENERAL INTERPRETED REQUIREMENTS 18

TC-5.1 OVERVIEW 18

TC-5.2 DETAILED REQUIREMENTS 18

TC-5.2.1 SECURITY POLICY 18

TC-5.2.1.1 Discretionary Access Control 18

TC-5.2.1.2 Object Reuse 18

TC-5.2.1.3 Labels 19

TC-5.2.1.4 Mandatory Access Control 20

TC-5.2.2 ACCOUNTABILITY 20

TC-5.2.2.1 Identification and Authentication 20

TC-5.2.2.2 Audit 21

TC-5.2.3 ASSURANCE 22

TC-5.2.3.1 Operational Assurance 22

TC-5.2.3.2 Life-Cycle Assurance 23

TC-5.2.4 DOCUMENTATION 24

TC-5.2.4.1 Security Features User's Guide 24

TC-5.2.4.2 Trusted Facility Manual 25

TC-5.2.4.3 Test Documentation 26

TC-5.2.4.4 Design Documentation 26

TC-5.3 SUMMARY OF THE REQUIREMENTS 26

TC-5.3.1 LOCAL REQUIREMENTS 26

TC-5.3.2 GLOBAL REQUIREMENTS 27

TC-6 DESIGN CHOICES 28

TC-6.1 OVERVIEW 28

TC-6.2 A SINGLE TCB SUBSET 28

TC-6.2.1 ANALYSIS OF THE CONDITIONS 28

TC-6.2.1.1 Condition 1: Candidate TCB Subsets 28

TC-6.2.1.2 Condition 2: Policy Allocation 29

TC-6.2.1.3 Condition 3: Trusted Subjects Included 29

TC-6.2.1.4 Condition 4: TCB Subset Structure 29

TC-6.2.1.5 Condition 5: Separate Subset-Domains 29

TC-6.2.1.6 Condition 6: Support for RVM Arguments 29

TC-6.2.2 EVALUATION CONSEQUENCES 29

TC-6.3 TWO TCB SUBSETS,MEETING THE CONDITIONS 30

TC-6.3.1 ANALYSIS OF THE CONDITIONS 30

TC-6.3.1.1 Condition 1: Candidate TCB Subsets 30

TC-6.3.1.2 Condition 2: Policy Allocation 31

TC-6.3.1.3 Condition 3: Trusted Subjects Included 31

TC-6.3.1.4 Condition 4: TCB Subset Structure 31

TC-6.3.1.5 Condition 5: Separate Subset-Domains 31

TC-6.3.1.6 Condition 6: Support for RVM Arguments 31

TC-6.3.2 EVALUATION CONSEQUENCES 32

TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS 33

TC-6.4.1 ANALYSIS OF THE CONDITIONS 34

TC-6.4.1.1 Condition 1: Candidate TCB Subsets 34

TC-6.4.1.2 Condition 2: Policy Allocation 34

TC-6.4.1.3 Condition 3: Trusted Subjects Included 34

TC-6.4.1.4 Condition 4: TCB Subset Structure 35

TC-6.4.1.5 Condition 5: Separate Subset-Domains 35

TC-6.4.1.6 Condition 6: Support for RVM Arguments 35

TC-6.4.2 EVALUATION CONSEQUENCES 35

TC-6.5 SUMMARY 36

PART 2 INTERPRETED REQUIREMENTS 37

IR-1 OVERVIEW AND CONTEXT 39

IR-2 SUMMARY OF THE INTERPRETATIONS 39

IR-2.1 SECURITY POLICY 39

IR-2.1.1 DISCRETIONARY ACCESS CONTROL 39

IR-2.1.2 OBJECT REUSE 40

IR-2.1.3 LABELS 40

IR-2.1.4 MANDATORY ACCESS CONTROL 40

IR-2.2 ACCOUNTABILITY 40

IR-2.2.1 IDENTIFICATION AND AUTHENTICATION 40

IR-2.2.2 AUDIT 40

IR-2.3 ASSURANCE 40

IR-2.3.1 OPERATIONAL ASSURANCE 40

IR-2.3.1.1 System Architecture 40

IR-2.3.1.2 System Integrity 40

IR-2.3.1.3 Covert Channel Analysis 41

IR-2.3.1.4 Trusted Facility Management 41

IR-2.3.1.5 Trusted Recovery 41

IR-2.3.2 LIFE CYCLE ASSURANCE 41

IR-2.3.2.1 Security Testing 41

IR-2.3.2.2 Design Specification and Verification 41

IR-2.3.2.3 Configuration Management 41

IR-2.3.2.4 Trusted Distribution 41

IR-2.4 DOCUMENTATION 42

IR-2.4.1 SECURITY FEATURES USER'S GUIDE 42

IR-2.4.2 TRUSTED FACILITY MANUAL 42

IR-2.4.3 TEST DOCUMENTATION 42

IR-2.4.4 DESIGN DOCUMENTATION 42

IR-3 LABELS 42

IR-3.1 GENERAL DISCUSSION 42

IR-3.2 SPECIFIC INTERPRETATIONS 43

IR-4 AUDIT 44

IR-4.1 GENERAL DISCUSSION 44

IR-4.2 SPECIFIC INTERPRETATIONS 45

IR-5 SYSTEM ARCHITECTURE 47

IR-5.1 GENERAL DISCUSSION 47

IR-5.2 SPECIFIC INTERPRETATIONS 47

IR-6 DESIGN SPECIFICATION AND VERIFICATION 48

IR-6.1 GENERAL DISCUSSION 48

IR-6.2 SPECIFIC INTERPRETATIONS 52

IR-7 DESIGN DOCUMENTATION 55

IR-7.1 GENERAL DISCUSSION 55

IR-7.2 SPECIFIC INTERPRETATIONS 56

APPENDIX A 59

CLASS (C1): 62

C1-1 SECURITY POLICY 62

C1-2 ACCOUNTABILITY 62

C1-3 ASSURANCE 62

C1-4 DOCUMENTATION 63

CLASS (C2): 66

C2-1 SECURITY POLICY 66

C2-2 ACCOUNTABILITY 66

C2-3 ASSURANCE 67

C2-4 DOCUMENTATION 68

CLASS (B1): 70

B1-1 SECURITY POLICY 70

B1-2 ACCOUNTABILITY 71

B1-3 ASSURANCE 73

B1-4 DOCUMENTATION 74

CLASS (B2): 77

B2-1 SECURITY POLICY 77

B2-2 ACCOUNTABILITY 79

B2-3 ASSURANCE 81

B2-4 DOCUMENTATION 85

CLASS (B3): 89

B3-1 SECURITY POLICY 89

B3-2 ACCOUNTABILITY 91

B3-3 ASSURANCE 93

B3-4 DOCUMENTATION 98

CLASS (A1): 102

A1-1 SECURITY POLICY 102

A1-2 ACCOUNTABILITY 104

A1-3 ASSURANCE 106

A1-4 DOCUMENTATION 112

APPENDIX B 117

1. PERSPECTIVE ON ASSURANCE 119

2. PROCUREMENT OPTIONS 120

3. ALTERATION OF PREVIOUSLY EVALUATED TCB 122

4. SATISFYING RVM REQUIREMENTS 125

5. SUBSET DEPENDENCY 127

6. TAMPER RESISTANCE ARGUMENTS 131

7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS 132

8 CONTENT-DEPENDENT AND CONTEXT-DEPENDENT

ACCESS CONTROL 136

9. BULK LOADING OF A DATABASE 137

10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT 137

11. RATING MORE COMPLEX SYSTEMS 139

GLOSSARY 141

BIBLIOGRAPHY 145

INTRODUCTION

HISTORICAL PERSPECTIVE

The Department of Defense Trusted Computer System Evaluation Criteria (TCSEC), published in 1983 as CSC-STD-001-83, consolidates knowledge about the degree of trust one can place in a computer system to protect sensitive information and organizes this knowledge into usable criteria for system evaluation. The TCSEC was republished as a DoD standard, DoD-5200.28-STD, in December 1985 to provide a means of evaluating specific security features and assurances available in "trusted, commercially available automatic data processing system The TCSEC's rating scale extends from a minimal to a high level of trust with advanced security features and sophisticated assurance measures. Specific criteria determine each rating level and guide system builders and evaluators in determining the level of trust provided by specific systems. When the rating levels are combined with environmental guidelines and minimum security protection requirements, accreditation decisions for specific installations can be made.

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

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

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

In June 1986, the National Computer Security Center (NCSC) initiated its efforts to address the

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

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

SCOPE

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

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

PURPOSE

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

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

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

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

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

The latter type of evaluation, that is, one done for the purpose of assessing a system's security attributes with respect to a specific operational mission, is known as a "certification evaluation." A formal product evaluation does not constitute certification or accreditation for the system to be used in any specific application environment. The system security certification and the formal approval/accreditation procedure, done in accordance with the applicable policies of the issuing agencies, must still be followed before a system can be approved for use in processing or handling sensitive or classified information. Designated Approving Authorities (DAAs) remain ultimately responsible for specifying the security of systems they The TCSEC and this Interpretation will be used directly and indirectly in the certification process. Along with applicable policy, they will be used directly as technical guidance for evaluation of the total system and for specifying system security and certification requirements for new acquisitions. Where a system being evaluated for certification employs a product that has undergone a formal product evaluation, reports from that process will be used as input to the certification evaluation. Moreover, the National Security Agency plans to publish additional guidelines to assist certifiers and help ensure consistency in certifications of systems processing national security informantion.

STRUCTURE OF THE DOCUMENT

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

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

PART 2, INTERPRETED REQUIREMENTS, "provides interpretions of those TCSEC requirements that are either specific to DBMSs (or applications in general), or are particularly relevant to DBMSs. The number of requirements that are treated explicitly is relatively small, because many of the TCSEC requirements apply as stated to database management systems. The requirements treated explicitly are labels, audit, system architecture, design specification and verification, and design documentation.

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

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

PART 1 TECHNICAL CONTEXT

TC-1 INTRODUCTION

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

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

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

PART 1, "TECHNICAL CONTEXT," is divided into six sections. Section TC-2, "Reference Monitor Perspective," summarizes the role of the reference monitor concept in both the TCSEC and the assessing of a system for its trust characteristics. Section TC-3, "Need for Evaluation by Parts," deals with the need to extend the reference monitor perspective slightly to begin to address the evaluation of systems constructed of separate parts. Section TC-4, "TCB Subsets," is the heart of PART 1. That section introduces a conservative extension to the reference validation mechanism, TCB subsets. This extension provides the basis for being able to undertake evaluation of systems built in parts in a way that allows re-use of the results of separate evaluations (whether those evaluations were performed before the current evaluation was begun or whether the separate evaluations overlap in time). Section TC-5, "General Interpreted Requirements," outlines the application of the TCSEC requirements to individual TCB subsets when an evaluation by parts is being done. Section TC-6, "Design Choices" describes the general process of applying TCB subsets and meeting the conditions for evaluation by parts. The treatment in this section is general and not limited to DBMSs; DBMS-specific issues are discussed in the appendices.

TC-2 REFERENCE MONITOR PERSPECTIVE

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

For convenience, these evaluation criteria use the term Trusted Computing Base to refer to the reference validation mechanism, beit a security kernel, front-end security filter, or the entire trusted computer system. [8, p. 67] Even in those lower classes (below B2) where the reference monitor concept and reference validation mechanisms are not mentioned explicitly, the perspective of the reference monitor and its implementation as a reference validation mechanism is present. Specifically, there are requirements for (1) identifying the policy being enforced, (2) identifying subjects and objects, (3) providing evidence that the operation of the reference validation mechanism matches the high-level description of the user interface, and (4) demonstrating isolation of the TCB.

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

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

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

TC-3 NEED FOR EVALUATION BY PARTS

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

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

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

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

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

In this circumstance of needing to be able to accommodate evaluation of a system built in parts and the lack of consensus about how this can be done in a technically sound fashion, a conservative approach must be adopted. The following are required: (1) a clear description of what "parts" will be considered for separate evaluation; (2) a clear description of the conditions under which such an evaluation by parts will be undertaken; and (3) a general interpretation of TCSEC requirements as they would apply when a system is being evaluated by parts. The "parts" that will be considered by separate evaluation are called "TCB subsets," the topic of Section TC-4 below.

TC-4 TCB SUBSETS

TC-4.1 INTRODUCTION

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

TC-4.2 TCB SUBSETS CONTEXT

TC-4.2.1 DEFINITION OF TCB SUBSETS

A TCB subset M is a set of software, firmware, and hardware (where any of these three could be absent) that mediates the access of a set S of subjects to a set O of objects on the basis of a stated access control policy P and satisfies the properties:

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

M uses resources provided by an explicit set of more primitive TCB subsets to create the objects of O, create and manage its data structures, and enforce the policy P. If there are no TCB subsets more primitive than M, then M uses only hardware resources to instantiate its objects, to create and manage its own data structures, and to enforce its policy.
The above definition does not explicitly prohibit an access control policy P that allows trusted subjects. The implications for the evaluation process when a TCB subset's policy allows or does not allow such trusted subjects are substantial and are discussed in Section TC-6.4. As described in TC-4.3, one of the conditions for an evaluation by parts of a TCB made up of TCB subsets is that all the trusted subjects of each TCB subset be included in that TCB subset.

TC-4.2.2 MOTIVATION

The definition of "TCB subset" is intended to parallel the definitions of the reference monitor and reference validation mechanism found in the Anderson report [1] and included in the TCSEC itself. "The term Trusted Computing Base [refers] to the reference validation mechanism, be it security kernel, front-end security filter, or the entire trusted computer system." [8, p. 67] "TCB subset" is defined exactly like a reference validation mechanism, with only one difference, that it does not necessarily extend to the hardware. Rather, a TCB subset uses either hardware resources or the resources provided by other, more primitive TCB subsets. Thus TCB subsets build on abstract machines, either physical hardware machines or other TCB subsets. Just like reference validation mechanisms, a TCB subset must enforce a defined access control policy.

TC-4.3 CONDITIONS FOR EVALUATION BY PARTS

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

The candidate TCB subsets are identified;

The system policy is allocated to the candidate TCB subsets;

Each candidateTCB subset M[i] includes all the trusted subjects with respect to its technical policies P[i];

The TCB subset structure or architecture is explicitly described;

Each TCB subset occupies distinct subset-domains; and

The more primitive TCB subsets provide support for the RVM arguments for less primitve TCB subsets.

These conditions are described below.

TC-4.3.1 CANDIDATE TCB SUBSETS

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

TC-4.3.2 POLICY ALLOCATION

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

TC-4.3.3 TRUSTED SUBJECTS INCLUDED

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

TC-4.3.4 TCB SUBSET STRUCTURE

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

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

More precisely, for a candidate TCB subset M, let sM denote the specification of M. The specification will include, as a minimum, the statement of the technical policy P of M. Further, let vM denote the (engineering) demonstrations of the correctimplementation of M with respect to its specification.

A (candidate) TCB subset A depends (for its correctness)" on (candidate) TCB subset B if and only if the arguments of vA assume, wholly or in part, that sB has been implemented correctly. (See Appendix B, item 5 for additional discussion.)

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

TC-4.3.5 SEPARATE SUBSET-DOMAINS

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

A subset-domain is a set of system domains.

Each candidate TCB subset must occupy a distinct subset-domain such that modify-access to a TCB subset's subset-domain is permitted only to that TCB subset and (possibly) to more primitive TCB subsets. This requirement ensures that the structure of subset-domains with respect to access is consonant with the dependency relation among TCB subsets.

TC-4.3.6 SUPPORT FOR RVM ARGUMENTS

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

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

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

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

TC-4.4 EVALUATION ALTERNATIVES

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

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

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

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

TC-5 GENERAL INTERPRETED REQUIREMENTS

TC-5.1 OVERVIEW

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

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

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

TC-5.2 DETAILED REQUIREMENTS

TC-5.2.1 SECURITY POLICY

TC-5.2.1.1 Discretionary Access Control

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

TC-5.2.1.2 Object Reuse

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

TC-5.2.1.3 Labels

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

Label Integrity

Exportation of Labeled Information

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

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.

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

System Integrity

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

Covert Channel Analysis

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

Trusted Facility Management

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

Trusted Recovery

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

TC-5.2.3.2 Life-Cycle Assurance

Security Testing

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

Design Specification and Verification

This requirement applies as stated in the TCSEC to every TCB subset, with the following specific additional interpretations. It must be demonstrated that the securitypolicy enforced by the composite TCB is represented by the collection of policy models for the individual TCB subsets.

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

Configuration Management

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

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

Trusted Distribution

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

TC-5.2.4 DOCUMENTATION

TC-5.2.4.1 DOCUMENTATION

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

TC-5.2.4.2 Trusted Facility Manual

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

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

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

The means for correlating multiple audit logs and synonymous user identifications from multiple TCB subsets (if such exist) shall also be addressed. The trusted facility manual shall describe the composite TCB so that the interactions among the TCB subsets can be readily determined. Other manuals may be referenced in this determination. The manuals that address the distinct modules of the TCB and the generation of the TCB need to be integrated with the other trusted facility manuals only to the extent that they are affected by the use and operation (versus the development) of the composite TCB.

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

TC-5.2.4.3 Test Documentation

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

TC-5.2.4.4 Design Documentation

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

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

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

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

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

TC-5.3 SUMMARY OF THE REQUIREMENTS

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

TC-5.3.1 LOCAL REQUIREMENTS

	Discretionary Access Control;
	Object Reuse;
	Labels (except Subject Sensitivity Labels);
	Mandatory Access Control;
	System Architecture (except domains for

execution and distinct address spaces);

System Integrity;
Configuration Management;
Security Features User's Guide;
Design Documentation
models,
DTLSs,
FTLSs, and
non-FTLS internals.

TC-5.3.2 GLOBAL REQUIREMENTS

Subject Sensitivity Labels;

Identification and Authentication;

Trusted Path;

Audit;

System Architecture domains for execution, and distinct address spaces;

Covert Channel Analysis;

Trusted Facility Management;

Trusted Recovery (also applies to

individual TCB subsets); Security Testing; Design Specification and Verification correspondence between system policy and the set of TCB subset models consistency of TCB interface with the

set of TCB subset DTLSs, and consistency ofTCB interface with the set of TCB subset FTLSs; Trusted Distribution; Trusted Facility Manual (also applies to individual TCB subsets);

Test Documentation; and Design Documentation (except models, DTLSs, FTLSs, and non-FTLS internals).

TC-6 DESIGN CHOICE

TC-6.1 OVERVIEW

This section examines the several design choices available for constructing systems in parts and the consequences of each when attempting to perform an evaluation by parts. The first case described is that of a TCB evaluated under the TCSEC without benefit of TCB subset structuring. This case is of value for several reasons: it serves as a reference point; it can be considered the degenerate case of subsetting; and it is always an option to evaluate any TCB, regardless of internal structure, as a monolith. The second and third cases are presented in terms of a

configuration of exactly two subsets; the

generalization to more than two TCB subsets is

straightforward. The second case is that of a

subsetted architecture that exactly satisfies the

conditions for evaluation by parts. The third case represents a special case of an altered TCB, one which is implemented using trusted subjects.

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

However, evaluation by parts is intended to allow the

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

TC-6.2 A SINGLE TCB SUBSET

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

TC-6.2.1 ANALYSIS OF THE CONDITIONS

TC-6.2.1.1 Condition 1: Candidate TCB Subsets

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

TC-6.2.1.2 Condition 2: Policy Allocation

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

TC-6.2.1.3 Condition 3: Trusted Subjects Included

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

TC-6.2.1.4 Condition 4: TCB Subset Structure

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

TC-6.2.1.5 Condition 5: Separate Subset-Domains

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

TC-6.2.1.6 Condition 6: Support for RVM Arguments

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

TC-6.2.2 EVALUATION S CONSEQUENCE

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

TC-6.3 TWO TCB SUBSETS, MEETING THE CONDITIONS

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

TC-6.3.1 ANALYSIS OF THE CONDITIONS

TC-6.3.1.1 Condition 1: Candidate TCB subsets

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

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

TC-6.3.1.2 Condition 2: Policy Allocation

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

TC-6.3.1.3 Condition 3: Trusted Subjects included

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

TC-6.3.1.4 Condition 4: TCB Subset Structure

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

TC-6.3.1.5 Condition 5: Separate Subset-Domains

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

TC-6.3.1.6 Condition 6: Support for RVM Arguments

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

TC-6.3.2 EVALUATION CONSEQUENCES

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

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

Demonstrating that the candidate system meets the TCSEC requirements (as they apply to the target evaluation class) requires that both A and B be evaluated with respect to the local requirements of the target class and that the composite TCB be evaluated for global requirements. In this case, full testing of TCB subset A against all the requirements (both local and global) simplifies the task of demonstrating satisfaction of the global requirements, both for B and for the entire TCB.

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

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

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

TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS

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

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

TC-6.4.1 ANALYSIS OF THE CONDITIONS

TC-6.4.1.1 Condition 1: Candidate TCB Subsets

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

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

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

TC-6.4.1.2 Condition 2: Policy Allocation

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

TC-6.4.1.3 Condition 3: Trusted Subjects

Included This condition is not satisfied because D includes at least one subject that is trusted with respect to C. Hence a subject that is trusted with respect to the policy of C is outside C, and evaluation by parts is not an option. If TCB subset C had previously been evaluated, then this is an example of an altered TCB, albeit a special case. The change consists of the addition of one or more trusted C-subjects in D whose effect on the behavior of C cannot be predicted a priori. An assessment of the impact of D on the behavior of C cannot be made strictly by an examination of the trusted subjects and the definition of C's interface. A global assessment of C and D is required.

TC-6.4.1.4 Condition 4: TCB Subset Structure

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

TC-6.4.1.5 Condition 5: Separate Subset-Domains

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

TC-6.4.1.6 Condition 6: Support for RVM Arguments

TC-6.4.2 EVALUATION CONSEQUENCES

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

TC-6.5 SUMMARY

The three cases described above illustrate the effects of various TCB subsetting situations as they relate to the evaluation requirements. A monolithic evaluation proceeds exactly as described in the TCSEC, with requirements being applied to the entire TCB. When all the conditions for evaluation by parts are satisfied, considerable savings in evaluation effort are realized. The evaluation of a new system configuration that includes exactly the same TCB subset that was previously evaluated (such as the TCB subsets A and B in the Section TC-6.3) is limited to (a) local analysis of the individual TCB subsets (by reference to earlier analysis, if available) and (b) a simpler global analysis, because each TCB subset is an exact analog of a TCB.

When the conditions for evaluation by parts are not satisfied, no general statements can be made about the factorability of analysis or the reusability of previous analysis. The extent to which previous evaluation evidence and results remain valid can be determined only on a case-by-case basis.

PART 2 INTERPRETED REQUIREMENTS

IR-1 OVERVIEW AND CONTEXT

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

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

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

IR-2 SUMMARY OF THE INTERPRETATIONS

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

In the database context, the set of candidates for "subject" and "object" can be larger than normally encountered in trusted operating systems. Where a database system builds on an underlying trusted operating system, for example, the set of candidate subjects for the two TCB subsets includes both the active entities created by the operating system and those active entities created by the trusted portion of the DBMS. The set of candidates for objects is large.

Examples are files, segments, buffers, structures, pages, relations, tables, tuples, rows, columns, elements, entities, relationships, procedures, metadata, system tables, query trees, query plans, locking mechanisms, rollback mechanisms, indices, recovery and backupmechanisms, precalculated operations (such as joins), view definitions, view instantiations, constraints, authorization tables, data dictionary tables, and audit logs.

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

In the case of multiple TCB subsets, the intent is the same. Tracing all policy requirements to

the actual system implementation must be possible, and vice versa. The current dilemma is that the theory and techniques for subdividing a model into a set of models (or a top level specification into a set of top level specifications) have not yet been established. Likewise neither theory or techniques have been established for composing a set of models or top level specifications into a unified model or top level specification. The absence of rigorous methods does not preclude an evaluation using a subsetted TCB.

The process of mapping policy to implementation is possible for each TCB subset, using the same techniques required for a monolithic TCB. For subsetted TCBs, designers and evaluators must explicitly show how the policy, model and specifications for each TCB subset meet the TCSEC requirements. In addition, convincing informal arguments must be given to show how the collection of TCB subsets enforces the policy of the composite TCB.

Because morerigorous composition methods are unavailable, convincing informal arguments are appropriate for evaluation of TCBs up to and including Class A1.

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

The allocation of policy to the TCB subsets,

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

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

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

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

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

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

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

IR-6.2 SPECIFIC INTERPRETATIONS

CLASS (B1): LABELED SECURITY PROTECTION

Statement from TCSEC

An informal or formal model of the security

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

Interpretation

If the TCB is composed of multiple TCB

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

CLASS (B2): STRUCTURED PROTECTION

Statement from TCSEC

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

Interpretation

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

C1-1.1 DISCRETIONARY ACCESS CONTROL

C1-2 ACCOUNTABILITY

C1-2.1 IDENTIFICATION AND AUTHENTICATION

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

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

C1-3 ASSURANCE

C1-3.1 OPERATIONAL ASSURANCE

C1-3.1.1 SYSTEM ARCHITECTURE

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

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

Statement from TCSEC

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

Interpretation

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

C1-3.1.2 SYSTEM INTEGRITY

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

C1-3.2 LIFE CYCLE ASSURANCE

C1-3.2.1 SECURITY TESTING

C1-4 DOCUMENTATION

C1-4.1 SECURITY FEATURES USER'S GUIDE

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.

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

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.

Statement from TCSEC

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

Interpretation

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

C2-3 ASSURANCE

C2-3.1 OPERATIONAL ASSURANCE

C2-3.1.1 SYSTEM ARCHITECTURE

This requirement applies as stated in the TCSEC to every TCB subset, with the following additional interpretations. The TCB must provide domains for execution that are allocated to and used by TCB subsets according to the subset-domain condition for evaluation by parts. A most primitive TCB subset must provide domains for execution. A less primitive TCB subset must make use of domains provided by a more primitive TCB subset. A less primitive TCB subset may provide further execution domains but is not required to do so.

Statement from TCSEC

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

Interpretation

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

C2-3.1.2 SYSTEM INTEGRITY

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

C2-3.2 LIFE CYCLE ASSURANCE

C2-3.2.1 SECURITY TESTING

C2-4 DOCUMENTATION

C2-4.1 SECURITY FEATURES USER'S GUIDE

C2-4.2 TRUSTED FACILITY MANUAL

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.

B1-3.2.1 SECURITY TESTING

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

B1-4.2 TRUSTED FACILITY MANUAL

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.

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

CLASS (B2): STRUCTURED PROTECTION

B2-1 SECURITY POLICY

B2-1.1 DISCRETIONARY ACCESS CONTROL

B2-1.2 OBJECT REUSE

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

B2-1.3 LABELS

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

B2-1.3.1 LABEL INTEGRITY

B2-1.3.2 EXPORTATION OF LABELED INFORMATION

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

B2-1.4 MANDATORY ACCESS CONTROL

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.

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.

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.

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.

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

B2-3.1.4 TRUSTED FACILITY MANAGEMENT

B2-3.2 LIFE CYCLE ASSURANCE

B2-3.2.1 SECURITY TESTING

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.

B2-4.1 SECURITY FEATURES USER'S GUIDE

B2-4.2 TRUSTED FACILITY MANUAL

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.

B2-4.3 TEST DOCUMENTATION

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

B2-4.4 DESIGN DOCUMENTATION

This requirement applies as stated in the TCSEC to the composite TCB, with the following specific addditional interpretations. Requirements concerning models and DTLSs apply to individual TCB subsets. The requirement concerning the description of interfaces between modules of the TCB includes the interfaces between TCB subsets. The documentation of the implementation of a reference validation mechanism must include justification for meeting the conditions for evaluation by parts.

Statement from TCSEC

The interfaces between the TCB modules shall be described.

Interpretation

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

Statement from TCSEC

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

Interpretation

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

Statement from TCSEC

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

Interpretation

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

Statement from TCSEC

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

Interpretation

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

CLASS (B3): SECURITY DOMAINS

B3-1 SECURITY POLICY

B3-1.1 DISCRETIONARY ACCESS CONTROL

B3-1.2 OBJECT REUSE

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

B3-1.3 LABELS

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

B3-1.3.1 LABEL INTEGRITY

B3-1.3.2 EXPORTATION OF LABELED INFORMATION

B3-1.3.3 SUBJECT SENSITIVITY LABELS

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

B3-1.3.4 DEVICE LABELS

B3-1.4 MANDATORY ACCESS CONTROL

B3-2 ACCOUNTABILITY

B3-2.1 IDENTIFICATION AND AUTHENTICATION

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

B3-2.1.1 TRUSTED PATH

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

B3-2.2 AUDIT

This requirement applies as stated in the TCSEC to the entire TCB. The cooperative action of the TCB subsets making up the TCB must satisfy the requirement. A TCB subset may maintain its own security audit log, distinct from that maintained by more primitive TCB subsets, or it may use an audit interface provided by a different TCB subset allowing the audit records it generates to be processed by that TCB subset. If the TCB subset uses different user identifications than a more primitive TCB subset, there shall be a means to associate audit records generated by different TCB subsets for the same individual with each other, either at the time they are generated or at some later time.

B3-3.1.2 SYSTEM INTEGRITY

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

B3-3.1.3 COVERT CHANNEL ANALYSIS

B3-3.1.4 TRUSTED FACILITY MANAGEMENT

B3-3.1.5 TRUSTED RECOVERY

B3-3.2 LIFE CYCLE ASSURANCE

B3-3.2.1 SECURITY TESTING

Otherwise, security testing of the entire TCB must be performed (even if the results of testing the individual TCB subsets were available).

B3-3.2.2 DESIGN SPECIFICATION AND VERIFICATION

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

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

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

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.

Statement from TCSEC

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

Interpretation

Statement from TCSEC

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

Interpretation

B3-3.2.3 CONFIGURATION MANAGEMENT

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

B3-4 DOCUMENTATION

B3-4.1 SECURITY FEATURES USER'S GUIDE

B3-4.2 TRUSTED FACILITY MANUAL

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.

B3-4.3 TEST DOCUMENTATION

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

B3-4.4 DESIGN DOCUMENTATION

This requirement applies as stated in the TCSEC to the composite TCB, with the following addtional specific interpretations Requirements concerning models and DTLSs apply to individual TCB subsets. The requirement concerning the description of interfaces between modules of the TCB includes the interfaces between TCB subsets. The documentation of the implementation of a reference validation mechanism must include justification for meeting the conditions for evaluation by parts.

Statement from TCSEC

The interfaces between the TCB modules shall be described.

Interpretation

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

Statement from TCSEC

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

Interpretation

Statement from TCSEC

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

Interpretation

Statement from TCSEC

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

Interpretation

If the TCB is composed of multiple TCB subsets, this requirement is interpreted to apply to each TCB subset with respect to its specific technical policy. In addition, there must be documented an informal argument that the cooperative action of the TCB subsets makes the TCB itself tamper resistant, non-bypassable, and correct.

Statement from TCSEC

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

Interpretation

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

Statement from TCSEC

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

Interpretation

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

CLASS (A1): VERIFIED DESIGN

A1-1 SECURITY POLICY

A1-1.1 DISCRETIONARY ACCESS CONTROL

A1-1.2 OBJECT REUSE

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

A1-1.3 LABELS

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

A1-1.3.1 LABEL INTEGRITY

A1-1.3.2 EXPORTATION OF LABELED INFORMATION

A1-1.3.3 SUBJECT SENSITIVITY LABELS

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

A1-1.3.4 DEVICE LABELS

A1-1.4 MANDATORY ACCESS CONTROL

A1-2 ACCOUNTABILITY

A1-2.1 IDENTIFICATION AND AUTHENTICATION

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

A1-2.1.1 TRUSTED PATH

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

A1-2.2 AUDIT

Statement from TCSEC

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

Interpretation

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

Statement from TCSEC

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

Interpretation

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

A1-3 ASSURANCE

A1-3.1 OPERATIONAL ASSURANCE

A1-3.1.1 SYSTEM ARCHITECTURE

This requirement applies as stated in the TCSEC to every TCB subset, with the following additional interpretations.The TCB must provide domains for execution that are allocated to and used by TCB subsets according to the subset-domain condition for evaluation by parts. A most primitive TCB subset must provide domains for execution. A less primitive TCB subset must make use of domains provided by a more primitive TCB subset. A less primitive TCB subset may provide further execution domains but is not required to do so.

A1-3.1.2 SYSTEM INTEGRITY

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

A1-3.1.3 COVERT CHANNEL ANALYSIS

A1-3.1.4 TRUSTED FACILITY MANAGEMENT

A1-3.1.5 TRUSTED RECOVERY

A1-3.2 LIFE CYCLE ASSURANCE

A1-3.2.1 SECURITY TESTING

Otherwise, security testing of the entire TCB must be performed (even if the results of testing the individual TCB subsets were available).

A1-3.2.2 DESIGN SPECIFICATION AND VERIFICATION

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

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

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

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

Interpretation

Statement from TCSEC

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

Interpretation

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

A1-3.2.3 CONFIGURATION MANAGEMENT

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

A1-3.2.4 TRUSTED DISTRIBUTION

A1-4 DOCUMENTATION

A1-4.1 SECURITY FEATURES USER'S GUIDE

A1-4.2 TRUSTED FACILITY MANUAL

A1-4.3 TEST DOCUMENTATION

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

A1-4.4 DESIGN DOCUMENTATION

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

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

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

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

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

Statement from TCSEC

The interfaces between the TCB modules shall be described.

Interpretation

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

Statement from TCSEC

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

Interpretation

Statement from TCSEC

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

Interpretation

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

Statement from TCSEC

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

Interpretation

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

Statement from TCSEC

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

Interpretation

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

Statement from TCSEC

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

Interpretation

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

APPENDIX B

GENERAL ITEMS

1. PERSPECTIVE ON ASSURANCE

This Trusted Database Management System Interpretation (TDI) of the Trusted Computer System Evaluation Criteria (TCSEC) derives its perspective on assurance directly from the reference monitor concept as recorded in the Anderson Report [1] and as embodied in the TCSEC. In both the reference monitor concept and in the TCSEC, the assessment of a system for trust characteristics involves a single, global review of the system at issue. That same perspective of an even, global review of a candidate trusted database management system (DBMS) is present in the TDI, in that only complete systems will be considered for assessment. That is, neither software packages in isolation nor systems that satisfy only a subset of the TCSEC. requirements will be considered for evaluation or accreditation. The interpretation of requirements, both in Part 1, "Technical Context," and Part 2, "Interpreted Requirements," is consistent with both community experience in designing and assessing trusted systems, and the precedents of the reference monitor concept and the TCSEC. The interpretations, therefore, provide special guidance for the task of evaluating (or accrediting) candidate systems composed of distinguishable parts. However, the interpretations neither attenuate nor delete TCSEC requirements.

It is worth noting that the introduction of the TCSEC with its metric for the evaluation of whole systems had as one goal the simplification of the task of accrediting computer systems for use in the processing of sensitive information. The evaluation process was not intended to replace the accreditation process but to provide input to that process. It must be recognized that there will be occasions when a fielded suite of computer systems, each evaluated against the TCSEC requirements at a particular class, will not be able to be assigned a TCSEC class, nor is it necessary to be able to make such an assignment. The accreditation decision includes the assessment of risk of a particular system configuration in a particular environment; a decision to connect a suite of TCSEC evaluated systems may have to be made without a uniformly applied TCSEC-like assessment over the entire system.

2. PROCUREMENT OPTIONS

The Trusted Computing System Evaluation Criteria (TCSEC) and its published interpretations, including this Trusted Database Management System Interpretation, have as a primary purpose the "provision [of] a basis for specifying security requirements in acquisition specifications." [8, p. 2] In the area of trusted DBMS and trusted systems that include database management functionality, there is a range of options open to an acquisition organization. These options need to be understood by the acquisition managers and their staffs to allow them the greatest possible flexibility in matching operational requirements with a combination of available products and the state of the art in system integration and development.

The fundamental point is the distinction between the target trust class (that is, C1, C2, B1, B2, B3, or A1) needed for a particular installation and the degree of trusted DBMS functionality that is required. Succinctly, a system that requires a particular level of trust (B2, for example) and DBMS functionality does not necessarily require an evaluated trusted DBMS at the level of B2. In fact, if the statement of required capability allows it, meeting the requirement without a trusted DBMS could well be the preferred risk-reducing approach. This is generally true because the more sophisticated the trusted DBMS requirement, the more likely it is that the current vendor base will not be able to supply the needed functionality (with the requisite assurance) from the normal product line. Further, even if one can specify carefully just what additional assured capability is needed so that a program-specific development can be undertaken, the lack of community experience and consensus on advanced trusted DBMS issues and implementations introduces the potential for

significant programmatic, schedule, and cost risks.

Although a full description of options for the acquisition manager is beyond the scope of this document, a representative description of some of the options that could be considered is included below. The options include (1) multiple copies of a DBMS running at different levels, each maintaining single-level databases; (2) a single copy of a DBMS, but with each database maintained at a single sensitivity level (i.e., no sharing of data between databases); (3) a single copy supporting single level databases, but with limited sharing, perhaps of a "snapshot" nature; and (4) DBMSs that allow databases that include data of several sensitivity levels. This option admits of subcases from the very simple to the very complex.

To illustrate the options listed above, consider a command post where a commander's staff uses a single computer system. Included on the staff are logistics, weather, and intelligence organizations, each dealing with information of differing (maximum) sensitivity. If all three organizations require similar DBMS functions, there might be a variety of ways to provide that functionality.

(1) If the product DBMS-1 suited the needs of each of the organizations and there were no requirement to share data between them, then three copies of DBMS-1 could be used, running at, for example, TOP SECRET, SECRET, and CONFIDENTIAL, respectively, and maintaining separate single-level databases. If the organizational missions do not require multilevel operations or sharing, this option could be perfectly suited to the operational need. In this case, every copy of DBMS-1 would be running as an application outside the TCB and would not have to be evaluated at all, neither as a product nor as a developed system. The advantages of this option are that commercial, off-the-shelf systems can be used (both the DBMS and the underlying trusted operating system) and no evaluation risk is entailed.

The disadvantages are the limited flexibility and the hidden fact that the installation procedures for many DBMSs require the insertion of code into the heart of the underlying computer system, insertions that would undermine the evaluation rating and thus theconfidence in the trusted operating system.

(2) A cost advantage could be realized in the preceding case if there were a product, DBMS-2, such that a single copy could provide DBMS functionality at all three levels. This capability requires that the base trusted operating system and the DBMS itself are designed so that the DBMS code uses scratch space to allow the code to be shared without the potential for mixing control or metadata in workspaces, indices, and stacks. Not all commercial DBMSs have this property, so this option will be less available than case (1). Note that in this case also, the databases themselves are single-level and the workspace used by the DBMS itself will have to be single-level.

(3) If the operational requirements are that the intelligence and logistics organizations must have access to the weather data maintained by the weather organization, the simplest technical solution would be to periodically provide a snapshot of the needed weather data for use by the other organizations. The database management system DBMS-2 above could provide a solution in this case if a portion of the weather database could be copied onto diskette (or even into another file) for the other organizations to incorporate into their own DBMS operations. The disadvantage of this approach is that the information will not be as current as that available to the weather organization itself. Frequently, however, that lack of currency may be a reasonable price to pay for the enormous reductions in cost and risk in procurement and maintenance.

(4) If the operational requirements will not allow anything less than real-time sharing of information, then DBMS-2 will not be sufficient. At this point, the operational requirements have forced the inclusion of the most sophisticated solution to a trusted system with DBMS requirements, a true multilevel DBMS. In this case, it remains a valuable goal to minimize the complexity of the needed sharing. If the DBMS is providing a functionality that looks like tables to the user, then it is less complex if each table is at a single level than if each row (or each column) could be at a different sensitivity level. The most complex situation is when each entry in the table could be at a different sensitivity level. During the procurement and development process, it would be worthwhile to structure the procurement to favor solutions that are as simple as possible from a multilevel trusted DBMS standpoint.

3. ALTERATION OF PREVIOUSLY EVALUATED TCB

The discussion in Part 1, "Technical Context" arose from consideration of the conditions under which it is possible to add an application layer, such as a DBMS, to another TCB in such a way as to allow the system rating to be determined by evaluating the system elements (i.e., the subsets) separately. The benefit to both the applications vendor and the evaluators derives from the fact that the DBMS operates as an untrusted subject relative to the underlying TCB (even though the DBMS enforces its own policy). Therefore, there is no need to re-examine previous evaluation evidence; any and ll actions performed by the application layer are completely constrained in accordance with the security policy defined for the underlying TCB.

The savings in evaluation effort is predicated on the assumption that the vendor of the application layer makes no changes of any kind to the other TCB. In effect, the argument made by the vendor is as follows:

(a) The underlying TCB enforces policy P[i].

The validity of the claims about the underlying TCB has already been established, and these claims remain valid because the underlying TCB has not been altered in any way and because the DBMS is completely constrained by that policy (i.e., P[i] cannot be violated by any action of the DBMS).

(b) The application is a TCB subset which enforces policy P[k]

Thus, the policy enforced by the composite system (i.e., the policy enforced at the user interface of the composite TCB) is merely a combination of the policies of the individual TCB subsets.

Because there is neither theory nor experience which allows one to make general, a priori statements about the effects of arbitrary changes, any alterations to a previously evaluated product must, in general, be considered to result in a product whose security attributes, and thus whose rating, is unknown. Thus, if the previously evaluated product is altered, argument (a) cannot be made merely by referencing the published evaluation report. It becomes the responsibility of the DBMS vendor to state P[i] (i.e., identify the policy enforced by the altered product) and to demonstrate that the implementation satisfies the appropriate TCSEC requirements. Hence, at least some evaluation evidence focused on the underlying TCB must be provided by the vendor of the application layer. The amount of evidence required will be determined by the type, extent, and amount of change, as well as the characteristics of the original TCB.

This is not to say, however, that changes always invalidate all previous evaluation evidence. Rather, that there is no way to predict what effect arbitrary change will have on that evidence. Clearly, some changes will invalidate a substantial part, if not all, of the previous evaluation results, requiring a completely new evaluation. In some cases it will be virtually impossible to determine the full effect of even relatively simple changes, whereas in other instances it may be possible to determine the effects of at least some changes quite precisely. In a well-modularized system, changes to the internals of a module might be shown to have no functional or security effect outside of the module. Even changes to the module that alter its interface might be shown to have effects which do not propagate beyond those modules which have a direct interface to the altered module.

In either case however, at least some evidence must be produced about the underlying, altered TCB. Thus, the vendor who alters the product which is hosting his application becomes responsible for any and all evidence required to substantiate the claims being made for both the application and the underlying TCB.

In fact, it is always the case that the DBMS vendor is responsible for all the evidence required to demonstrate that the system (i.e., the trusted components of the application plus the underlying TCB) has the level of trust claimed for it. In the case of strict subsetting for evaluation by parts, in which the application is layered onto an unaltered, previously-evaluated TCB, part of the evidence is satisfied by referencing the previous evaluation results and the commercially-available specifications for that portion of the system. However, if the previously evaluated TCB has been altered, the applications vendor is now responsible for demonstrating that the underlying TCB has the level of trust being claimed for it. How much, if any, of the previous evaluation evidence is still valid is a matter to be resolved.

The development of the subsetting notion has been motivated by the need for evaluating systems whose elements may have been developed by different vendors. Consequently, the discussion of TCB subsets has been largely focused on the topic of extending the policy enforcement attributes of previously evaluated TCBs. However, the notion of TCB subsetting provides a perfectly general design method. A TCB can be structured and policy enforcement allocated to simplify both analysis and evaluation. To the extent that each TCB subset in a subsetted system satisfies the conditions of TC-4.3, the evaluation can be factored along policy lines, and a rating for the composite system determined.

4. SATISFYING RVM REQUIREMENTS

The evaluation of a system whose TCB is made up of a set of TCB subsets follows a logical flow that makes it an orderly process. The initial step is satisfying the conditions for evaluation by parts. Those conditions are as follows:

Identification of the candidate TCB subsets;

Allocation of the policy (the clear statement of the technical policies enforced by the individual TCB subsets, stated in terms of the subjects and objects for that TCB subset);

Demonstration that each candidate TCB subset contains its own trusted subjects;

Specification of the structure of the TCB subsets (as a collection of abstract machines);

Identification of sets of domains (called "subset-domains") assigned for the execution of the individual TCB subsets; and

Identification of what externally stated properties of TCB subsets will be used to argue convincingly and independently for the RVM nature of each of the constituent TCB subsets.

The successful completion of this step, especially the "support for RVM arguments" will result in a conditional approval of two items: a set of goals in the evaluation of the more primitive TCB subsets and the feasibility of being able to argue the RVM properties of less primitive TCB subsets using no more information about the more primitive TCB subsets than the identified goals. The goals for the more primitive TCB subsets will be a set of mechanisms, characteristics, or properties whose proper, assured functioning will have to be demonstrated. Examples are domain mechanisms, mandatory integrity policy enforcement mechanisms, and a special category of object with associated content-preservation guarantees. These mechanisms or characteristics or properties are strictly a function of the more primitive TCB subset and will have to be evaluated and approved in a (possibly) later part of the evaluation process. The conditional approval of the feasibility of constructing an independent RVM argument for less primitive TCB subsets relies on an interplay between the proposed mechanisms of the more primitive TCB subset and the anticipated needs of the RVM argument for the less primitive TCB subset.

The next steps of the evaluation process, with regards to the reference validation mechanism requirements, involve the independent evaluation of the TCB subsets. TCB subsets that have been identified as providing features or mechanisms on which other TCB subsets will rely for RVM arguments will have to be demonstrated to provide the stated mechanisms with the same level of assurance as the target evaluation class of the entire system. If all the identified mechanisms can be validated, the conditional approval of the "support for RVM arguments" condition remains unchanged. If some mechanism cannot be properly established from either a functional or an assurance perspective, then the conditional approval of that portion of the "support" condition is withdrawn and the evaluation effort must regroup.

TCB subsets that were projected to be able to complete RVM arguments successfully using no more than the identified "support" mechanisms and features will have to have full RVM arguments advanced and accepted by the evaluation team. There are three possible outcomes: (1) it could be shown that the TCB subset in question does not meet the RVM requirements; (2) it could be shown, using the external descriptions and assurances of the mechanisms of the more primitive TCB subsets, that the less primitive TCB subset does meet the RVM requirements; or (3) it might be impossible to determine whether or not the TCB subset meets the requirements. In case (1), the TCB subset failed to meet its reference validation mechanism requirements and the design team must regroup. In case (2), the TCB subset satisfies its reference validation mechanism requirements. In case (3), the conditional approval of the "support for RVM arguments" condition will be withdrawn and the design and evaluation teams will have to agree on an alternate course of action.

In the case that an attempt to establish RVM properties for a less primitive TCB subset could not be completed (case (3) above), it might well be that additional mechanisms or features of the more primitive TCB subset would allow the RVM arguments to be completed successfully. In that case, the evaluation team and the design team would have to establish a new, augmented set of mechanisms for the "support" condition. The evaluation could then continue with the new mechanism requiring validation by the evaluation team and the argument for the RVM properties of the less primitive TCB subset having to be re-attempted.

It is important to note that the dependency of the less primitive TCB subsets on the assured policies and RVM supporting mechanisms makes it imperative that the evaluation of the whole TCB be done by a single evaluation team through the final determination that the system complies with the full

set of requirements for the target class. Thus, in particular, an evaluation team addressing an evaluation by parts (including the case of a TCB subset that has been previously evaluated and placed on the EPL) must be kept together for the entire evaluation. Local evaluation of one TCB subset does not justify dissolving the responsible subteam. Later results, global or local to another TCB subset, could require a full evaluation team current on all aspects of the evaluated configuration. This does not mean, of course, that the original evaluation team for a previously evaluated EPL product has to be reassembled. A new team, part of which may be delegated prime responsibility for that TCB subset, suffices, as long as the full team is kept together for the whole evaluation.

5. SUBSET DEPENDENCY

For candidate TCB subset M, sM denotes the specification of M, including as a minimum, the statement of the technical policy P of M. The term vM denotes the (engineering) demonstrations of the correctness of the implementation of M with respect to its specification. A (candidate) TCB subset A "depends (for its correctness)" on (candidate) TCB subset B if and only if the arguments within vA assume the correctness of the implementation of B with respect to sB.

In less precise terms, the specification sM defines what M is supposed to do. M does whatever its implementation allows, features and all. How well M does compared to what sM says it should do is encompassed in the engineering arguments vM. If, in the argument vA, one has to assume that all or part of sB accurately describes what B does, A "depends" on B for its correctness.

Example 1: Use of Provided Objects

Suppose TCB subset B provides "file" as a mediated object under its technical policy P[B] and that candidate TCB subset A uses B-files to store data and executables. If vA uses the fact that different B-files are distinct and access to them is constrained by the technical policy P[B] (assumptions that are nearly certain to apply), then vA is relying on the fact that sB and B match and in this case, A depends on B.

Example 2: Mutually Suspicious Systems

Suppose A and B are mutually suspicious airline reservation systems hosted in two interconnected systems belonging to two distinct organizations. It is assumed that sA and sB both provide for a capability to accept reservations over the network from "foreign" systems using a mutually defined protocol. The protocol is carefully and completely specified (within both sA and sB) and both vA and vB demonstrate, to the desired level of satisfaction, that A and B are correct with respect to sA and sB, respectively. A does not depend for its correctness on B because sA is complete: for whatever sequence of bits it receives from B, sA specifies exactly what behavior A must exhibit, and vA demonstrates that it does exhibit that behavior. Similarly, B does not depend upon A for its correctness. Neither A nor B depends on the other.

There may well exist a "system specification" that specifies the desired behavior of the entire system, but that is irrelevant to the arguments that A and B are individually correct with respect to their own specifications. It may even be the case that both A and B are individually correct, while the combined system is incorrect with respect to the "system specification." That is, two correct subsystems can be combined improperly with respect to the desired "system specification."

Example 3: Use of Remotely Provided Functionality

Suppose A is a mail server and B a generic SQL DBMS. The specification sA (as might be expected) makes no mention of a DBMS; it simply specifies the interface behavior (to its human clients) of the mail system. In vA, however, we find that the software for A uses tables provided by B to store messages. A and B are on separate, interconnected machines. Neither sB nor vB make mention of the mail system at all. As in the preceding example, sB completely specifies the behavior of B for all received bit patterns and sequences. Here, A depends upon B, but B does not depend on A. Note that data flow in both directions is completely legitimate and does not compromise in any way the "integrity" (correctness) of B. Dependency is distinct from "data flow."

This example shows that a superficial examination of the "architecture" of a domain structure is insufficient to determine which candidate TCB subsets depend upon other TCB subsets. Superficially, this architecture is the same as the example of mutually suspicious systems above, but here A depends on B. It also shows that an examination of the interface specifications is insufficient. Finally, it shows that dependency is not the same as the notion of "privilege" (as normally understood in the context of operating systems to mean loosened restrictions on allowed functions and accesses), because there is in this example no sense in which B has access to all of A's internal structures. It only has access to some of them.

Example 4: Use of Locally Provided Functionality

Suppose A and B are the mail server and SQL DBMS of the preceding example, except that A is implemented in a less privileged ring than B. That is, the interconnect is replaced by a ring-crossing service call. Obviously, A still depends on B and B does not depend on A. The change is that now B has potential access to any of A's structures. The general rule for the use of domain protection mechanisms (such as rings) is that if B is privileged with respect to A, then A necessarily depends on B (simply by virtue of B's privilege to access any of A's structures). Thus, a detailed examination of sA and vA is unnecessary to establish dependency.

Cautionary Example

Suppose that A and B are "mutually dependent"; that is, A depends on B and B depends on A. This means that vA assumes that B is implemented correctly with respect to sB, and vB assumes that A is implemented correctly with respect to sA. Further suppose that both vA and vB are valid (reasonable and compelling). One would hope that it follows from this that both A and B are correct. Unfortunately, this is not always the case.

If A and B are both correct with respect to sA and sB, then vA is a valid argument with a true premise and is therefore true. The same is true for B and vB.

Suppose, however, that A is implemented incorrectly with respect to sA and B is implemented incorrectly with respect to sB. vA is a valid argument with a false premise; it is thus valid but (possibly) untrue. Similarly, vB is valid but (possibly) untrue. This case shows that it is quite possible for vA and vB to both be valid while A and B are both (individually) incorrectly implemented.

What has been exposed here is a hidden case of circular reasoning: the argument that A is correct is based on the assumption that B is correct, and the argument that B is correct is based on the assumption that A is correct. Thus, vA depends (circularly) on the assumption that A is correct, and vA reduces to the following tautology: if vA is correct with respect to sA then vA is correct with respect to sA. It is thus possible in principle for mutually dependent subsystems A and B to have vA and vB to be logically valid while either A or B, or both, are incorrect with respect to their specifications (sA or sB).

To make this result concrete, consider two airline reservation systems, A and B, based on the mutually suspicious systems of example 2 above. Suppose that A maintains information about all flights originating or terminating in the United States while B maintains information about flights originating or terminating in Europe. Assume sA includes a statement that A will generate flight itineraries from an origin to a destination, with appropriate provision for connections. "Appropriate provision for connections" means allowing enough time to change planes without requiring passengers to wait an excessive period of time. Further assume that sB includes a similar statement. From the assumption that A meets sA and B meets sB, one can construct a valid argument that A meets its specification sA for itineraries orginating or terminating in either the U.S. or Europe. A similarly valid argument can be made about B. If, however, A stores flight segment times in the local time of the airport and B stores them i n Greenwich Mean Time, an itinerary generated by either A or B that relies on information from the other will be incorrect because of the time differences. Thus, A will not generate accurate, timely flight itineraries, even though a valid argument that it does can be constructed. This difficulty arises from the presumption that A and B are mutually dependent.

6. TAMPER RESISTANCE ARGUMENTS

The requirement to demonstrate that individual TCB subsets exhibit the reference validation mechanism tamper resistance property deserves special attention. In a subsetted architecture there are two (related) aspects to this requirement. The first is the ability of a less primitive TCB subset to maintain control over access to the objects that implement its logic and data structures. The second is establishing the assurance that policy-critical or correctness-critical data used by a TCB subset is persistent (that is, that it does not change or become contaminated with other data between the execution of instructions).

A less primitive TCB subset will be using objects and subjects provided by a more primitive TCB subset. Thus, policy-critical data will be stored in objects that are provided by the more primitive TCB subset rather than in some system entity created and maintained by the less primitive TCB subset itself.

One part of the tamper resistance argument focuses on being able to demonstrate that no alteration of either the policy-critical data or of the TCB subset's code is possible. That is, no system entity external to a TCB subset (with the possible exception of more primitive TCB subsets upon which it depends) should be capable of causing arbitrary changes to that TCB subset's code or data structures. If a third, not more primitive TCB subset (or a subject totally outside the TCB) were able to gain access to an object where policy-critical data was stored, the tamper resistance property could not be established for the TCB subset in question. For a most-primitive TCB subset, a wide variety of techniques could be used to limit access to an object in which such policy-critical data is stored (e.g., prohibition on the sharing of objects, strict ownership control of the ability to extend access permission, and mandatory access controls). Similarly, the conditions for evaluation by parts require that the system designer identify a set of mechanisms and their assured properties as the basis for demonstrating tamper resistance for each TCB subset.

The second topic is the assurance that the contents of the objects that store a TCB subset's policy-critical data not change except through the execution of that TCB subset's logic. If a data structure that identified an exported object (such as tables or tuples or entities) were to have extraneous data inserted by a more primitive TCB subset (for example, as a result of garbage collection or the random action of memory management), then no basis would exist for arguments concerning the correct implementation of the less primitive TCB subset. For a most primitive TCB subset (which includes supporting hardware), the argument that the policy-critical data is kept current and correct can be made strictly on the basis of that TCB subset. However, when a TCB subset obtains resources from a more primitive TCB subset, the argument cannot be made strictly on the basis of the design of the TCB subset. Rather, the argument must proceed from assured mechanisms provided by more primitive TCB subsets. This is exactl y analogous to the case of a reference validation mechanism for which one relies on mechanisms not strictly included in the design of the policy-enforcing elements to establish the requisite properties of non-bypassability and tamper resistance. A variety of mechanisms might provide a basis for demonstrating that the implementation of a TCB subset is correct, even though resources are obtained from a more primitive TCB subset (e.g., type-enforcement).

7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS

Section TC-5, "General Interpreted Requirements," lists the requirements of the TCSEC according to how the requirements apply to a TCB made up of more than one TCB subset. The general rationale for distinguishing which requirements can be satisfied by independent analysis and consideration of the TCB subsets was to consider the requirements one at a time to determine whether satisfaction of the requirement by the individual TCB subsets would necessarily mean that the entire system satisfies the stated requirement.

For some requirements, such as those for certain documentation, it is clear that the requirement is factorable; that is, it is satisfied for the composite TCB if it is satisfied for each of the TCB subsets individually. For other requirements, individual system characteristics could make factorability of a requirement patently obvious, but not all systems would enjoy such simple factorability. An example would be trusted path requirements for security-related events: if all security-related ev ents occur in the most primitive TCB subset, satisfaction of the requirement by that TCB subset suffices to demonstrate that the system meets the requirement, but for systems that have security-relevant events in less primitive TCB subsets, some explanation of the cooperative action of the TCB subsets would be required. For still other requirements, one can expect that the satisfaction of the requirement for the entire system will always require some explanation of the cooperative action of the constituent TCB subsets. Provision of a coherent audit record across events in several TCB subsets is in this category.

In the paragraphs below, a brief rationale for identifying requirements as wholly or partially global is provided. Those requirements that are not listed are considered to be completely local.

Subject Sensitivity Labels

At level B2 and above, the TCSEC requires the following:

The TCB shall immediately notify a terminal user of each change in the security level associated with that user during an interactive session. A terminal user shall be able to query the TCB as desired for a display of the subject's complete sensitivity level.

For subsetted architectures, the user interface could be to a TCB subset that does not support a mandatory access control policy. Thus, a change noted by a more primitive TCB subset that does support such a policy would have to be relayed to the user, possibly through cooperative action of the full set of TCB subsets. Similarly, a request by a terminal user for the complete sensitivity level could be initially received by a TCB subset that does not support a mandatory access control policy and will require cooperation between TCB subsets to determine the complete subject sensitivity level and to provide that information to the requesting user.

Identification and Authentication

The identification and authentication requirements in the TCSEC address the need to correctly associate authorizations with subjects. In a TCB made of several TCB subsets, it is possible that only one of the TCB subsets will provide identification and authentication, which will be used by all the less primitive TCB subsets. Alternatively, identification and authentication may be provided directly in more than one TCB subset. In either case, the TCB subsets have to work cooperatively to use identification and authentication data for uniquely identifying users and for associating users with auditable actions.

Trusted Path

At B2, the only required uses of trusted path are login and authentication. At B3 and above, occasions "when a positive TCB-to-user connection is required (e.g., login, change subject security level)" are included. In both cases, a system vendor may choose to use trusted path for situations where the security-relevant event could be recognized or handled in more than one TCB subset. On those occasions, the careful coordination of all the involved TCB subsets in the correct handling of trusted path situations must be shown. If a single TCB subset implements trusted path and all the invocations of trusted path are limited to that TCB subset (that is, the flow of control in responding to a trusted path initiation never leaves the TCB subset until the response is completed), then nothing further would be required. The description of the limitation of trusted path to a single TCB subset will suffice for the global part of the requirement, leaving only the demonstration of local satisfaction of the requireme nt by the identified TCB subset.

Audit

If each of several TCB subsets meets the audit requirements locally, then there is the issue of whether the set of audit records meets the requirements of being able to note and record individual user actions, and at B3 and above, to be able to initiate required action. If not all the TCB subsets meet the audit requirements locally, then the requirements must be satisfied by the cooperative action of the set of TCB subsets. In both cases, consideration of the audit characteristics of all the TCB subsets has to be part of determining that the entire TCB meets the audit requirements.

System Architecture

For many of the system architecture requirements, demonstrating that a requirement is satisfied by all of the consitituent TCB subsets is sufficient to demonstrate that it is satisfied for the composite TCB. The requirements for the "TCB [to] maintain a domain for its execution" and for the TCB to "maintain process isolation through the provision of distinct address spaces" could be satisfied by the entire TCB without each constituent TCB meeting the requirement.

The requirement for the TCB to maintain a domain for its execution implies the need for each TCB subset to have a domain for its own execution, isolated from both untrusted portions of the system and from less primitive TCB subsets. The exact wording of the TCSEC requirement could be read as disallowing a less primitive TCB subset from occupying a domain provided by a more primitive TCB subset and to allocate its subjects to domains that do not have access to its own domain: the verb "maintain" could be (erroneously) read as requiring each TCB subset to create and maintain its own domain for execution. The proper interpretation is that the TCB as a whole must provide and maintain such domains for execution, rather than each individual TCB subset. Similarly, the exact wording of the TCSEC requirement on the "maintain[ing] of process isolation through the provision of distinct address spaces" could be read as requiring each TCB subset to provide distinct address spaces. The proper interpretation is that the TCB as a whole must provide and maintain process isolation, either through provision and subsequent use of distinct address spaces, or through provision of distinct address spaces by every TCB subset.

Covert Channel Analysis

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

Trusted Facility Management

The ability to run a trusted system facility properly applies to the combination of TCB subsets making up the TCB. This requirement should not be difficult to meet, provided that the individual TCB subsets meet the requirement and the interactions between the TCB subsets at the facility management level are clear.

Trusted Recovery

In the case of "an ADP system failure or other discontinuity," each TCB subset in a B3 or above system needs to be able to recover "without a protection compromise." Further, the recovery actions of distinct TCB subsets needs to be coordinated and combined so that the resulting system is not only recovered as far as each TCB subset is concerned, but is also recovered as a composite TCB.

Security Testing

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

Design Specification and Verification

For many of the design specification and verification requirements, demonstrating that a requirement is satisfied by all of the consitituent TCB subsets is sufficient to demonstrate that it is satisfied for the composite TCB. The requirements for a "formal model of the security policy supported by the TCB" and that the DTLS at B3 and the FTLS at A1 "be an accurate description of the TCB interface" apply in a limited way to the entire TCB.

After complying security models are provided for the individual TCB subsets, a convincing argument is required to explain how the set of models represents abstractly the policy of the entire system.

After complying top-level specifications (DTLS at B3 and FTLS at A1) are provided for the individual TCB subsets, an explicit and convincing description of how the set of top-level specifications describe the TCB interface with respect to exceptions, errors and effects must also be provided.

8. CONTENT-DEPENDENT AND CONTEXT-DEPENDENT ACCESS CONTROL

An attractive proposition in a database managment system is to implement access controls that depend in some way on the values of the data in a storage object or the context in which the information is accessed. For example, one might desire to limit access to all personnel records in a database according to the salary value (content-dependent access rules). On the other hand, a company's earnings report might be held in confidence until announced at the stockholders' meeting, at which time it is public information (context-dependent access rules).

This document does not encourage or endorse mandatory access control on storage objects that are based on the content of data values or on the context in which the information is viewed. Given that these are research topics, it is prudent to take this conservative stance. Research and current practice are insufficient to allow definitive guidance on such implementations.

9. BULK LOADING OF A DATABASE

The bulk loading of a database into (perhaps thousands of) database objects must be done with care. If the data to be loaded are unlabeled, it may not be practical to require an authorized user to examine the data to be loaded into each object and assign it a sensitivity label. Instead it may be more practical to assign labels to the data according to the sensitivity label of the single-level device that is used to import it. In this way, bulk loading may be done in single-level stages.

Even importing labeled multilevel data may prove difficult. The imported data records may be organized on the input device in accordance with their logical structure, not their sensitivity levels. For some trusted DBMS architectures, this requires that the TCB first separate the data by sensitivity levels and subsequently load the data into the database as single-level structures.

Another problem with bulk loading of labeled data is granularity. It may be that the labeling granularity of data on the input device is different from the labeling granularity supported by the receiving trusted DBMS. As an example, the data being imported may be labeled at the file or field level, and the importing DBMS may support labeling at the tuple level. In such instances, the data would have to be mapped into objects of the proper labeling granularity as the data are being imported.

10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT

The ability to distinguish and separately reference the results of local analysis of TCB subsets is a primary aspect of evaluation by parts, and the benefits which accrue are apparent in two, closely related, cases that arise in evalutions by parts. These may be thought of as dealing with the problems of "hosting" and "porting" although they are actually two aspects of the same problemthat of assessing a trusted system constructed of previously evaluated parts.

For the first case (i.e., that of "hosting"), consider an operating system which has been evaluated against the TCSEC requirements and has received a rating. Thus, the operating system is a TCB for which both the local and global analysis has been done. The results of the local analysis can now be used to support the evaluation of a TCB made up of the operating system (or, the more primitive TCB subset) and any proposed TCB extension (or, less primitive TCB subset). Suppose, for example, that vendor A chooses the rated operating system as the host for a DBMS product, which implements an access control policy. As described in TC-6, it is now possible, under the

correct conditions, to re-use the results of the local analysis of the host operating system in developing a rating for the composite system. Even for those cases not meeting all the conditions for evaluation by parts, it may be possible that some, if not most, of the previous results are still valid. If vendor B also chooses the rated operating system as the host for his DBMS product, it will be possible (again, under the proper conditions) to develop a rating for the (new) composite system without having to repeat the local analysis of the host operating system. As an alternate case, suppose a site has need of an electronic mail service as well as the DBMS utility. The mail utility will operate in a peer-entity relation with the trusted DBMS utility (i.e., both the mail service and the DBMS depend on the host operating system, but neither depends on the other). Again, having the results of the local analysis of the host operating system eases the burden of assessing the security characteristics of the user interface to the composite system made up of the mail system and the host operating system. In short, the ability to distinguish and separately reference the results of the local analysis of the host operating system makes it feasible to evaluate the effect of adding arbitrary trusted applications, only by performing the local analyis for the application and any global analysis required.

For the second case, (i.e., that of "porting") the question becomes that of determining the effect of moving a known trusted application, such as a DBMS, across arbitrary host systems. Assume that a trusted DBMS product meeting the conditions for evaluation by parts has been evaluated on some trusted host, and a rating determined for the composite system. Clearly, the results of the local analysis of the trusted application available are also applicable to the analysis of a composite system made up of the trusted application and a different host operating system. Thus, having the local analysis of the trusted application will ease the evaluation burden associated with porting of trusted applications to different hosts. To the extent that the conditions for evaluations by parts have been satisfied, the local analysis of the application is valid by reference.

Hence only the local analysis of the host operating system and the requisite global analysis is needed to assess the security attributes of the new composite system.

11. RATING MORE COMPLEX SYSTEMS

The view taken by the TCSEC is that of an "atomic" TCB; the TCB is seen to be a single entity which is, in some sense, homogeneous. This allows a relatively simple measure (i.e., the digraphs) to be assigned to the TCB. However, real systems may be more complex, resulting in the inability of a single, simple rating to convey the full complexity of the system. This is implicitly recognized in TCSEC evaluation reports and EPL entries, in which credit may be given to a vendor for meeting TCSEC (functional) requirements beyond those necessary to satisfy the rating (e.g., the B3 discretionary access control feature in a C2 TCB). In short, systems which reflect straightforward implementations or extensions of the TCSEC can accurately be described with a single digraph. On the other hand, adding complexity to systems may violate assumptions which underlie the TCSEC rating system, requiring a more complex description if accuracy is to be achieved.

If a TCB made up of TCB subsets is consistent with the TCSEC assumptions on homogeneity, then a simple digraph suffices for a full and accurate description of the security properties of the product. However, to the extent that a subsetted architecture introduces complexity not captured by the digraphs, the simple TCSEC ratings cannot be applied to the composite system. More specifically, for a subsetted TCB to achieve a single rating, all the requirements of that class must be satisfied. For example, if a discretionary access control-enforcing DBMS TCB subset is added onto a previously evaluated B3 product, the entire system can achieve a B3 rating if it could also have achieved the B3 rating evaluated as a monolith. That is, the new TCB subset must also satisfy all the assurance and architectural requirements of B3.

Consider a candidate TCB subset which enforces a discretionary access control policy over a new type of object, targeted at a host system which has already been evaluated at the B3 level. Examples are a database management system providing discretionary access control over tuples, a transaction processor providing discretionary access control over transactions, and a message system providing discretionary access control over messages. If the candidate TCB subset meets all the C2 requirements, the problem is what rating will be assigned to the composite system. To designate it a "C2" is clearly inaccurate, as well as being unfair to the original B3 product vendor. To designate it "B3" may be equally inaccurate, and it creates ambiguity in the meaning of the metric used for comparing systems. In fact, depending on the details of the specific candidate, the composite system could legitimately be rated at any level from C2 to B3 under a TCSEC evaluation.

The TCSEC rating system assumes a measure of homogeneity which the above example violates thus invalidating the very basis upon which a single digraph may be assigned. Hence, a subsetted system such as described above, will have to be characterized with a more complex description than a single digraph.

Although this may seem undesirable, it will be a more accurate description of the system, and it provides sufficient information to allow system designers and accreditors to make decisions about sufficiency of security for their specific applications. In essence, such an approach is necessary for recognizing the additional complexity which can be introduced by architectures which allow system elements to be developed separately.

GLOSSARY

candidate TCB subset The identification of the hardware, firmware, and software that make up the proposed TCB subset, along with the identification of its subjects and objects; one of the conditions for evaluation by parts

content-dependent access control Access control in which access is determined by the value of the data to be accessed.

context-dependent access control Access control in which access is determined by the specific circumstances under which the data is being accessed.

database management system A computer system whose main function is to facilitate the sharing of a common set of data among many different users. It may or may not maintain semantic relationships among the data items.

DBMS Abbreviation for "database management system."

depends A TCB subset A depends (for its correctness) on TCB subset B if and only if the (engineering) arguments of the correct implementation of A with respect to its specification assume, wholly or in part, that the specification of B has been implemented correctly.

domain The set of objects that a subject has the ability to access.

dominated by Security level A is dominated by security level B if (1) the clearance/classification in A is less than or equal to the clearance/classification in B, and (2) the set of access approvals (e.g., compartment designators) in A is contained in the set of access approvals in B (i.e., each access approval appearing in A also appears in B). This dominance relation is a special case of a partial order.

dominates "Security level B dominates security level A" is synonymous with "security level A is dominated by security level B." See "dominated by."

global requirements Those which require analysis of the entire system and for which separate analysis of the individual TCB subsets does not suffice. See Section TC-5.3.2 for a summary list.

lattice A partially ordered set for which every pair of elements has a greatest lower bound and a least upper bound.

local requirements Those for which separate analysis of the individual TCB subsets suffices to determine compliance for the composite TCB. See Section TC-5.3.1 for summary list.

metadata (1) Data referring to other data; data (such as data structures, indices, and pointers) that are used to instantiate an abstraction (such as "process," "task," "segment," "file," or "pipe"). (2) A special database, also referred to as a data dictionary, containing descriptions of the elements (e.g., relations, domains, entities, or relationships) of a database.

monolithic TCB A TCB that consists of a single TCB subset.

object A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are: records, blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, fields, processors, video displays, keyboards, clocks, printers, network nodes, etc.

partial order A relation that is symmetric (a is related to a), transitive (if a is related to b and b is related to c, then a is related to c), and antisymmetric (if a is related to b and b is related to a, then a and b are identical.)

primitive An ordering relation between TCB subsets based on dependency (see "depends" above). A TCBsubset B is more primitive than a second TCB subset A (and A is less primitive than B) if (a) A directly depends on B or (b) a chain of TCB subsets from A to B exists such that each element of the chain directly depends on its successor in the chain.

reference monitor concept An access control concept that refers to an abstract machine that mediates all accesses to objects by subjects.

reference validation mechanism "An implementation of the reference monitor concept . . . that validates each reference to data or programs by any user (program) against a list of authorized types of reference for that user." It must be tamper proof, must always be invoked, and must be small enough to be subject to analysis and tests, the completeness of which can be assured. [1]

security policy The set of laws, rules, and practices that regulate how an organization manages, protects, and distributes sensitive information.

storage object An object that supports both read and write accesses.

subject An active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. Technically, a process/domain pair.

subset-domain A set of system domains. For evaluation by parts, each candidate TCB subset must occupy a distinct subset domain such that modify-access to a domain within a TCB subset's subset-domain is permitted only to that TCB subset and (possibly) to more primitive TCB subsets.

TCB subset A set of software, firmware, and hardware (where any of these three could be absent) that mediates the access of a set S of subjects to a set O of objects on the basis of a stated access control policy P and satisfies the properties:

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

technical policy The set of rules regulating access of subjects to objects enforced by a computer system.

Trusted Computing Base (TCB) The totality of protection mechanisms within a computer system including hardware, firmware, and software the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a TCB to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user's clearance) related to the security policy.

trusted subject A subject that is permitted to have simultaneous view- and alter-access to objects of more than one sensitivity level.

user Any person who interacts directly with a computer system.

view That portion of the database that satisfies the conditions specified in a query.

view definition A stored query; sometimes loosely referred to as a "view."

BIBLIOGRAPHY

1. J. P. Anderson, "Computer Security Technology

Planning Study," ESD-TR-73-51 (AD-758206), J. P.

Anderson Co., October 1972.

2. J. P. Anderson, "On the Feasibility of Connecting
RECON to an External Network," Technical Report, J. P.
Anderson Co., March 1981.
3. D. E. Bell and L. J. La Padula, "Secure
Computer Systems: Unified Exposition and Multics Interpretation," MTR-2997, (AY/W 020 445), The MITRE Corporation, Bedford, Massachusetts, July 1975.
4. D. E. Bell and L. J. La Padula, "Secure

Computer Systems: Mathematical Foundations,"

MTR-2547-I, (AD 770 768), The MITRE Corporation,

Bedford, Massachusetts, March 1973.

5. L. J. La Padula and D. E. Bell, "Secure
Computer Systems: A Mathematical Model," MTR 2547-II, (AD 771 543), The MITRE Corporation, Bedford, Massachusetts, May 1973.
6. D. E. Bell, "Secure Computer Systems: A
Refinement of the Mathematical Model," MTR 2547-III,
(AD 780 528), The MITRE Corporation, Bedford,

Massachusetts, December 1973.

7. D. E. Bell, "Secure Computer Systems: A Network
Interpretation," Proceedings of the Second Aerospace Computer Security Conference, McLean Virginia, December 2-4, 1986, pp. 32-39.

8. Department of Defense, Department of Defense

Trusted Computer System Evaluation Criteria, DOD

5200.28-STD, December 1985.

9. D. E. Denning, "Cryptographic Checksums for
Multilevel Database Security," Proceedings of the IEEE Symposium on Security & Privacy, Oakland, California, April 29-May 2, 1984, pp. 52-61.
10. D. E. Denning, "Commutative Filters for Reducing
Inference Threats in Multilevel Database Systems," Proceedings of the IEEE Symposium on Security & Privacy, Oakland, California, April 22-24, 1985, pp. 134-146.
11. E. B. Fernandez, R. C. Summers, and C. Wood,
Database Security and Integrity, Boston, Massachusetts:
Addison Wesley, 1981.
12. C. Garvey and A. Wu, "ASD Views," Proceedings of the Fourth Aerospace Computer Security Applications Conference, Orlando, Florida, December 1988, pp. 85-95.
13. R. D. Graubart and J. P. L. Woodward, "A
Preliminary Naval Surveillance DBMS Security Model," Proceedings of the IEEE Symposium on Security & Privacy, Oakland, California, April 26-28, 1982, pp. 21-37.
14. R. D. Graubart, "The Integrity-Lock Approach to
Secure Database Management," Proceedings of the IEEE
Symposium on Security & Privacy, Oakland, California,

April 29-May 2, 1984, pp. 62-74.

15. M. J. Grohn, "A Model of a Protected Data
Management System," ESD-TR-76-289, I. P. Sharp Associates, Ltd., June 1976.
16. T. H. Hinke, M. Schaefer et al., "Secure Data
Management System," RADC-TR-75-266 (AD-A019201), System Development Corporation, Santa Monica, California, November 1975.
17. C. E. Landwehr, C. L. Heitmeyer, and J.
McLean, "A Security Model for Military Message Systems," ACM Transactions on Computer Systems, Vol. 2, No. 3, August 1984, pp. 198-222.
18. T. F. Lunt, D. E. Denning, P. G. Neumann, R.
R. Schell, M. Heckman, and W. R. Shockley, "Final

Report Vol. 1: Security Policy and Policy

Interpretation for a Class A1 Multilevel Secure

Relational Database System," Computer Science

Laboratory, SRI International, Menlo Park, California, 1988.

19. J. McHugh and B. M. Thuraisingham, "Multilevel
Security Issues in Distributed Database Management Systems," Computers & Security, Vol. 7, No. 4, Elsevier Advanced Technology Publications, August 1988, pp. 387-396.
20. National Computer Security Center, Proceedings of the National Computer Security Center Invitational Workshop on Database Security, Baltimore, Maryland, June 17-20, 1986.
21. P. A. Rougeau and E. D. Sturms, "The Sybase
Secure Dataserver: A Solution to the Multilevel Secure

DBMS Problem," Proceedings of the 10th National

Computer Security Conference, Baltimore, Maryland,

September 21-24, 1987, pp. 211-215.

22. M. Schaefer, ed., Multilevel Data Management

Security, Air Force Studies Board, Committee on

Multilevel Data Management Security, National Academy Press: Washington, D.C., 1983.

23. M. D. Schroeder and J. H. Saltzer, "A Hardware
Architecture for Implementing Protection Rings," Communications of the ACM, Vol. 15, No. 3, March 1972, pp.157-170.
24. W. R. Shockley and R. R. Schell, "TCB Subsets for Incremental Evaluation," Proceedings of the Third Aerospace Computer Security Conference, Orlando, Florida, December 7-11, 1987, pp. 131-139.
25. P. Stachour and B. Thuraisingham, "Design of LDV

· A Multilevel Secure Database Management System," IEEE Transactions on Knowledge and Data Engineering, Vol. 2, No. 2, June 1990, pp. 190-209.

26. M. Stonebraker, "Operating System Support for Database Management," Communications of the ACM, Vol. 24, No. 7, July 1981, pp. 412-418.

27. Unisys Corporation, "Secure Distributed Database
Management System," Final Technical Report, Rome Air Development Center Technical Report, RADC-TR-89-314, Vol. 1-5, December 1989.
28. J. Wilson, "Views as the Security Objects in a
Multi-level Secure Relational Database Management System," Proceedings of the 1988 IEEE Symposium on Security & Privacy, Oakland, California, April 18-21, 1988, pp. 70-84.

Trusted Database Management System Interpretation

FOREWORD

ACKNOWLEDGMENTS

TABLE OF CONTENTS

INTRODUCTION

HISTORICAL PERSPECTIVE

SCOPE

PURPOSE

STRUCTURE OF THE DOCUMENT

PART 1 TECHNICAL CONTEXT

TC-1 INTRODUCTION

TC-2 REFERENCE MONITOR PERSPECTIVE

TC-3 NEED FOR EVALUATION BY PARTS

TC-4 TCB SUBSETS

TC-4.1 INTRODUCTION

TC-4.2 TCB SUBSETS CONTEXT

TC-4.2.1 DEFINITION OF TCB SUBSETS

TC-4.2.2 MOTIVATION

TC-4.3 CONDITIONS FOR EVALUATION BY PARTS

TC-4.3.1 CANDIDATE TCB SUBSETS

TC-4.3.2 POLICY ALLOCATION

TC-4.3.3 TRUSTED SUBJECTS INCLUDED

TC-4.3.4 TCB SUBSET STRUCTURE

TC-4.3.5 SEPARATE SUBSET-DOMAINS

TC-4.3.6 SUPPORT FOR RVM ARGUMENTS

TC-4.4 EVALUATION ALTERNATIVES

TC-5 GENERAL INTERPRETED REQUIREMENTS

TC-5.1 OVERVIEW

TC-5.2 DETAILED REQUIREMENTS

TC-5.2.1 SECURITY POLICY

TC-5.2.1.1 Discretionary Access Control

TC-5.2.1.2 Object Reuse

TC-5.2.1.3 Labels

Label Integrity

Exportation of Labeled Information

Subject Sensitivity Labels

Device Labels

TC-5.2.1.4 Mandatory Access Control

TC-5.2.2 ACCOUNTABILITY

TC-5.2.2.1 Identification and Authentication

Trusted Path

TC-5.2.2.2 Audit

TC-5.2.3 ASSURANCE

TC-5.2.3.1 Operational Assurance

System Architecture

System Integrity

Covert Channel Analysis

Trusted Facility Management

Trusted Recovery

TC-5.2.3.2 Life-Cycle Assurance

Security Testing

Design Specification and Verification

Configuration Management

Trusted Distribution

TC-5.2.4 DOCUMENTATION

TC-5.2.4.1 DOCUMENTATION

TC-5.2.4.2 Trusted Facility Manual

TC-5.2.4.3 Test Documentation

TC-5.2.4.4 Design Documentation

TC-5.3 SUMMARY OF THE REQUIREMENTS

TC-5.3.1 LOCAL REQUIREMENTS

TC-5.3.2 GLOBAL REQUIREMENTS

TC-6 DESIGN CHOICE

TC-6.1 OVERVIEW

TC-6.2 A SINGLE TCB SUBSET

TC-6.2.1 ANALYSIS OF THE CONDITIONS

TC-6.2.1.1 Condition 1: Candidate TCB Subsets

TC-6.2.1.2 Condition 2: Policy Allocation

TC-6.2.1.4 Condition 4: TCB Subset Structure

TC-6.2.1.5 Condition 5: Separate Subset-Domains

TC-6.2.1.6 Condition 6: Support for RVM Arguments

TC-6.2.2 EVALUATION S CONSEQUENCE

TC-6.3 TWO TCB SUBSETS, MEETING THE CONDITIONS

TC-6.3.1 ANALYSIS OF THE CONDITIONS

TC-6.3.1.1 Condition 1: Candidate TCB subsets

TC-6.3.1.2 Condition 2: Policy Allocation

TC-6.3.1.3 Condition 3: Trusted Subjects included

TC-6.3.1.4 Condition 4: TCB Subset Structure

TC-6.3.1.5 Condition 5: Separate Subset-Domains

TC-6.3.1.6 Condition 6: Support for RVM Arguments