NCSC-TG-021 Library No. S235,625 FOREWORD The National Computer Security Center is issuing the Trusted Database Management System Interpretation as part of the Technical Guidelines Program, through which we produce the "Rainbow Series." In the Rainbow Series, we discuss in detail the features of the Trusted Computer System Evaluation Criteria (DoD 5200.28-STD) and provide guidance for meeting each requirement. The National Computer Security Center, through its Trusted Product Evaluation Program, analyzes the security features of commercially produced and supported computer systems. Together, these programs ensure that organizations are capable of protecting their important data with trusted computer systems. The Trusted Database Management System Interpretation extends the evaluation classes of the Trusted Computer System Evaluation Criteria to trusted applications in general, and database management systems in particular. It serves as an adjunct to the Trusted Computer System Evaluation Criteria by providing a technical context for the consideration of entire systems constructed of parts and by presenting database-specific interpretation of topics that require direct comment. Thus, it is relevant to applications which support sharing of computer services and resources, and which enforce access control policies. More specifically, it provides insight into the the design, implementation, evaluation, and accreditation of database management systems. This document will be used for at least one year after the date of signature. During this period the NCSC will gain experience using the Trusted Database Management Systems Interpretation in several evaluations and continue to receive comments on issues of technical accuracy, clarity of exposition, and utility. After this trial period, necessary changes will be made and a revised version issued. _____________ PATRICK R. GALLAGHER, JR. April 1991 Director National Computer Security Center ACKNOWLEDGMENTS This document represents the combined effort of participants from the research community, industry, and government working over several years. Three major drafts and numerous intermediary versions were produced, reviewed, and commented upon. To name all the contributors would be impossible. To single out a few would be to slight a host of others who gave unstintingly of their time and talent. To all those who contributed to the development and refinement of the fundamental concepts, contributed to the development of the several predecessor versions, and who contributed valuable personal time and invaluable experience in reviewing and commenting on the previous versions, thanks is extended. TABLE OF CONTENTS FOREWORD i ACKNOWLEDGMENTS iii INTRODUCTION 1 HISTORICAL PERSPECTIVE 1 SCOPE 2 PURPOSE 2 STRUCTURE OF THE DOCUMENT 4 PART 1 TECHNICAL CONTEXT 7 TC-1 INTRODUCTION 9 TC-2 REFERENCE MONITOR PERSPECTIVE 10 TC-3 NEED FOR EVALUATION BY PARTS 11 TC-4 TCB SUBSETS 11 TC-4.1 INTRODUCTION 12 TC-4.2 TCB SUBSETS CONTEXT 13 TC-4.2.1 DEFINITION OF TCB SUBSETS 13 TC-4.2.2 MOTIVATION 13 TC-4.3 CONDITIONS FOR EVALUATION BY PARTS 14 TC-4.3.1 CANDIDATE TCB SUBSETS 14 TC-4.3.2 POLICY ALLOCATION 15 TC-4.3.3 TRUSTED SUBJECTS INCLUDED 15 TC-4.3.4 TCB SUBSET STRUCTURE 15 TC-4.3.5 SEPARATE SUBSET-DOMAINS 16 TC-4.3.6 SUPPORT FOR RVM ARGUMENTS 16 TC-4.4 EVALUATION ALTERNATIVES 17 TC-5 GENERAL INTERPRETED REQUIREMENTS 18 TC-5.1 OVERVIEW 18 TC-5.2 DETAILED REQUIREMENTS 18 TC-5.2.1 SECURITY POLICY 18 TC-5.2.1.1 Discretionary Access Control 18 TC-5.2.1.2 Object Reuse 18 TC-5.2.1.3 Labels 19 TC-5.2.1.4 Mandatory Access Control 20 TC-5.2.2 ACCOUNTABILITY 20 TC-5.2.2.1 Identification and Authentication 20 TC-5.2.2.2 Audit 21 TC-5.2.3 ASSURANCE 22 TC-5.2.3.1 Operational Assurance 22 TC-5.2.3.2 Life-Cycle Assurance 23 TC-5.2.4 DOCUMENTATION 24 TC-5.2.4.1 Security Features User's Guide 24 TC-5.2.4.2 Trusted Facility Manual 25 TC-5.2.4.3 Test Documentation 26 TC-5.2.4.4 Design Documentation 26 TC-5.3 SUMMARY OF THE REQUIREMENTS 26 TC-5.3.1 LOCAL REQUIREMENTS 26 TC-5.3.2 GLOBAL REQUIREMENTS 27 TC-6 DESIGN CHOICES 28 TC-6.1 OVERVIEW 28 TC-6.2 A SINGLE TCB SUBSET 28 TC-6.2.1 ANALYSIS OF THE CONDITIONS 28 TC-6.2.1.1 Condition 1: Candidate TCB Subsets 28 TC-6.2.1.2 Condition 2: Policy Allocation 29 TC-6.2.1.3 Condition 3: Trusted Subjects Included 29 TC-6.2.1.4 Condition 4: TCB Subset Structure 29 TC-6.2.1.5 Condition 5: Separate Subset-Domains 29 TC-6.2.1.6 Condition 6: Support for RVM Arguments 29 TC-6.2.2 EVALUATION CONSEQUENCES 29 TC-6.3 TWO TCB SUBSETS,MEETING THE CONDITIONS 30 TC-6.3.1 ANALYSIS OF THE CONDITIONS 30 TC-6.3.1.1 Condition 1: Candidate TCB Subsets 30 TC-6.3.1.2 Condition 2: Policy Allocation 31 TC-6.3.1.3 Condition 3: Trusted Subjects Included 31 TC-6.3.1.4 Condition 4: TCB Subset Structure 31 TC-6.3.1.5 Condition 5: Separate Subset-Domains 31 TC-6.3.1.6 Condition 6: Support for RVM Arguments 31 TC-6.3.2 EVALUATION CONSEQUENCES 32 TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS 33 TC-6.4.1 ANALYSIS OF THE CONDITIONS 34 TC-6.4.1.1 Condition 1: Candidate TCB Subsets 34 TC-6.4.1.2 Condition 2: Policy Allocation 34 TC-6.4.1.3 Condition 3: Trusted Subjects Included 34 TC-6.4.1.4 Condition 4: TCB Subset Structure 35 TC-6.4.1.5 Condition 5: Separate Subset-Domains 35 TC-6.4.1.6 Condition 6: Support for RVM Arguments 35 TC-6.4.2 EVALUATION CONSEQUENCES 35 TC-6.5 SUMMARY 36 PART 2 INTERPRETED REQUIREMENTS 37 IR-1 OVERVIEW AND CONTEXT 39 IR-2 SUMMARY OF THE INTERPRETATIONS 39 IR-2.1 SECURITY POLICY 39 IR-2.1.1 DISCRETIONARY ACCESS CONTROL 39 IR-2.1.2 OBJECT REUSE 40 IR-2.1.3 LABELS 40 IR-2.1.4 MANDATORY ACCESS CONTROL 40 IR-2.2 ACCOUNTABILITY 40 IR-2.2.1 IDENTIFICATION AND AUTHENTICATION 40 IR-2.2.2 AUDIT 40 IR-2.3 ASSURANCE 40 IR-2.3.1 OPERATIONAL ASSURANCE 40 IR-2.3.1.1 System Architecture 40 IR-2.3.1.2 System Integrity 40 IR-2.3.1.3 Covert Channel Analysis 41 IR-2.3.1.4 Trusted Facility Management 41 IR-2.3.1.5 Trusted Recovery 41 IR-2.3.2 LIFE CYCLE ASSURANCE 41 IR-2.3.2.1 Security Testing 41 IR-2.3.2.2 Design Specification and Verification 41 IR-2.3.2.3 Configuration Management 41 IR-2.3.2.4 Trusted Distribution 41 IR-2.4 DOCUMENTATION 42 IR-2.4.1 SECURITY FEATURES USER'S GUIDE 42 IR-2.4.2 TRUSTED FACILITY MANUAL 42 IR-2.4.3 TEST DOCUMENTATION 42 IR-2.4.4 DESIGN DOCUMENTATION 42 IR-3 LABELS 42 IR-3.1 GENERAL DISCUSSION 42 IR-3.2 SPECIFIC INTERPRETATIONS 43 IR-4 AUDIT 44 IR-4.1 GENERAL DISCUSSION 44 IR-4.2 SPECIFIC INTERPRETATIONS 45 IR-5 SYSTEM ARCHITECTURE 47 IR-5.1 GENERAL DISCUSSION 47 IR-5.2 SPECIFIC INTERPRETATIONS 47 IR-6 DESIGN SPECIFICATION AND VERIFICATION 48 IR-6.1 GENERAL DISCUSSION 48 IR-6.2 SPECIFIC INTERPRETATIONS 52 IR-7 DESIGN DOCUMENTATION 55 IR-7.1 GENERAL DISCUSSION 55 IR-7.2 SPECIFIC INTERPRETATIONS 56 APPENDIX A 59 CLASS (C1): 62 C1-1 SECURITY POLICY 62 C1-2 ACCOUNTABILITY 62 C1-3 ASSURANCE 62 C1-4 DOCUMENTATION 63 CLASS (C2): 66 C2-1 SECURITY POLICY 66 C2-2 ACCOUNTABILITY 66 C2-3 ASSURANCE 67 C2-4 DOCUMENTATION 68 CLASS (B1): 70 B1-1 SECURITY POLICY 70 B1-2 ACCOUNTABILITY 71 B1-3 ASSURANCE 73 B1-4 DOCUMENTATION 74 CLASS (B2): 77 B2-1 SECURITY POLICY 77 B2-2 ACCOUNTABILITY 79 B2-3 ASSURANCE 81 B2-4 DOCUMENTATION 85 CLASS (B3): 89 B3-1 SECURITY POLICY 89 B3-2 ACCOUNTABILITY 91 B3-3 ASSURANCE 93 B3-4 DOCUMENTATION 98 CLASS (A1): 102 A1-1 SECURITY POLICY 102 A1-2 ACCOUNTABILITY 104 A1-3 ASSURANCE 106 A1-4 DOCUMENTATION 112 APPENDIX B 117 1. PERSPECTIVE ON ASSURANCE 119 2. PROCUREMENT OPTIONS 120 3. ALTERATION OF PREVIOUSLY EVALUATED TCB 122 4. SATISFYING RVM REQUIREMENTS 125 5. SUBSET DEPENDENCY 127 6. TAMPER RESISTANCE ARGUMENTS 131 7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS 132 8 CONTENT-DEPENDENT AND CONTEXT-DEPENDENT ACCESS CONTROL 136 9. BULK LOADING OF A DATABASE 137 10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT 137 11. RATING MORE COMPLEX SYSTEMS 139 GLOSSARY 141 BIBLIOGRAPHY 145 INTRODUCTION HISTORICAL PERSPECTIVE The Department of Defense Trusted Computer System Evaluation Criteria (TCSEC), published in 1983 as CSC-STD-001-83, consolidates knowledge about the degree of trust one can place in a computer system to protect sensitive information and organizes this knowledge into usable criteria for system evaluation. The TCSEC was republished as a DoD standard, DoD-5200.28-STD, in December 1985 to provide a means of evaluating specific security features and assurances available in "trusted, commercially available automatic data processing system The TCSEC's rating scale extends from a minimal to a high level of trust with advanced security features and sophisticated assurance measures. Specific criteria determine each rating level and guide system builders and evaluators in determining the level of trust provided by specific systems. When the rating levels are combined with environmental guidelines and minimum security protection requirements, accreditation decisions for specific installations can be made. The philosophy of protection embodied in the TCSEC requires that the access of subjects (i.e., processes in a domain) to objects (i.e., containers of information) be mediated in accordance with an explicit and well-defined security policy. At the higher criteria classes, the "reference monitor concept" [1] is an essential part of the system and the security policy is modeled. There are several security policy models that represent the desired behavior of a reference monitor. The Bell-La Padula model [4-6] and its Multics interpretation [3] are commonly used, but not mandated. The computer security research and development that underpin the TCSEC began in the late 1960s and concentrated on secure operating systems. By the early 1970s initial worked examples had provided a substantial amount of information about building trust into operating systems. Research continued throughout the 1970s to refine mechanisms, features, and assurances needed to provide trusted operating systems. Multilevel database management security received far less research and development attention than did secure operating systems. This was primarily due to the perception that one could not credibly implement a multilevel secure database management system (DBMS) on top of an untrusted operating system base. However, some research in multilevel secure DBMSs (mostly theoretical) was conducted during the 1970s [15-16], and research has continued to the present [9-14, 17-19, 22, 25-28]. By the mid 1980s, commercially developed, trusted operating systems were becoming available that could provide the basis for hosting secure applications such as multilevel secure DBMSs. In June 1986, the National Computer Security Center (NCSC) initiated its efforts to address the evaluation of trusted database management systems with an Invitational Workshop in Baltimore, Maryland. Representatives from the research, database vendor, commercial, and government communities met to address issues of database management security. The attendees met to discuss aspects of trust (defined by the TCSEC) that were sufficiently well defined and capable of producing repeatable and objective assessments. The NCSC invited issue papers and prepared a discussion agenda. The issue papers and the subcommittee summaries were published as the Proceedings of the National Computer Security Center Invitational Workshop on Database Security [20]. As an outgrowth of this workshop, the NCSC undertook the task of preparing this Trusted Database Management System Interpretation (TDI) of the TCSEC to focus on the special problems posed by DBMSs. A working group was assembled to draft this Interpretation. Three drafts were produced, with extensive community review and public discussion. This Interpretation is the result of the interaction within the general computer security and database management communities. SCOPE The interpretations in this document are intended to be used in conjunction with the TCSEC itself; they apply to application-oriented software systems in general, and database management systems (DBMSs) in particular. Although the interpretations, as noted, are general enough to apply to any software system which supports sharing and needs to enforce access control (e.g., transaction processing systems, electronic mail systems), in the interest of simplicity, the discussion, and thus the terminology, will be directed toward DBMSs. The interpretations are intended to be applied primarily to commercially developed trusted DBMSs, but can also be applied to the evaluation of existing non-commercial DBMSs and to the specification of security requirements for DBMS acquisitions. PURPOSE This Interpretation of the TCSEC has been prepared for the following purposes: To provide a standard to manufacturers for security features to build into their new and planned commercial products in order to provide widely available systems that satisfy trust requirements (with particular emphasis on preventing the disclosure of data) for sensitive applications, To provide a metric with which to evaluate the degree of trust that can be placed in computer systems for the secure processing of classified and other sensitive information, and To provide a basis for specifying security requirements in acquisition specifications. With respect to the second purpose for development of the criteria, i.e., providing a security evaluation metric, evaluations can be delineated into two types: (1) evaluations performed on a computer product from a perspective that excludes the application environment; or, (2) evaluations to assess whether appropriate security measures have been taken to permit the system to be used operationally in a specific environment. The former type of evaluation is done by the National Computer Security Center (NCSC) through the Trusted Product Evaluation Program and is called "formal product evaluation." The latter type of evaluation, that is, one done for the purpose of assessing a system's security attributes with respect to a specific operational mission, is known as a "certification evaluation." A formal product evaluation does not constitute certification or accreditation for the system to be used in any specific application environment. The system security certification and the formal approval/accreditation procedure, done in accordance with the applicable policies of the issuing agencies, must still be followed before a system can be approved for use in processing or handling sensitive or classified information. Designated Approving Authorities (DAAs) remain ultimately responsible for specifying the security of systems they accredit. 3 The TCSEC and this Interpretation will be used directly and indirectly in the certification process. Along with applicable policy, they will be used directly as technical guidance for evaluation of the total system and for specifying system security and certification requirements for new acquisitions. Where a system being evaluated for certification employs a product that has undergone a formal product evaluation, reports from that process will be used as input to the certification evaluation. Moreover, the National Security Agency plans to publish additional guidelines to assist certifiers and help ensure consistency in certifications of systems processing national security informantion. STRUCTURE OF THE DOCUMENT The remainder of the TDI is divided into two parts, plus two appendices and a glossary. PART 1, "TECHNICAL CONTEXT," presents general information about the evaluation of trusted systems that are constructed of several parts. This discussion is critical to trusted DBMSs built upon trusted operating systems, but is not limited to DBMSs only. It is included in the TDI because it is not currently available in any previously published document. This section reviews the central reference monitor concept, explains the need to evaluate a system built of well-defined parts, and develops the concept of TCB subsets. TCB subsets provide a way of splitting a total TCB along access control policy lines such that an evaluation by parts can be undertaken. PART 1 concludes with an interpretation of those TCSEC requirements which are relevant to an evaluation by parts, and a description of the process of evaluation by parts. PART 2, "INTERPRETED REQUIREMENTS," provides interpretions of those TCSEC requirements that are either specific to DBMSs (or applications in general), or are particularly relevant to DBMSs. The number of requirements that are treated explicitly is relatively small, because many of the TCSEC requirements apply as stated to database management systems. The requirements treated explicitly are labels, audit, system architecture, design specification and verification, and design documentation. Appendix A summarizes the interpreted requirements for each TCSEC class and is intended to provide an easy reference for those requiring a listing of requirements for a specific class (e.g., B2). Appendix B provides discussion of several topics not directly tied to the requirements levied on trusted DBMSs by the interpretation of the TCSEC requirements. The TDI proper will be supplemented by a Companion Document Series (CDS). The CDS will address a wide spectrum of issues related to trusted DBMSs but which are beyond the scope of this document. Community debate about on-going topics of interest will probably result in gradual extensions of what is known about trusted DBMSs. Thus, volumes in the CDS will be issued both regularly (to document the state of the community debate) and by exception (to record new problems and new solutions). PART 1 TECHNICAL CONTEXT 7 TC-1 INTRODUCTION Modern computing systems are rarely conceived and built by a single organization. Rather, the rule is that systems are constructed by assembling parts?hardware, firmware, and software?produced independently by various organizations or vendors. This fact introduces a fundamental difficulty into the task of evaluating a "system" for conformance to the trust requirements of the Trusted Computer System Evaluation Criteria (TCSEC). [8] This difficulty stems from the fact that assessment (either evaluation of a product or certification of a system) entails a global perspective of the entire system under consideration. There are not yet widely accepted methods of factoring the various aspects of a trust assessment and then reassembling the results into a statement about the whole. These conflicting perspectives of local production and global evaluation analysis are particularly evident in the field of database management, but they are by no means limited to that field. Thus the publication of this Interpretation requires consideration of how to deal with systems built in parts in the absence of a general treatment of the topic. On the other hand, any treatment of the issue in the context of trusted database management will have significant influence in other fields where the same or similar problems arise, just because of community review and NCSC publication. The approach taken in this document is to address the issues of evaluating systems built of parts in a way that is independent of the field of trusted database management. This conscious attitude of generality is intended to make clear the distinction between the larger system-of-parts issues and the more specific DBMS issues. PART 1, "TECHNICAL CONTEXT," is divided into six sections. Section TC-2, "Reference Monitor Perspective," summarizes the role of the reference monitor concept in both the TCSEC and the assessing of a system for its trust characteristics. Section TC-3, "Need for Evaluation by Parts," deals with the need to extend the reference monitor perspective slightly to begin to address the evaluation of systems constructed of separate parts. Section TC-4, "TCB Subsets," is the heart of PART 1. That section introduces a conservative extension to the reference validation mechanism, TCB subsets. This extension provides the basis for being able to undertake evaluation of systems built in parts in a way that allows re-use of the results of separate evaluations (whether those evaluations were performed before the current evaluation was begun or whether the separate evaluations overlap in time). Section TC-5, "General Interpreted Requirements," outlines the application of the TCSEC requirements to individual TCB subsets when an evaluation by parts is being done. Section TC-6, "Design Choices" describes the general process of applying TCB subsets and meeting the conditions for evaluation by parts. The treatment in this section is general and not limited to DBMSs; DBMS-specific issues are discussed in the appendices. TC-2 REFERENCE MONITOR PERSPECTIVE Building or evaluating a system for compliance with the requirements of a particular class in the TCSEC is based on the perspective of the Trusted Computing Base (TCB). The notion of the TCB is central to the entire concept of assessing systems for trust. The reference monitor described in the Anderson report [1] is the basis of the notion of a TCB, as described in the TCSEC: For convenience, these evaluation criteria use the term Trusted Computing Base to refer to the reference validation mechanism, be it a security kernel, front-end security filter, or the entire trusted computer system. [8, p. 67] Even in those lower classes (below B2) where the reference monitor concept and reference validation mechanisms are not mentioned explicitly, the perspective of the reference monitor and its implementation as a reference validation mechanism is present. Specifically, there are requirements for (1) identifying the policy being enforced, (2) identifying subjects and objects, (3) providing evidence that the operation of the reference validation mechanism matches the high-level description of the user interface, and (4) demonstrating isolation of the TCB. Therefore, all TCSEC evaluations share the initial conceptual steps of identifying the mediation policy, the subjects, and the objects. Starting from a global system perspective, the initial step is to identify the access mediation policy that will be enforced. One must then identify those active system entities that are candidates for being the "subjects" whose access to objects the TCB will mediate. Similarly, one must identify those passive entities, those data repositories, that are candidates for being the "objects," access to which the TCB will mediate. As usual, the existence of an abstraction within a system does not make it necessarily a reference-monitor object, i.e., one visible at the TCB interface. This is because the TCB will make use of system abstractions for both its internal processes and its storage requirements. Those entities, while being stored in system "objects," will not be available to untrusted processes (that is, they are not exported by the TCB). Thus the analytical, iterative step is the separation of candidate subjects and objects into those that are mediated by the TCB and those that are not. The various trust classes include requirements, at varying levels of completeness and rigor, that the basic reference monitor perspective of mediating access of subjects to objects be implemented in a correct, self-protecting, and non-bypassable manner. The core requirements of the TCSEC classes focus on these reference monitor imperatives. The increasingly strict requirements for visibility into the system design and implementation (structure, documentation, testing, configuration, and distribution requirements) all support the notion of checking the system's conformance to its identified intent with regard to the subjects, objects, and policy. TC-3 NEED FOR EVALUATION BY PARTS The need to be able to evaluate and certify systems built in parts is increasingly evident. This need is seen in a variety of contexts: The need to evaluate and certify systems built out of parts sold by different vendors, a situation especially prevalent in the field of trusted DBMSs. The need to re-assess systems that have undergone either small- or large-scale improvements and are already evaluated and placed on the Evaluated Products List (EPL). The general problem of "families of systems," systems that exist on a spectrum of hardware bases or that can be customized for a user's specific needs. In all such cases, two related versions of a system are largely similar. It should be possible to undertake evaluations and certifications in such a way that the entire assessment does not have to be re-done for every slight variation that appears. The current state of technology, however, places limitations on what can be accomplished in this regard; it is not currently possible to determine the trust characteristics of a system on the basis of an arbitrary collection of subparts. The overall task of trust assessment entails so many interrelated subtasks that the ability to separate and reassemble is not well understood. In this circumstance of needing to be able to accommodate evaluation of a system built in parts and the lack of consensus about how this can be done in a technically sound fashion, a conservative approach must be adopted. The following are required: (1) a clear description of what "parts" will be considered for separate evaluation; (2) a clear description of the conditions under which such an evaluation by parts will be undertaken; and (3) a general interpretation of TCSEC requirements as they would apply when a system is being evaluated by parts. The "parts" that will be considered by separate evaluation are called "TCB subsets," the topic of Section TC-4 below. TC-4 TCB SUBSETS TC-4.1 INTRODUCTION To attempt an evaluation of a TCB by splitting it into parts, there must be available a precise definition of what parts are candidates for separate evaluation (that is, for evaluation by parts) as well as any other conditions that must be satisfied before an evaluation by parts will be undertaken. This section defines "TCB subset" as a strict and conservative extension of the traditional concept of the reference validation mechanism (RVM) as a method of delineating which parts of a TCB can be candidates for separate evaluation. The definition of TCB subsets, as well as explanatory and motivational material, is included below in Section TC-4.2, "TCB Subsets Context." Section TC-4.3 addresses the conditions that must be satisfied by a TCB divided into a set of TCB subsets before evaluation by parts will be undertaken. These conditions assure that the structure of and relationships among TCB subsets will satisfy TCSEC requirements, especially those derived from the reference monitor concept. TC-4.2 TCB SUBSETS CONTEXT TC-4.2.1 DEFINITION OF TCB SUBSETS A TCB subset M is a set of software, firmware, and hardware (where any of these three could be absent) that mediates the access of a set S of subjects to a set O of objects on the basis of a stated access control policy P and satisfies the properties: 1) M mediates every access to objects in O by subjects in S; 2) M is tamper resistant; and 3) M is small enough to be subject to analysis and tests, the completeness of which can be assured. M uses resources provided by an explicit set of more primitive TCB subsets to create the objects of O, create and manage its data structures, and enforce the policy P. If there are no TCB subsets more primitive than M, then M uses only hardware resources to instantiate its objects, to create and manage its own data structures, and to enforce its policy. The above definition does not explicitly prohibit an access control policy P that allows trusted subjects. The implications for the evaluation process when a TCB subset's policy allows or does not allow such trusted subjects are substantial and are discussed in Section TC-6.4. As described in TC-4.3, one of the conditions for an evaluation by parts of a TCB made up of TCB subsets is that all the trusted subjects of each TCB subset be included in that TCB subset. TC-4.2.2 MOTIVATION The definition of "TCB subset" is intended to parallel the definitions of the reference monitor and reference validation mechanism found in the Anderson report [1] and included in the TCSEC itself. "The term Trusted Computing Base [refers] to the reference validation mechanism, be it security kernel, front-end security filter, or the entire trusted computer system." [8, p. 67] "TCB subset" is defined exactly like a reference validation mechanism, with only one difference, that it does not necessarily extend to the hardware. Rather, a TCB subset uses either hardware resources or the resources provided by other, more primitive TCB subsets. Thus TCB subsets build on abstract machines, either physical hardware machines or other TCB subsets. Just like reference validation mechanisms, a TCB subset must enforce a defined access control policy. TC-4.3 CONDITIONS FOR EVALUATION BY PARTS Building or evaluating a system using the definition of TCB subsets in the section above requires meeting six conditions in addition to demonstrating that the candidate TCB subsets satisfy the properties appropriate to the evaluation target class. The conditions are as follows: The candidate TCB subsets are identified; The system policy is allocated to the candidate TCB subsets; Each candidate TCB subset M[i] includes all the trusted subjects with respect to its technical policies P[i]; The TCB subset structure or architecture is explicitly described; Each TCB subset occupies distinct subset-domains; and The more primitive TCB subsets provide support for the RVM arguments for less primitve TCB subsets. These conditions are described below. TC-4.3.1 CANDIDATE TCB SUBSETS The first condition is that the relevant elements of each candidate TCB subset M[i] be identified. The hardware, firmware, and software which compose the TCB subset need to be clearly identified, along with the subjects and objects. In terms of Section TC-4.2.1, this condition is the identification of M[i], S[i], and O[i]. There may be no objects mediated by more than one TCB subset. That is, there cannot be an object O that is both in O[i] and O[j]. TC-4.3.2 POLICY ALLOCATION The next condition is policy allocation, the description of the technical policy P[i] for each identified M[i] along with the relation of these policies to the system policy P. The policies P[i] will be expressed in terms of subjects in S[i] and objects in O[i]. Thus, to satisfy the TCSEC requirement that the (composite) TCB enforce its stated policy P, each rule in P must be traceable through the structure of the candidate TCB subsets to the TCB subset(s) where that enforcement occurs. See Sections TC-5.2.1.1 and TC-5.2.1.4. TC-4.3.3 TRUSTED SUBJECTS INCLUDED Every trusted subject with respect to P[i] must be part of the TCB subset M[i]. This condition makes possible separate evaluation of TCB subsets with respect to "local" requirements. When this condition is not met, evaluation of candidate TCB subsets cannot be guaranteed on an evaluation by parts basis. This situation is treated in Section 6.4. TC-4.3.4 TCB SUBSET STRUCTURE The TCB subsets will exhibit a structure based on the ordering implied by dependency. TCB subset A is less primitive than TCB subset B if (a) A directly depends on B or (b) a chain of TCB subsets from A to B exists such that each element of the chain directly depends on its successor in the chain. In this case we use the phrase "TCB subset B is more primitive than TCB subset A" synonymously. The sense of "directly depend" in (a) is exactly the following: it is not possible to verify the implementation of A with respect to its specification without a statement about the specification of B. More precisely, for a candidate TCB subset M, let sM denote the specification of M. The specification will include, as a minimum, the statement of the technical policy P of M. Further, let vM denote the (engineering) demonstrations of the correct implementation of M with respect to its specification. A (candidate) TCB subset A "depends (for its correctness)" on (candidate) TCB subset B if and only if the arguments of vA assume, wholly or in part, that sB has been implemented correctly. (See Appendix B, item 5 for additional discussion.) The proposed structure of TCB subsets has to be identified. The order must be a partial order. (Without a partial order, there could be circular chains of dependencies that would inhibit separate evaluations of the TCB subsets.) TC-4.3.5 SEPARATE SUBSET-DOMAINS The candidate TCB subsets must operate in near isolation from each other, with the only interaction between them being that explicitly asserted as part of the interface. In the case of reference monitors, many existing implementations have relied on the domain concept [23] which supports the assertions of non-bypassability and self protection. A natural extension of the domain concept will be required for isolation of TCB subsets from each other and from non-TCB entities. A subset-domain is a set of system domains. Each candidate TCB subset must occupy a distinct subset-domain such that modify-access to a TCB subset's subset-domain is permitted only to that TCB subset and (possibly) to more primitive TCB subsets. This requirement ensures that the structure of subset-domains with respect to access is consonant with the dependency relation among TCB subsets. TC-4.3.6 SUPPORT FOR RVM ARGUMENTS Candidate TCB subsets must satisfy the three RVM properties included in the definition in TC-4.2.1 in order to complete evaluation by parts successfully. TCB subsets that build on resources and functionality provided by more primitive TCB subsets must rely on assured and evaluatable characteristics of those more primitive TCB subsets. A convincing argument must be advanced that the features, characteristics, and assurances provided by the more primitive TCB subsets are capable of supporting RVM arguments for the less primitive TCB subsets. The first property (mediating every access) requires that there is no way of bypassing the mediation provided by TCB subset M for its objects, either directly or by unexpected side-effects of interactions with other TCB subsets. A variety of approaches could suffice for demonstrating this property. The second property (tamper resistance) requires that the policy-critical code and data for the less primitive TCB subset be protected from any alteration not specifically allowed by the TCB subset. A variety of approaches could suffice for demonstrating this property. The third property (completeness of testing and analysis for correctness) requires the (engineering) demonstrations vM[i] of the correctness of each less primitive candidate TCB subset M[i]. A convincing argument must therefore be advanced that the specifications sM[k] for all of the more primitive TCB subsets M[k] on which M[i] depends will suffice for establishing vM[i]. TC-4.4 EVALUATION ALTERNATIVES As noted earlier, the need to evaluate systems whose elements are developed separately, possibly by independent developers, results in the need to define TCB subsets. That is not to say, however, that design by TCB subsetting and the subsequent evaluation by parts are the only alternatives. Rather, there are three distinct possibilities. A system TCB, regardless of any internal structure, may be viewed as a single entity. In such a case, the evaluation may proceed essentially as an evaluation against the TCSEC. This case is examined in Section TC-6.2. A system TCB may be presented as a subsetted architecture composed of a number of candidate TCB subsets. Given that each of the candidate TCB subsets satisfies the conditions set forth in Section TC-4.3, an evaluation by parts is possible. This case is described in Section TC-6.3. It may be possible to satisfy only some of the conditions for evaluation by parts. This situation might arise when a previously evaluated TCB or TCB subset is modified to accommodate the policy-enforcing elements of a new application layer. A special case of this situation is described in Section TC-6.4. In such cases, depending upon the particulars, it may be possible to realize some of the savings in evaluation effort. However, no general statements can be made for these cases. TC-5 GENERAL INTERPRETED REQUIREMENTS TC-5.1 OVERVIEW This section provides specific interpretations of those TCSEC requirements that are particularly relevant for subsetted architectures and evaluation by parts. Its organization is derived from the structure of the TCSEC requirements. For each relevant TCSEC requirement there is a discussion of how that requirement is interpreted in an evaluation by parts. For conciseness, only the requirements headings applicable for A1 systems are included below. Thus, the interpretation guidance below should be applied only as demanded by the requirements for the target class of the candidate trusted system. For a system targeted at an evaluation class below A1, only those requirements that pertain to the target class apply to the TCB subsets making up that system. A listing of the requirements and interpretations by TCSEC class is presented in Appendix A. The rationale for the applicability of the TCSEC requirements to TCB subsets alone or to the TCB as an entirety is described in Appendix B, item 7. TC-5.2 DETAILED REQUIREMENTS TC-5.2.1 SECURITY POLICY TC-5.2.1.1 Discretionary Access Control The discretionary access control requirements apply as stated in the TCSEC to every TCB subset whose policy includes discretionary access control of its subjects to its objects. Any TCB subset whose policy does not include such discretionary access control is exempt from this requirement. TC-5.2.1.2 Object Reuse This requirement applies as stated in the TCSEC to every TCB subset in the TCB. TC-5.2.1.3 Labels This requirement applies as stated in the TCSEC to every TCB subset whose policy includes mandatory access control of its subjects to its objects. Any TCB subset whose policy does not include such mandatory access control is exempt from this requirement. Label Integrity This requirement applies as stated in the TCSEC to every TCB subset whose policy includes mandatory access control of its subjects to its objects. Any TCB subset whose policy does not include such mandatory access control is exempt from this requirement. Exportation of Labeled Information This requirement applies as stated in the TCSEC to every TCB subset whose policy includes mandatory access control of its subjects to its objects. Any TCB subset whose policy does not include such mandatory access control is exempt from this requirement. Subject Sensitivity Labels This requirement applies as stated in the TCSEC to the entire TCB. The cooperative action of the TCB subsets making up the TCB must satisfy the requirement. Device Labels This requirement applies as stated in the TCSEC to every TCB subset whose policy includes mandatory access control of its subjects to its objects and has attached physical or virtual devices. Any TCB subset whose policy does not include such mandatory access control or has no attached physical or virtual devices is exempt from this requirement. This requirement can be satisifed by the cooperative action of more than one TCB subset. TC-5.2.1.4 Mandatory Access Control This requirement applies as stated in the TCSEC to every TCB subset whose policy includes mandatory access control of its subjects to its objects. Any TCB subset whose policy does not include such mandatory access control is exempt from this requirement. TC-5.2.2 ACCOUNTABILITY TC-5.2.2.1 Identification and Authentication This requirement applies as stated in the TCSEC to the entire TCB. The cooperative action of the TCB subsets making up the TCB must satisfy the requirement. If the TCB is composed of TCB subsets, one TCB subset may either rely on a mechanism in another TCB subset to provide identification and authentication services or provide the services directly. Similarly, that TCB subset may rely on a mechanism in another more primitive TCB subset to ensure that the security level of subjects external to the TCB that may be created to act on behalf of the individual user are dominated by the clearance and authorization of that user. Each TCB subset may maintain its own identification and authentication data or one central repository may be maintained. If each TCB subset has its own data, then the information for each individual user must be consistent among all subsets. Trusted Path This requirement applies as stated in the TCSEC to the entire TCB. The cooperative action of the TCB subsets making up the TCB must satisfy the requirement. When TCB subsets are used, the requirement for trusted path at levels B2 and above remains applicable to the entire TCB. The need for trusted path "when positive TCB-to-user connection is required (e.g., login, change subject security level)" can require user interaction with virtually any TCB subset within the TCB. The implementation of trusted path could be localized in a single TCB subset. Alternatively, it could be implemented in more than one TCB subset if the separate implementations together comply with the system security policy. TC-5.2.2.2 Audit This requirement applies as stated in the TCSEC to the entire TCB. The cooperative action of the TCB subsets making up the TCB must satisfy the requirement. A TCB subset may maintain its own security audit log, distinct from that maintained by more primitive TCB subsets, or it may use an audit interface provided by a different TCB subset allowing the audit records it generates to be processed by that TCB subset. If the TCB subset uses different user identifications than a more primitive TCB subset, there shall be a means to associate audit records generated by different TCB subsets for the same individual with each other, either at the time they are generated or later. Any TCB subset wherein events may occur that require notification of the security administrator shall be able to do the following: (1) detect the occurrence of these events, (2) initiate the recording of the audit trail entry, and (3) initiate the notification of the security administrator. The ability to terminate events (2) and (3) above may be provided either in the TCB subset within which they occur, or in the TCB subset(s) where actions that lead to the event were initiated. The monitoring and notification requirements may require cooperation between multiple distinct TCB subsets or multiple instantiations of the same TCB subset. For example, to detect the accumulation of events for a single user it may be necessary to collect events from several subjects in distinct processes that are surrogates for the same user. As another example, there may be a single TCB subset that collects events from a number of other TCB subset instantiations and, based on its analysis of them, notifies the security administrator. TC-5.2.3 ASSURANCE TC-5.2.3.1 Operational Assurance System Architecture This requirement applies as stated in the TCSEC to every TCB subset, with the following additional interpretations. The TCB must provide domains for execution that are allocated to and used by TCB subsets according to the subset-domain condition for evaluation by parts. A most primitive TCB subset must provide domains for execution. A less primitive TCB subset must make use of domains provided by a more primitive TCB subset. A less primitive TCB subset may provide further execution domains but is not required to do so. Similarly, the TCB must provide distinct address spaces for untrusted processes. A most primitive TCB subset must provide distinct address spaces for its subjects. A less primitive TCB subset must make use of the distinct address space provided by a more primitive TCB subset. A less primitive TCB subset may provide more fine-grained distinct address spaces, but is not required to do so. In general, requirements specifically referring to hardware or firmware apply only to TCB subsets that include hardware or firmware. The exception is the requirement that the TCB make effective use of available hardware. This requirement applies to those TCB subsets that use resources provided by more primitive TCB subsets in lieu of hardware. Those TCB subsets are required to make effective use of the protection-relevant features exported to it by the more primitive TCB subsets (e.g., execution domains, support for distinct address spaces) to separate those elements that are protection-critical from those that are not. System Integrity This requirement applies as stated in the TCSEC to every TCB subset that includes hardware or firmware. Any TCB subset that does not include hardware or firmware is exempt from this requirement. Covert Channel Analysis This requirement applies as stated in the TCSEC to the entire TCB. When the TCB is made up entirely of TCB subsets meeting the conditions for evaluation by parts, analysis of the individual TCB subsets satisfies this requirement. Otherwise, covert channel analysis of the entire TCB must be performed (even if the results of covert channel analysis of the individual TCB subsets were available). Trusted Facility Management This requirement applies as stated in the TCSEC to the entire TCB. Any "operator" or "administrator" functions intrinsic to an individual TCB subset must be supported by that TCB subset or by a more primitive TCB subset. Trusted Recovery This requirement applies as stated in the TCSEC to the entire TCB and to the individual TCB subsets. The cooperative recovery actions of the TCB subsets making up the TCB must provide trusted recovery for the overall TCB. Otherwise, trusted recovery evaluation must address the entire TCB (even if the individual TCB subsets meet the trusted recovery requirements). TC-5.2.3.2 Life-Cycle Assurance Security Testing This requirement applies as stated in the TCSEC to the entire TCB. If a TCB consists of TCB subsets meeting the conditions for evaluation by parts, the satisfaction of the requirements by each TCB subset satisfies the requirement for the entire TCB. Otherwise, security testing of the entire TCB must be performed (even if the results of testing the individual TCB subsets were available). Design Specification and Verification This requirement applies as stated in the TCSEC to every TCB subset, with the following specific additional interpretations. It must be demonstrated that the security policy enforced by the composite TCB is represented by the collection of policy models for the individual TCB subsets. The argument that the descriptive top level specification (DTLS) and formal top level specification (FTLS) are consistent with the TCB interface applies to the entire TCB. There is required an explicit and convincing description of how the set of top level specifications (one for each TCB subset) describes the TCB interface in terms of exceptions, errors, and effects. Configuration Management This requirement applies as stated in the TCSEC to every TCB subset in the TCB, with the following additional interpretation. Because subsets of the TCB may be developed independently, a single configuration management system may not be feasible. However, the combination of configuration management systems used to support all the TCB subsets must meet all the stated requirements. The information describing the interrelations between separate TCB subsets and separate security policy models falls into the category of "all documentation and code associated with the current version of the TCB" in the TCSEC requirements. Trusted Distribution This requirement applies as stated in the TCSEC to the entire TCB. It can be met by satisfying the requirements for each TCB subset if procedures exist for assuring that all TCB subsets upon which a particular TCB subset depends (that is, the more primitive TCB subsets) are exactly the same version as specified for the TCB subset in question. TC-5.2.4 DOCUMENTATION TC-5.2.4.1 Security Features User's Guide This requirement applies as stated in the TCSEC to every TCB subset in the TCB. This collection of guides must include descriptions of every TCB subset in the TCB and explicit cross-references to other related user's guides to other TCB subsets, as required. In addition, interactions between mechanisms within different TCB subsets must be clearly described. TC-5.2.4.2 Trusted Facility Manual This requirement applies as stated in the TCSEC to the TCB and to every TCB subset in the TCB. This requirement can be met by providing a set of manuals, one for each distinct (non-replicated) TCB subset. Each manual shall address the functions and privileges to be controlled for the associated TCB subset. Additionally, it must clearly show the interfaces to, and the interaction with, more primitive TCB subsets. The manual for each TCB subset shall identify the functions and privileges of the TCB subsets on which the associated TCB subset depends. Also, the TCB subset's manual shall identify which, if any, configuration options of the more primitive TCB subsets are to be used for the composite TCB to operate securely. Any pre-defined roles supported (e.g., database administrator) by the TCB subset shall be addressed. The means for correlating multiple audit logs and synonymous user identifications from multiple TCB subsets (if such exist) shall also be addressed. The trusted facility manual shall describe the composite TCB so that the interactions among the TCB subsets can be readily determined. Other manuals may be referenced in this determination. The manuals that address the distinct modules of the TCB and the generation of the TCB need to be integrated with the other trusted facility manuals only to the extent that they are affected by the use and operation (versus the development) of the composite TCB. The TCB modules that contain the reference validation mechanism must be associated with the TCB subset to which they belong. The procedure for generating a new TCB after modifying only one (or several) TCB subsets must be described. This may be accommodated by independent regeneration of the individual TCB subsets or by regeneration of only the affected TCB subsets. TC-5.2.4.3 Test Documentation This requirement applies as stated in the TCSEC to the composite TCB. TC-5.2.4.4 Design Documentation This requirement applies as stated in the TCSEC to the composite TCB, with the following specific additional interpretations: Requirements concerning models, FTLS and DTLS, apply to individual TCB subsets. The requirement concerning the description of interfaces between modules of the TCB includes the interfaces between TCB subsets. The documentation of the implementation of a reference validation mechanism must include justification for meeting the conditions for evaluation by parts. The A1 requirement to describe clearly non-FTLS internals of the TCB applies to TCB subsets. TC-5.3 SUMMARY OF THE REQUIREMENTS The requirements interpretations in Section TC-5.2 above can be grouped into two categories: those that apply to individual TCB subsets and those that apply totally or in part to the overall TCB. For purposes of exposition, the former category will be termed "local requirements," that is, those for which separate analysis of the individual TCB subsets suffices to determine compliance for the composite TCB. The latter are termed "global requirements," that is, those which require analysis of the entire system and for which separate analysis of the individual TCB subsets does not suffice. TC-5.3.1 LOCAL REQUIREMENTS Discretionary Access Control; Object Reuse; Labels (except Subject Sensitivity Labels); Mandatory Access Control; System Architecture (except domains for execution and distinct address spaces); System Integrity; Configuration Management; Security Features User's Guide; Design Documentation models, DTLSs, FTLSs, and non-FTLS internals. TC-5.3.2 GLOBAL REQUIREMENTS Subject Sensitivity Labels; Identification and Authentication; Trusted Path; Audit; System Architecture domains for execution, and distinct address spaces; Covert Channel Analysis; Trusted Facility Management; Trusted Recovery (also applies to individual TCB subsets); Security Testing; Design Specification and Verification correspondence between system policy and the set of TCB subset models consistency of TCB interface with the set of TCB subset DTLSs, and consistency ofTCB interface with the set of TCB subset FTLSs; Trusted Distribution; Trusted Facility Manual (also applies to individual TCB subsets); Test Documentation; and Design Documentation (except models, DTLSs, FTLSs, and non-FTLS internals). TC-6 DESIGN CHOICE TC-6.1 OVERVIEW This section examines the several design choices available for constructing systems in parts and the consequences of each when attempting to perform an evaluation by parts. The first case described is that of a TCB evaluated under the TCSEC without benefit of TCB subset structuring. This case is of value for several reasons: it serves as a reference point; it can be considered the degenerate case of subsetting; and it is always an option to evaluate any TCB, regardless of internal structure, as a monolith. The second and third cases are presented in terms of a configuration of exactly two subsets; the generalization to more than two TCB subsets is straightforward. The second case is that of a subsetted architecture that exactly satisfies the conditions for evaluation by parts. The third case represents a special case of an altered TCB, one which is implemented using trusted subjects. Note that no evaluation using TCB subsets and evaluation by parts results in a TCB subset receiving an evaluation rating. Rather, the entire system, with its composite TCB, is evaluated and receives a rating. However, evaluation by parts is intended to allow the results of local analysis of individual TCB subsets to be distinguishable and separately referencable. For further discussion of this topic, see Appendix B, item 10. TC-6.2 A SINGLE TCB SUBSET The evaluation of a TCB consisting of a single TCB subset is equivalent to a straightforward evaluation against the TCSEC. The conditions for evaluation by parts (Section TC-4.3) reduce to requirements found in the TCSEC itself. TC-6.2.1 ANALYSIS OF THE CONDITIONS TC-6.2.1.1 Condition 1: Candidate TCB Subsets The TCB (hardware, software, and firmware), as distinguished from the rest of the computing system, must be identified. This is a basic requirement for TCSEC evaluation. Similarly, the subjects and objects within the system must be identified. The requirement that no more than one TCB subset mediate access to any particular object is satisfied, because there is only one TCB subset. TC-6.2.1.2 Condition 2: Policy Allocation The policy P enforced by the TCB (subset) must be identified. The demonstration that the TCB (subset) enforces that policy will be a description of how the TCB performs access mediation between the system's subjects and objects according a system-level description of limitations on access (the technical policy P[i] of the definition). The tracing of the policy to the system design and behavior is part of the stated TCSEC requirements. ?TC-6.2.1.3 Condition 3: Trusted Subjects Included This condition is satisfied in the same manner as it is in evaluations under the TCSEC. Specifically, the TCB boundary is shown to be the interface that is presented to untrusted subjects. TC-6.2.1.4 Condition 4: TCB Subset Structure Satisfaction of this condition (TC-4.3.4) is immediate, because there is only one TCB subset. TC-6.2.1.5 Condition 5: Separate Subset-Domains Satisfaction of the separate subset-domain condition (TC-4.3.5) is identical to the C1 through A1 requirement that "the TCB maintain a domain for its own execution that protects it from external interference or tampering." [8, p. 13 et al.] TC-6.2.1.6 Condition 6: Support for RVM Arguments Satisfaction of this condition (TC-4.3.6) is immediate, inasmuch as there are no less primitive TCB subsets that must be demonstrated to satisfy RVM requirements. TC-6.2.2 EVALUATION CONSEQUENCES In this case, the evaluation of the (single) TCB subset proceeds exactly like an evaluation under the TCSEC. Demonstration that the candidate system meets all the global and local requirements (as they apply to the target evaluation class) includes the consideration of each requirement as it applies system's philosophy of protection, design, documentation, and implementation. The system must be shown to exhibit the properties of a reference validation mechanism, appropriate to the target class. TC-6.3 TWO TCB SUBSETS, MEETING THE CONDITIONS This case is of a TCB that consists of two candidate TCB subsets, A and B, where A is the most primitive TCB subset. That is, B uses the abstractions provided by A (the objects, in particular) as its resource for the construction and exportation of its own abstractions. B also uses the abstractions provided by A for its metadata (that is, internal data structures) that make it possible for B to instantiate its exported abstractions as well as keep records that enable it to correctly enforce its stated policy. In terms of the discussion of Section TC-4.3.4, TCB subset B directly depends on TCB subset A. It will be assumed that TCB subset A enforces mandatory and discretionary policies on its objects and that TCB subset B enforces a discretionary policy on the objects it exports. Additionally, all trusted subjects of A are contained within A. Thus, every subject of A (including all the active entities that make up the logic of B) operates at a single sensitivity level. It will further be assumed for th is example that the mechanisms for domains and thus for subset-domains are independent of the mandatory and discretionary access control policy enforcement mechanisms. TC-6.3.1 ANALYSIS OF THE CONDITIONS TC-6.3.1.1 Condition 1: Candidate TCB Subsets The TCB (hardware, software, and firmware), as distinguished from the rest of the computing system, must be identified. This is a basic requirement for TCSEC evaluation. Similarly, the subjects and objects within the system must be identified. In this case, all the hardware, software, and firmware that make up the TCB must be identified as being part of either TCB subset A or TCB subset B. The subjects and objects mediated by A (call them the "A-subjects" and "A-objects" for this discussion) must be identified. Similarly the B-subjects and B-objects must also be identified. The additional requirement in Section TC-4.3.1 that "there may not be any objects mediated by more than one TCB subset" means that there can be no B-object that is also an A-object. TC-6.3.1.2 Condition 2: Policy Allocation The policy P enforced by the whole TCB must be identified. In addition, the policy enforced by A (call it the A-policy), stated in terms of the A-subjects and the A-objects, must be identified. Similarly, the B-policy, stated in terms of the B-subjects and the B-objects, must be identified. TC-6.3.1.3 Condition 3: Trusted Subjects Included As was stated above, TCB Subset A contains all its own trusted subjects. There may be trusted subjects with respect to the policy of A, but all such subjects execute in the subset-domain of A. TC-6.3.1.4 Condition 4: TCB Subset Structure Because B directly uses the A-objects and its logic is embodied in A-subjects, the structure of the TCB subsets is precisely "TCB subset A is more primitive than TCB subset B." This is a partial order. TC-6.3.1.5 Condition 5: Separate Subset-Domains Satisfaction of the separate subset-domain condition requires that a set of domains provided by the system be identified as being the domains "occupied" by A and B. The domain, or domains, occupied by A is exactly the "domain for its own execution" found in the TCSEC requirements. The domain or domains occupied by TCB subset B must not be modifiable by any code or other system entity except possibly by TCB subset A. TC-6.3.1.6 Condition 6: Support for RVM Arguments Satisfying the condition for RVM arguments requires demonstrating the plausibility of being able to establish the three requisite properties of an RVM. The first property requires that no B-subject be allowed to access B-objects without those accesses being mediated by TCB subset B. The tamper resistance property requires that TCB subset A provide a way that TCB subset B can be designed and implemented such that A-subjects that are not part of B's implementation cannot tamper with B's policy-critical code or data. The third RVM property must be satisfied by the individual TCB subsets. The degree to which each TCB subset must satisfy this property is commensurate with the evaluation class of the TCB. TC-6.3.2 EVALUATION CONSEQUENCES In this case, the evaluation of the two TCB subsets requires that each meet TCSEC requirements applicable to each TCB subset viewed individually and that the two TCB subsets combine in a way to meet all the TCSEC requirements stated for the target class. All local requirements are imposed on the two TCB subsets, A and B, individually. If each TCB subset can meet the requirements of the target class, viewed as if it were a separate TCB, the only areas where additional evaluation or accreditation work might be required are those areas where the sum of the analysis of the parts is not necessarily complete and convincing. Those areas requiring additional work are exactly the set of global requirements described in Section TC-5.3.2. Demonstrating that the candidate system meets the TCSEC requirements (as they apply to the target evaluation class) requires that both A and B be evaluated with respect to the local requirements of the target class and that the composite TCB be evaluated for global requirements. In this case, full testing of TCB subset A against all the requirements (both local and global) simplifies the task of demonstrating satisfaction of the global requirements, both for B and for the entire TCB. Suppose, for example, that TCB subset A has been subjected to security testing appropriate to the target class and has been shown to be adequately resistant to penetration attacks. This means that within the confidence level provided by the testing requirement, no A-subject can subvert A's enforcement of its policy. In this situation, every active entity in B is an A-subject and hence B can neither penetrate A nor be induced to do so by any B-subject. Thus, no further testing of A will be required to determine whether the entire TCB is resistant to penetration; any additional penetration testing can be limited to determining the ability of B to withstand assault. Similarly, if A has been searched for covert channels (as required for its target class requirements), then no further search for covert channels will be required, either in the analysis of B or in the overall consideration of the entire TCB. Note that if B implements a mandatory access control policy (e.g., integrity), then it would be necessary to perform a covert channel analysis on B, but no further covert channel analysis of A would be required. The ability of users to determine the current sensitivity level of B-subjects operating on their behalf will have to be shown by considering the TCB subsets A and B together. This requirement is satisfied immediately if the argument relies exclusively on A meeting the requirement. TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS This case also concerns a TCB that consists of two candidate TCB subsets, C and D. C is the most primitive TCB subset. That is, D uses the abstractions provided by C (the objects, in particular) as its resource for the construction and exportation of its own abstractions. D also uses the abstractions provided by C for its metadata (that is, internal data structures) that make it possible for D to instantiate its exported abstractions as well as keep records that enable it to correctly enforce its stated policy. In terms of the discussion of Section TC-4.3.4, TCB subset D directly depends on TCB subset C. Additionally, D is trusted with respect to C. That is, some of the C-subjects which make up TCB subset D execute as trusted processes of C. Here also, as in the previous example, it is assumed that C implements mandatory and discretionary policies over its objects. Further, the intent of D is to implement a discretionary policy over the objects it exports. However, because D includes subjects which are trusted relative to C's policy demonstration of the full and correct enforcement of the mandatory policy requires analysis of both C and D and is no longer localized to TCB subset C. It will be assumed that the mechanisms for domains and thus for subset-domains are independent of the mandatory and discretionary access control policy enforcement mechanisms. This case can be viewed as a special case of a previously evaluated TCB which has been altered. However, the alteration takes the form of a less primitive subset which is implemented, at least in part, with trusted subjects (i.e., some of the C-subjects are trusted subjects which execute in the subset-domain of D). Although this case may appear, intuitively, to be different from that of arbitrary alteration of a previously evaluated TCB, the example demonstrates that such an approach makes it impossible to perform an evaluation by parts. TC-6.4.1 ANALYSIS OF THE CONDITIONS TC-6.4.1.1 Condition 1: Candidate TCB Subsets The identification of the TCB (hardware, software, and firmware) as distinguished from the rest of the computing system is a basic requirement for TCSEC evaluation. Likewise, the subjects and objects within the system must be identified. In this case, all the hardware, software, and firmware that make up the TCB must be identified as being part of either TCB subset C or TCB subset D. The C-subjects and C-objects mediated by C have to be identified. Similarly the D-subjects and D-objects must also be identified. The additional requirement in Section TC-4.3.1 that "there may not be any objects mediated by more than one TCB subset" means there can be no D-object that is also a C-object. TC-6.4.1.2 Condition 2: Policy Allocation The policy P enforced by the whole TCB must be identified. In addition, the individual policy enforced by C (call it the C-policy) must be identified in terms of the C-subjects and the C-objects. Similarly, the D-policy, stated in terms of the D-subjects and the D-objects, must be stated. In this case, the C-policy will include the strict enforcement of a mandatory access control policy that allows trusted subjects to execute in the subset-domains which compose TCB subset D. TC-6.4.1.3 Condition 3: Trusted Subjects Included This condition is not satisfied because D includes at least one subject that is trusted with respect to C. Hence a subject that is trusted with respect to the policy of C is outside C, and evaluation by parts is not an option. If TCB subset C had previously been evaluated, then this is an example of an altered TCB, albeit a special case. The change consists of the addition of one or more trusted C-subjects in D whose effect on the behavior of C cannot be predicted a priori. An assessment of the impact of D on the behavior of C cannot be made strictly by an examination of the trusted subjects and the definition of C's interface. A global assessment of C and D is required. TC-6.4.1.4 Condition 4: TCB Subset Structure Because D directly uses the C-objects and its logic is embodied in C-subjects, the structure of the TCB subsets is precisely "TCB subset C is more primitive than TCB subset D." This is a partial order. TC-6.4.1.5 Condition 5: Separate Subset-Domains Satisfying the separate subset-domain condition (TC-4.3.5) requires identifying the set of system domains (likely administered by the most primitive TCB subset C) as the domains "occupied" by C and D. The domain, or domains, occupied by C is exactly the "domain for its own execution" found in the TCSEC requirements. The domain or domains occupied by TCB subset D must not be modifiable by any code or other system entity except possibly by a part of TCB subset C. TC-6.4.1.6 Condition 6: Support for RVM Arguments Satisfying the condition for RVM arguments requires demonstrating the plausibility of being able to establish the three requisite properties of an RVM. The first property requires that no B-subject be allowed to access B-objects without those accesses being mediated by TCB subset B. The tamper resistance property requires that TCB subset A provide a way that TCB subset B can be designed and implemented such that A-subjects that are not part of B's implementation cannot tamper with B's policy-critical code or data. The third RVM property must be satisfied by the individual TCB subsets. The degree to which each TCB subset must satisfy this property is commensurate with the evaluation class of the TCB. TC-6.4.2 EVALUATION CONSEQUENCES In this example, the conditions for evaluation by parts are not satisfied and thus, the full potential for savings in evaluation effort cannot, in general, be realized. A clear option in such cases is to view the system as a monolithic TCB and proceed accordingly. However, because this case represents an example of an altered TCB, it admits of a wide spectrum of specific sub-cases. Thus, if the analysis of the system proceeds in parallel to that required for evaluation by parts it may be possible, in special cases, to identify elements of the analysis of the more primitive candidate TCB subset which can be successfully argued to be unaffected by the alterations. Some evaluation effort, often significant, can be saved, but unlike evaluation by parts, how much can only be estimated by consideration of the implementation specifics. For example, in this specific case, the local analysis of TCB subset C represents a reasonable candidate for analysis that need not be redone. TC-6.5 SUMMARY The three cases described above illustrate the effects of various TCB subsetting situations as they relate to the evaluation requirements. A monolithic evaluation proceeds exactly as described in the TCSEC, with requirements being applied to the entire TCB. When all the conditions for evaluation by parts are satisfied, considerable savings in evaluation effort are realized. The evaluation of a new system configuration that includes exactly the same TCB subset that was previously evaluated (such as the TCB subsets A and B in the Section TC-6.3) is limited to (a) local analysis of the individual TCB subsets (by reference to earlier analysis, if available) and (b) a simpler global analysis, because each TCB subset is an exact analog of a TCB. When the conditions for evaluation by parts are not satisfied, no general statements can be made about the factorability of analysis or the reusability of previous analysis. The extent to which previous evaluation evidence and results remain valid can be determined only on a case-by-case basis. PART 2 INTERPRETED REQUIREMENTS IR-1 OVERVIEW AND CONTEXT Part 2, "INTERPRETED REQUIREMENTS," provides specific interpretations of those TCSEC requirements which are deemed to be either DBMS-specific (or, more generally, application-specific) or particularly relevant to DBMSs. All of the requirements in the TCSEC apply in any case. For the topics included below, the interpretations provide clarification of the TCSEC requirements. As is the case for the TCSEC, the interpreted requirements at any class include those specified for that class in addition to interpretations for lower classes that have not been superseded or altered. Section IR-2 presents an overall summary of the TCSEC requirements, as interpreted in the more detailed sections that follow. Sections IR-3 through IR-7 address individual requirements interpretations for labels, audit, system architecture, design specification and verification, and design documentation, respectively. The format is an initial discussion of the topic in general, followed by specific requirements and interpretations that apply to database management systems. A listing of the requirements and interpretations organized by TCSEC class is presented in Appendix A. IR-2 SUMMARY OF THE INTERPRETATIONS This section provides specific interpretations of those TCSEC requirements that are particularly relevant for subsetted architectures and evaluation by parts. Its organization is derived from the structure of the TCSEC requirements. For each relevant TCSEC requirement there is a discussion of how that requirement is interpreted for a DBMS. IR-2.1 SECURITY POLICY IR-2.1.1 DISCRETIONARY ACCESS CONTROL The requirement for discretionary access control is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.1.2 OBJECT REUSE The requirement for object reuse is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.1.3 LABELS The requirement for labels is treated in Section IR-3 of this document. IR-2.1.4 MANDATORY ACCESS CONTROL The requirement for mandatory access control is not changed in the context of this document and therefore applies as stated in the TCSEC. However, there are several subtle ramifications of this requirement of which a developer or evaluator should be aware. A brief discussion can be found in Appendix B, item 8, "Content-Dependent and Context-Dependent Access Control." IR-2.2 ACCOUNTABILITY IR-2.2.1 IDENTIFICATION AND AUTHENTICATION The requirement for identification and authentication is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.2.2 AUDIT The requirement for audit is treated in Section IR-4 of this document. IR-2.3 ASSURANCE IR-2.3.1 OPERATIONAL ASSURANCE IR-2.3.1.1 System Architecture The requirement for system architecture is treated in Section IR-5 of this document. IR-2.3.1.2 System Integrity The requirement for system integrity is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.3.1.3 Covert Channel Analysis The requirement for covert channel analysis is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.3.1.4 Trusted Facility Management The requirement for trusted facility management is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.3.1.5 Trusted Recovery The requirement for trusted recovery is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.3.2 LIFE CYCLE ASSURANCE IR-2.3.2.1 Security Testing The requirement for security testing is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.3.2.2 Design Specification and Verification The requirement for design specification and verification is treated in Section IR-6 of this document. IR-2.3.2.3 Configuration Management The requirement for configuration management is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.3.2.4 Trusted Distribution The requirement for trusted distribution is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.4 DOCUMENTATION IR-2.4.1 SECURITY FEATURES USER'S GUIDE The requirement for a security features user's guide is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.4.2 TRUSTED FACILITY MANUAL The requirement for a trusted facility manual is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.4.3 TEST DOCUMENTATION The requirement for test documentation is not changed in the context of this document and therefore applies as stated in the TCSEC. IR-2.4.4 DESIGN DOCUMENTATION The requirement for design documentation is treated in Section IR-7 of this document. IR-3 LABELS IR-3.1 GENERAL DISCUSSION The labels requirements of the TCSEC are entirely applicable to database management systems. The basic difference between the TCSEC labeling requirements as they apply to operating systems and DBMSs involves which storage objects are labeled rather than how the labels are handled. This section discusses special considerations in implementing and evaluating labeling mechanisms in database management systems. Of particular importance is the selection of the storage objects that are to be labeled. Beginning at the B1 evaluation class, trusted database management systems are required to associate labels with all storage objects under their control. The granularity of storage objects to be protected shall be chosen by the DBMS designer. Stored view definitions (that is, named query commands) that are visible at the TCB boundary must be stored in labeled objects. The TCB must mediate access both to the view definition and to the view instantiation (that is, the set of labeled objects accessed as the result of executing the query command contained in the view definition). It has been proposed in several designs that views be used as a mechanism to implement context- or content-dependent labeling. The intuitive attractiveness of this approach is undeniable, but the implementation details must be carefully worked out to achieve a sound implementation. A brief discussion of this topic can be found in Appendix B, item 8, "Content-Dependent and Context-Dependent Access Control." TCB designers and evaluators may make distinctions between objects that are explicitly labeled or implicitly labeled. Such distinctions are meaningful only within the confines of the TCB; all storage objects are explicitly labeled from a point of view outside the TCB. For example, consider an object of one type (e.g., table or file) within the TCB that "contains" many (reference monitor) objects of another type (e.g., tuples and records). The file could have an explicit label associated with it, and some of the records could have explicit labels associated with them. Those records that have no explicit label would be implicitly labeled by the label of the file. For database management systems, the objects that store the base data of the database (e.g., files, records, relations, and tuples), as well as those objects that store the metadata (e.g., directories, indices, schemas, data dictionaries, discretionary authorization tables, recovery logs, and transaction logs), must be labeled. Objects that need not be labeled include internal resources that are not user visible (e.g., printer daemon scratch files and resource allocation tables). The requirement for importing data (labeled and unlabeled) is the same as in the TCSEC. For additional information, see Appendix B, item 9, "Bulk Loading of a Database." IR-3.2 SPECIFIC INTERPRETATIONS CLASS (B1): LABELED SECURITY PROTECTION There are no interpretations for this class. CLASS (B2): STRUCTURED PROTECTION Statement from TCSEC Sensitivity labels associated with each ADP system resource . . . that is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB. Interpretation Internal TCB variables that are not visible to untrusted subjects need not be labeled, provided that they are not directly or indirectly accessible by subjects external to the TCB. However, it is important to understand that such internal variables can function as covert signaling channels when untrusted subjects are able to detect changes in these variables by observing system behavior. CLASS (B3): SECURITY DOMAINS There are no additional requirements. CLASS (A1): VERIFIED DESIGN There are no additional requirements. IR-4 AUDIT IR-4.1 GENERAL DISCUSSION The audit requirements of the TCSEC apply to database management systems. This section discusses special considerations in designing and evaluating audit mechanisms in database management systems. The TCB must be capable of maintaining an audit trail of accesses and attempted accesses to the objects protected by the mandatory and discretionary security policies. Two examples are given to illustrate auditing techniques for discretionary access control decisions. Example 1. Consider a DBMS TCB providing discretionary controls on defined views of the database. Because the named object presented at the TCB interface is the view definition (not the records instantiated through the view), all that needs to be auditable is the use of the view by any untrusted subject. Example 2. Consider a DBMS TCB that enforces discretionary access control on individual data records. When a user enters a query, the construction of a response may involve a search over many records that are not returned to the user because they did not satisfy the query. Records that do satisfy the query but to which the user does not have access should be auditable. Records that do not satisfy the query need not be auditable. That is, in the context of audit, access permission to the user and satisfaction of a query are to be kept separate. There is no need to audit operations that are strictly internal to the TCB. Separate security audit logs may be maintained by the operating system and the database management system. Likewise, separate identifications for the same user may be maintained by the operating system and the database management system. The correlation of separate audit logs may be done either at the time they are generated or at some later time. The emphasis of the audit criterion is to provide individual accountability for actions by users. This goal is not the same as that for a backup and recovery log. There is no requirement to integrate the audit log with the backup and recovery log, although such an integrated log is not prohibited. At the designer's discretion, there may be a selectable capability to reduce the number of audit records generated in response to queries that involve many access control decisions. IR-4.2 SPECIFIC INTERPRETATIONS CLASS (C2): CONTROLLED ACCESS PROTECTION Statement from TCSEC The TCB shall be able to create, maintain, and protect from modification . . . an audit trail of accesses to the objects it protects. Interpretation Auditable events, in the case of a database management system, are the individual operations initiated by untrusted users (e.g., updates, retrievals, and inserts), not just the invocation of the database management system. The auditing mechanism shall have the capability of auditing all mediated accesses which are visible to users. That is, each discretionary access control policy decision shall be auditable. Individual operations performed by trusted software, if totally transparent to the user, need not be auditable. If the total audit requirement is met by the use of more than one audit log, a method of correlation must be available. CLASS (B1): LABELED SECURITY PROTECTION Statement from TCSEC The TCB shall be able to create, maintain, and protect from modification . . . an audit trail of accesses to the objects it protects. Interpretation Auditable events, in the case of a database management system, are the individual operations initiated by untrusted users (e.g., updates, retrievals, and inserts), not just the invocation of the database management system. The auditing mechanism shall have the capability of auditing all mediated accesses which are visible to the user. That is, each discretionary access control policy decision and each mandatory access control policy decision shall be auditable. Individual operations performed by trusted software, if totally transparent to the user, need not be auditable. If the total audit requirement is met by the use of more than one audit log, a method of correlation must be available. CLASS (B2): STRUCTURED PROTECTION There is no interpretation for the additional requirements. CLASS (B3): SECURITY DOMAINS There is no interpretation for the additional requirements. CLASS (A1): VERIFIED DESIGN There are no additional requirements. IR-5 SYSTEM ARCHITECTURE IR-5.1 GENERAL DISCUSSION The system architecture requirements of the TCSEC apply to database management systems. The interpretations provided are a duplication of the general interpreted requirements that apply to an evaluation by parts. They are included because DBMS evaluations often involve multiple TCB subsets. IR-5.2 SPECIFIC INTERPRETATIONS CLASS (C1): DISCRETIONARY SECURITY PROTECTION Statement from TCSEC The TCB shall maintain a domain for its own execution that protects it from external interference or tampering. Interpretation If the TCB is composed of multiple TCB subsets, this requirement applies to each TCB subset. CLASS (C2): CONTROLLED ACCESS PROTECTION There is no interpretation for the additional requirements. CLASS (B1): LABELED SECURITY PROTECTION There is no interpretation for the additional requirements. CLASS (B2): STRUCTURED PROTECTION Statement from TCSEC The user interface to the TCB shall be completely defined and all elements of the TCB identified. Interpretation If the TCB is composed of multiple subsets, this requirement applies to the interface between the TCB subsets as well as the user interface to the whole TCB. Statement from TCSEC It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not. Interpretation If the TCB is composed of multiple subsets, each TCB subset must make use of facilities provided to it by more primitive TCB subsets, such as support for execution domains and for distinct address spaces, to achieve the required separation. CLASS (B3): SECURITY DOMAINS There is no interpretation for the additional requirements. CLASS (A1): VERIFIED DESIGN There are no additional requirements. IR-6 DESIGN SPECIFICATION AND VERIFICATION IR-6.1 GENERAL DISCUSSION The design specification and verification requirements of the TCSEC, with the related documentation requirements, apply to database management systems. The interpretations provided include a duplication of general interpreted requirements that apply to an evaluation by parts. They are included because of the likelihood that a DBMS evaluation will involve multiple TCB subsets. In the database context, the set of candidates for "subject" and "object" can be larger than normally encountered in trusted operating systems. Where a database system builds on an underlying trusted operating system, for example, the set of candidate subjects for the two TCB subsets includes both the active entities created by the operating system and those active entities created by the trusted portion of the DBMS. The set of candidates for objects is large. Examples are files, segments, buffers, structures, pages, relations, tables, tuples, rows, columns, elements, entities, relationships, procedures, metadata, system tables, query trees, query plans, locking mechanisms, rollback mechanisms, indices, recovery and backup mechanisms, precalculated operations (such as joins), view definitions, view instantiations, constraints, authorization tables, data dictionary tables, and audit logs. The requirements in the TCSEC for showing how the various representations of the system being evaluated fit together can be represented as in Figure IR-1. For monolithic TCBs, the policy must be stated; the model must be developed, maintained, and shown to be sufficient to enforce the policy; and the DTLS (FTLS for A1) must be constructed and shown to correspond both to the model and to the TCB implementation. These steps allow a chain of reasoning to proceed from the stated policy to the assertion that the system in question actually enforces the policy. In the case of multiple TCB subsets, the intent is the same. Tracing all policy requirements to the actual system implementation must be possible, and vice versa. The current dilemma is that the theory and techniques for subdividing a model into a set of models (or a top level specification into a set of top level specifications) have not yet been established. Likewise neither theory or techniques have been established for composing a set of models or top level specifications into a unified model or top level specification. The absence of rigorous methods does not preclude an evaluation using a subsetted TCB. The process of mapping policy to implementation is possible for each TCB subset, using the same techniques required for a monolithic TCB. For subsetted TCBs, designers and evaluators must explicitly show how the policy, model and specifications for each TCB subset meet the TCSEC requirements. In addition, convincing informal arguments must be given to show how the collection of TCB subsets enforces the policy of the composite TCB. Because more rigorous composition methods are unavailable, convincing informal arguments are appropriate for evaluation of TCBs up to and including Class A1. The TCSEC requirements concerning the mapping from policy to implementation for a TCB composed of multiple TCB subsets raise these crucial topics: The allocation of policy to the TCB subsets, The relation of the models for the TCB subsets to the overall system policy, and The relation of the top level specification for each TCB subset to the entire system. Allocation of policy to the TCB subsets is a precise division of the policy for the entire system, as addressed in the policy allocation condition of Section TC-4.3. The second topic, above, requires that the policy for each TCB subset be stated. Additionally, it is required that there be an informal convincing argument that the collection of models represents the policy enforced by the entire system. The third topic, the way in which the set of top level specifications for the individual TCB subsets describes the composite TCB interface with respect to exceptions, errors and effects, is treated in a similar fashion. The top level specifications for each TCB subset must meet the requirement. There is, in addition, a requirement for an informal, convincing description of how the set of top level specifications describes the TCB interface with respect to exceptions, errors, and effects. At the A1 level, there is no requirement for additional formal specification or formal proofs beyond the specification and proofs specific to the individual TCB subsets. Rather than formally composing the policies, models, and specifications and performing a single monolithic evaluation, a series of separate evaluations may be performed (one for each TCB subset). The evaluations are then tied together by presentation of sufficient informal arguments that the individual policies collectively represent the policy enforced by the entire system, that the individual models collectively represent the system's policy, that the individual specifications represent the TCB interface, and that the source code of each TCB subset is consistent with its top level specification. Note that satisfactory completion of these requirements is logically equivalent to demonstrating that a "unified" model for the entire TCB is consistent with the policy enforced by the system, that a "unified" top level specification corresponds to the model, and that the "unified" top level specification(s) corresponds to the source code. These interpreted requirements, which do not mandate a "unified" top level specification, are technically achievable interpretations of the policy-tracing requirements in the case of multiple TCB subsets. IR-6.2 SPECIFIC INTERPRETATIONS CLASS (B1): LABELED SECURITY PROTECTION Statement from TCSEC An informal or formal model of the security policy supported by the TCB shall be maintained over the life cycle of the ADP system and demonstrated to be consistent with its axioms. Interpretation If the TCB is composed of multiple TCB subsets, this requirement applies to the security policy of each TCB subset. An informal argument that the set of policy models represents the "security policy supported by the [composite] TCB" must be provided. CLASS (B2): STRUCTURED PROTECTION Statement from TCSEC A formal model of the security policy supported by the TCB shall be maintained over the life cycle of the ADP system and demonstrated to be consistent with its axioms. Interpretation If the TCB is composed of multiple TCB subsets, this requirement applies to the security policy of each TCB subset. An informal argument that the set of policy models represents the "security policy supported by the [composite] TCB" must be provided. Statement from TCSEC A descriptive top-level specification (DTLS) of the TCB shall be maintained that completely and accurately describes the TCB in terms of exceptions, error messages, and effects. Interpretation If the TCB is composed of multiple TCB subsets, this requirement applies to the DTLS of each TCB subset. An informal argument that the set of DTLSs accurately describes the TCB must be provided. If there is a multifaceted policy (e.g., both mandatory access control and discretionary access control policies) in a particular TCB subset, then all facets must be represented in the DTLS and in the TCB subset's model. Statement from TCSEC The descriptive top-level specification (DTLS) shall be shown to be an accurate description of the TCB interface. Interpretation If the TCB is composed of multiple subsets, this requirement applies to the interface between the TCB subsets as well as to the user interface of the composite TCB. The TCB interface description shall include an explanation of how to describe the total TCB accurately, in the context of the multiple TCB subset DTLSs. CLASS (B3): SECURITY DOMAINS Statement from TCSEC A convincing argument shall be given that the DTLS is consistent with the model. Interpretation If the TCB is composed of multiple TCB subsets, this requirement applies to individual TCB subsets. Enforcement of all policies must be shown to occur in all situations (e.g., state transitions) required by the formal security policy model. In the case of a discretionary access control policy, the presence of the access control check at all identified state transitions is the total of what is required for demonstrating consistency between the DTLS and the model. This may be verified by inspection of the DTLS (that is, by visually checking that exception checks required by the model are present in the DTLS). For the mandatory access control policy, the DTLS must be shown by a convincing argument to be consistent with the model. CLASS (A1): VERIFIED DESIGN Statement from TCSEC A formal top-level specification (FTLS) of the TCB shall be maintained that accurately describes the TCB in terms of exceptions, error messages, and effects. Interpretation If the TCB is composed of multiple TCB subsets, this requirement applies to the FTLS of each TCB subset. An informal argument that the set of FTLSs accurately describes the TCB must be provided. If there is a multifaceted policy (e.g., both mandatory access control and discretionary access control policies) in a particular TCB subset, then all facets must be represented in the FTLS and in the TCB subset's model. Statement from TCSEC The FTLS shall be shown to be an accurate description of the TCB interface. Interpretation If the TCB is composed of multiple subsets, this requirement applies to the interface between the TCB subsets as well as to the user interface of the composite TCB. The TCB interface description shall include an explanation of how to describe the total TCB accurately, in the context of the multiple TCB subset DTLSs. Statement from TCSEC . . . a combination of formal and informal techniques shall be used to show that the FTLS is consistent with the model. Interpretation If the TCB is composed of multiple TCB subsets, this requirement applies to individual TCB subsets. Enforcement of all policies must be shown to occur in all situations (e.g., state transitions) required by the formal security policy model at the required occasions. In the case of a discretionary access control policy, the presence of the access control check at all identified state transitions is the total of what is required for demonstrating consistency between the FTLS and the model. This may be verified by inspection of the FTLS (that is, by visually checking that exception checks required by the model are present in the FTLS). For the mandatory access control policy, the FTLS must be shown by a combination of formal and informal techniques to be consistent with the model. IR-7 DESIGN DOCUMENTATION IR-7.1 GENERAL DISCUSSION The design documentation requirement of the TCSEC applies to database management systems. The interpretations provided are a duplication of the general interpreted requirements that apply to an evaluation by parts. They are included because DBMS evaluations often involve multiple TC