home *** CD-ROM | disk | FTP | other *** search
Text File | 1999-11-04 | 243.8 KB | 5,634 lines |
- Trusted Database Management System
- Interpretation
-
- NCSC-TG-021
-
- Library
-
- No. S235,625
-
- FOREWORD
-
- The National Computer Security Center is issuing the Trusted Database
- Management System Interpretation as part of the Technical Guidelines
- Program, through which we produce the "Rainbow Series."
-
- In the Rainbow Series, we discuss in detail the features of the Trusted
- Computer System Evaluation Criteria (DoD 5200.28-STD) and provide guidance
- for meeting each requirement. The National Computer Security Center,
- through its Trusted Product Evaluation Program, analyzes the security
- features of commercially produced and supported computer systems.
- Together, these programs ensure that organizations are capable of
- protecting their important data with trusted computer systems.
-
- The Trusted Database Management System Interpretation extends the
- evaluation classes of the Trusted Computer System Evaluation Criteria to
- trusted applications in general, and database management systems in
- particular. It serves as an adjunct to the Trusted Computer System
- Evaluation Criteria by providing a technical context for the consideration
- of entire systems constructed of parts and by presenting database-specific
- interpretation of topics that require direct comment. Thus, it is relevant
- to applications which support sharing of computer services and resources,
- and which enforce access control policies. More specifically, it provides
- insight into the the design, implementation, evaluation, and accreditation
- of database management systems.
-
- This document will be used for at least one year after the date of
- signature. During this period the NCSC will gain experience using the
- Trusted Database Management Systems Interpretation in several evaluations
- and continue to receive comments on issues of technical accuracy, clarity
- of exposition, and utility. After this trial period, necessary changes
- will be made and a revised version issued.
-
- PATRICK R. GALLAGHER, JR.
-
- April 1991
-
- Director National Computer Security Center
-
- ACKNOWLEDGMENTS
-
- This document represents the combined effort of participants from the
- research community, industry, and government working over several years.
- Three major drafts and numerous intermediary versions were produced,
- reviewed, and commented upon. To name all the contributors would be
- impossible. To single out a few would be to slight a host of others who
- gave unstintingly of their time and talent. To all those who contributed
- to the development and refinement of the fundamental concepts, contributed
- to the development of the several predecessor versions, and who
- contributed valuable personal time and invaluable experience in reviewing
- and commenting on the previous versions, thanks is extended.
-
- TABLE OF CONTENTS
-
- FOREWORD i
-
- ACKNOWLEDGMENTS iii
-
- INTRODUCTION 1
-
- HISTORICAL PERSPECTIVE 1
-
- SCOPE 2
-
- PURPOSE 2
-
- STRUCTURE OF THE DOCUMENT 4
-
- PART 1 TECHNICAL CONTEXT 7
-
- TC-1 INTRODUCTION 9
-
- TC-2 REFERENCE MONITOR PERSPECTIVE 10
-
- TC-3 NEED FOR EVALUATION BY PARTS 11
-
- TC-4 TCB SUBSETS 11
-
- TC-4.1 INTRODUCTION 12
-
- TC-4.2 TCB SUBSETS CONTEXT 13
-
- TC-4.2.1 DEFINITION OF TCB SUBSETS 13
-
- TC-4.2.2 MOTIVATION 13
-
- TC-4.3 CONDITIONS FOR EVALUATION BY PARTS 14
-
- TC-4.3.1 CANDIDATE TCB SUBSETS 14
-
- TC-4.3.2 POLICY ALLOCATION 15
-
- TC-4.3.3 TRUSTED SUBJECTS INCLUDED 15
-
- TC-4.3.4 TCB SUBSET STRUCTURE 15
-
- TC-4.3.5 SEPARATE SUBSET-DOMAINS 16
-
- TC-4.3.6 SUPPORT FOR RVM ARGUMENTS 16
-
- TC-4.4 EVALUATION ALTERNATIVES 17
-
- TC-5 GENERAL INTERPRETED REQUIREMENTS 18
-
- TC-5.1 OVERVIEW 18
-
- TC-5.2 DETAILED REQUIREMENTS 18
-
- TC-5.2.1 SECURITY POLICY 18
-
- TC-5.2.1.1 Discretionary Access Control 18
-
- TC-5.2.1.2 Object Reuse 18
-
- TC-5.2.1.3 Labels 19
-
- TC-5.2.1.4 Mandatory Access Control 20
-
- TC-5.2.2 ACCOUNTABILITY 20
-
- TC-5.2.2.1 Identification and Authentication 20
-
- TC-5.2.2.2 Audit 21
-
- TC-5.2.3 ASSURANCE 22
-
- TC-5.2.3.1 Operational Assurance 22
-
- TC-5.2.3.2 Life-Cycle Assurance 23
-
- TC-5.2.4 DOCUMENTATION 24
-
- TC-5.2.4.1 Security Features User's Guide 24
-
- TC-5.2.4.2 Trusted Facility Manual 25
-
- TC-5.2.4.3 Test Documentation 26
-
- TC-5.2.4.4 Design Documentation 26
-
- TC-5.3 SUMMARY OF THE REQUIREMENTS 26
-
- TC-5.3.1 LOCAL REQUIREMENTS 26
-
- TC-5.3.2 GLOBAL REQUIREMENTS 27
-
- TC-6 DESIGN CHOICES 28
-
- TC-6.1 OVERVIEW 28
-
- TC-6.2 A SINGLE TCB SUBSET 28
-
- TC-6.2.1 ANALYSIS OF THE CONDITIONS 28
-
- TC-6.2.1.1 Condition 1: Candidate TCB Subsets 28
-
- TC-6.2.1.2 Condition 2: Policy Allocation 29
-
- TC-6.2.1.3 Condition 3: Trusted Subjects Included 29
-
- TC-6.2.1.4 Condition 4: TCB Subset Structure 29
-
- TC-6.2.1.5 Condition 5: Separate Subset-Domains 29
-
- TC-6.2.1.6 Condition 6: Support for RVM Arguments 29
-
- TC-6.2.2 EVALUATION CONSEQUENCES 29
-
- TC-6.3 TWO TCB SUBSETS,MEETING THE CONDITIONS 30
-
- TC-6.3.1 ANALYSIS OF THE CONDITIONS 30
-
- TC-6.3.1.1 Condition 1: Candidate TCB Subsets 30
-
- TC-6.3.1.2 Condition 2: Policy Allocation 31
-
- TC-6.3.1.3 Condition 3: Trusted Subjects Included 31
-
- TC-6.3.1.4 Condition 4: TCB Subset Structure 31
-
- TC-6.3.1.5 Condition 5: Separate Subset-Domains 31
-
- TC-6.3.1.6 Condition 6: Support for RVM Arguments 31
-
- TC-6.3.2 EVALUATION CONSEQUENCES 32
-
- TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS 33
-
- TC-6.4.1 ANALYSIS OF THE CONDITIONS 34
-
- TC-6.4.1.1 Condition 1: Candidate TCB Subsets 34
-
- TC-6.4.1.2 Condition 2: Policy Allocation 34
-
- TC-6.4.1.3 Condition 3: Trusted Subjects Included 34
-
- TC-6.4.1.4 Condition 4: TCB Subset Structure 35
-
- TC-6.4.1.5 Condition 5: Separate Subset-Domains 35
-
- TC-6.4.1.6 Condition 6: Support for RVM Arguments 35
-
- TC-6.4.2 EVALUATION CONSEQUENCES 35
-
- TC-6.5 SUMMARY 36
-
- PART 2 INTERPRETED REQUIREMENTS 37
-
- IR-1 OVERVIEW AND CONTEXT 39
-
- IR-2 SUMMARY OF THE INTERPRETATIONS 39
-
- IR-2.1 SECURITY POLICY 39
-
- IR-2.1.1 DISCRETIONARY ACCESS CONTROL 39
-
- IR-2.1.2 OBJECT REUSE 40
-
- IR-2.1.3 LABELS 40
-
- IR-2.1.4 MANDATORY ACCESS CONTROL 40
-
- IR-2.2 ACCOUNTABILITY 40
-
- IR-2.2.1 IDENTIFICATION AND AUTHENTICATION 40
-
- IR-2.2.2 AUDIT 40
-
- IR-2.3 ASSURANCE 40
-
- IR-2.3.1 OPERATIONAL ASSURANCE 40
-
- IR-2.3.1.1 System Architecture 40
-
- IR-2.3.1.2 System Integrity 40
-
- IR-2.3.1.3 Covert Channel Analysis 41
-
- IR-2.3.1.4 Trusted Facility Management 41
-
- IR-2.3.1.5 Trusted Recovery 41
-
- IR-2.3.2 LIFE CYCLE ASSURANCE 41
-
- IR-2.3.2.1 Security Testing 41
-
- IR-2.3.2.2 Design Specification and Verification 41
-
- IR-2.3.2.3 Configuration Management 41
-
- IR-2.3.2.4 Trusted Distribution 41
-
- IR-2.4 DOCUMENTATION 42
-
- IR-2.4.1 SECURITY FEATURES USER'S GUIDE 42
-
- IR-2.4.2 TRUSTED FACILITY MANUAL 42
-
- IR-2.4.3 TEST DOCUMENTATION 42
-
- IR-2.4.4 DESIGN DOCUMENTATION 42
-
- IR-3 LABELS 42
-
- IR-3.1 GENERAL DISCUSSION 42
-
- IR-3.2 SPECIFIC INTERPRETATIONS 43
-
- IR-4 AUDIT 44
-
- IR-4.1 GENERAL DISCUSSION 44
-
- IR-4.2 SPECIFIC INTERPRETATIONS 45
-
- IR-5 SYSTEM ARCHITECTURE 47
-
- IR-5.1 GENERAL DISCUSSION 47
-
- IR-5.2 SPECIFIC INTERPRETATIONS 47
-
- IR-6 DESIGN SPECIFICATION AND VERIFICATION 48
-
- IR-6.1 GENERAL DISCUSSION 48
-
- IR-6.2 SPECIFIC INTERPRETATIONS 52
-
- IR-7 DESIGN DOCUMENTATION 55
-
- IR-7.1 GENERAL DISCUSSION 55
-
- IR-7.2 SPECIFIC INTERPRETATIONS 56
-
- APPENDIX A 59
-
- CLASS (C1): 62
-
- C1-1 SECURITY POLICY 62
-
- C1-2 ACCOUNTABILITY 62
-
- C1-3 ASSURANCE 62
-
- C1-4 DOCUMENTATION 63
-
- CLASS (C2): 66
-
- C2-1 SECURITY POLICY 66
-
- C2-2 ACCOUNTABILITY 66
-
- C2-3 ASSURANCE 67
-
- C2-4 DOCUMENTATION 68
-
- CLASS (B1): 70
-
- B1-1 SECURITY POLICY 70
-
- B1-2 ACCOUNTABILITY 71
-
- B1-3 ASSURANCE 73
-
- B1-4 DOCUMENTATION 74
-
- CLASS (B2): 77
-
- B2-1 SECURITY POLICY 77
-
- B2-2 ACCOUNTABILITY 79
-
- B2-3 ASSURANCE 81
-
- B2-4 DOCUMENTATION 85
-
- CLASS (B3): 89
-
- B3-1 SECURITY POLICY 89
-
- B3-2 ACCOUNTABILITY 91
-
- B3-3 ASSURANCE 93
-
- B3-4 DOCUMENTATION 98
-
- CLASS (A1): 102
-
- A1-1 SECURITY POLICY 102
-
- A1-2 ACCOUNTABILITY 104
-
- A1-3 ASSURANCE 106
-
- A1-4 DOCUMENTATION 112
-
- APPENDIX B 117
-
- 1. PERSPECTIVE ON ASSURANCE 119
-
- 2. PROCUREMENT OPTIONS 120
-
- 3. ALTERATION OF PREVIOUSLY EVALUATED TCB 122
-
- 4. SATISFYING RVM REQUIREMENTS 125
-
- 5. SUBSET DEPENDENCY 127
-
- 6. TAMPER RESISTANCE ARGUMENTS 131
-
- 7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS 132
-
- 8 CONTENT-DEPENDENT AND CONTEXT-DEPENDENT
-
- ACCESS CONTROL 136
-
- 9. BULK LOADING OF A DATABASE 137
-
- 10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT 137
-
- 11. RATING MORE COMPLEX SYSTEMS 139
-
- GLOSSARY 141
-
- BIBLIOGRAPHY 145
-
- INTRODUCTION
-
- HISTORICAL PERSPECTIVE
-
- The Department of Defense Trusted Computer System Evaluation Criteria
- (TCSEC), published in 1983 as CSC-STD-001-83, consolidates knowledge about
- the degree of trust one can place in a computer system to protect
- sensitive information and organizes this knowledge into usable criteria
- for system evaluation. The TCSEC was republished as a DoD standard,
- DoD-5200.28-STD, in December 1985 to provide a means of evaluating
- specific security features and assurances available in "trusted,
- commercially available automatic data processing system The TCSEC's rating
- scale extends from a minimal to a high level of trust with advanced
- security features and sophisticated assurance measures. Specific criteria
- determine each rating level and guide system builders and evaluators in
- determining the level of trust provided by specific systems. When the
- rating levels are combined with environmental guidelines and minimum
- security protection requirements, accreditation decisions for specific
- installations can be made.
-
- The philosophy of protection embodied in the TCSEC requires that the
- access of subjects (i.e., processes in a domain) to objects (i.e.,
- containers of information) be mediated in accordance with an explicit and
- well-defined security policy. At the higher criteria classes, the
- "reference monitor concept" [1] is an essential part of the system and the
- security policy is modeled. There are several security policy models that
- represent the desired behavior of a reference monitor. The Bell-La Padula
- model [4-6] and its Multics interpretation [3] are commonly used, but not
- mandated.
-
- The computer security research and development that underpin the TCSEC
- began in the late 1960s and concentrated on secure operating systems. By
- the early 1970s initial worked examples had provided a substantial amount
- of information about building trust into operating systems. Research
- continued throughout the 1970s to refine mechanisms, features, and
- assurances needed to provide trusted operating systems.
-
- Multilevel database management security received far less research and
- development attention than did secure operating systems. This was
- primarily due to the perception that one could not credibly implement a
- multilevel secure database management system (DBMS) on top of an untrusted
- operating system base. However, some research in multilevel secure DBMSs
- (mostly theoretical) was conducted during the 1970s [15-16], and research
- has continued to the present [9-14, 17-19, 22, 25-28]. By the mid 1980s,
- commercially developed, trusted operating systems were becoming available
- that could provide the basis for hosting secure applications such as
- multilevel secure DBMSs.
-
- In June 1986, the National Computer Security Center (NCSC) initiated its
- efforts to address the
-
- evaluation of trusted database management systems with an Invitational
- Workshop in Baltimore, Maryland. Representatives from the research,
- commercial, and government communities met to address issues of database
- management security. The met to discuss aspects of trust (defined by the
- that were sufficiently well defined and capable producing repeatable and
- objective assessments. The NCSC invited issue papers and prepared a
- agenda. The issue papers and the subcommittee summaries were published as
- the Proceedings of the National Computer Security Center Invitational
- Workshop on Database Security [20].
-
- As an outgrowth of this workshop, the NCSC undertook the task of preparing
- this Trusted Database Management System Interpretation (TDI) of the TCSEC
- to focus on the special problems posed by DBMSs. A working group was
- assembled to draft this Interpretation. Three drafts were produced, with
- extensive community review and public discussion. This Interpretation is
- the result of the interaction within the general computer security and
- database management communities.
-
- SCOPE
-
- The interpretations in this document are intended to be used in
- conjunction with the TCSEC itself; they apply to application-oriented
- software systems in general, and database management systems (DBMSs) in
- particular. Although the interpretations, as noted, are general enough to
- apply to any software system which supports sharing and needs to enforce
- access control (e.g., transaction processing systems, electronic mail
- systems), in the interest of simplicity, the discussion, and thus the
- terminology, will be directed toward DBMSs.
-
- The interpretations are intended to be applied primarily to commercially
- developed trusted DBMSs, but can also be applied to the evaluation of
- existing non-commercial DBMSs and to the specification of security
- requirements for DBMS acquisitions.
-
- PURPOSE
-
- This Interpretation of the TCSEC has been prepared for the following
- purposes:
-
- ₧ To provide a standard to manufacturers for security features to build
- into their new and planned commercial products in order to provide widely
- available systems that satisfy trust requirements (with particular
- emphasis on preventing the disclosure of data) for sensitive applications,
-
- ₧ To provide a metric with which to evaluate the degree of trust that can
- be placed in computer systems for the secure processing of classified and
- other sensitive information, and
-
- ₧ To provide a basis for specifying security requirements in acquisition
- specifications.
-
- With respect to the second purpose for development of the criteria, i.e.,
- providing a security evaluation metric, evaluations can be delineated into
- two types: (1) evaluations performed on a computer product from a
- perspective that excludes the application environment; or, (2) evaluations
- to assess whether appropriate security measures have been taken to permit
- the system to be used operationally in a specific environment. The former
- type of evaluation is done by the National Computer Security Center (NCSC)
- through the Trusted Product Evaluation Program and is called "formal
- product evaluation."
-
- The latter type of evaluation, that is, one done for the purpose of
- assessing a system's security attributes with respect to a specific
- operational mission, is known as a "certification evaluation." A formal
- product evaluation does not constitute certification or accreditation for
- the system to be used in any specific application environment. The system
- security certification and the formal approval/accreditation procedure,
- done in accordance with the applicable policies of the issuing agencies,
- must still be followed before a system can be approved for use in
- processing or handling sensitive or classified information. Designated
- Approving Authorities (DAAs) remain ultimately responsible for specifying
- the security of systems they The TCSEC and this Interpretation will be
- used directly and indirectly in the certification process. Along with
- applicable policy, they will be used directly as technical guidance for
- evaluation of the total system and for specifying system security and
- certification requirements for new acquisitions. Where a system being
- evaluated for certification employs a product that has undergone a formal
- product evaluation, reports from that process will be used as input to the
- certification evaluation. Moreover, the National Security Agency plans to
- publish additional guidelines to assist certifiers and help ensure
- consistency in certifications of systems processing national security
- informantion.
-
- STRUCTURE OF THE DOCUMENT
-
- The remainder of the TDI is divided into two parts, plus two appendices
- and a glossary.
-
- PART 1, TECHNICAL CONTEXT, "presents general information about the
- evaluation of trusted systems that are constructed of several parts. This
- discussion is critical to trusted DBMSs built upon trusted operating
- systems, but is not limited to DBMSs only. It is included in the TDI
- because it is not currently available in any previously published
- document. This section reviews the central reference monitor concept,
- explains the need to evaluate a system built of well-defined parts, and
- develops the concept of TCB subsets. TCB subsets provide a way of
- splitting a total TCB along access control policy lines such that an
- evaluation by parts can be undertaken. PART 1 concludes with an
- interpretation of those TCSEC requirements which are relevant to an
- evaluation by parts, and a description of the process of evaluation by
- parts.
-
- PART 2, INTERPRETED REQUIREMENTS, "provides interpretions of those TCSEC
- requirements that are either specific to DBMSs (or applications in
- general), or are particularly relevant to DBMSs. The number of
- requirements that are treated explicitly is relatively small, because many
- of the TCSEC requirements apply as stated to database management systems.
- The requirements treated explicitly are labels, audit, system
- architecture, design specification and verification, and design
- documentation.
-
- Appendix A summarizes the interpreted requirements for each TCSEC class
- and is intended to provide an easy reference for those requiring a listing
- of requirements for a specific class (e.g., B2). Appendix B provides
- discussion of several topics not directly tied to the requirements levied
- on trusted DBMSs by the interpretation of the TCSEC requirements.
-
- The TDI proper will be supplemented by a Companion Document Series (CDS).
- The CDS will address a wide spectrum of issues related to trusted DBMSs
- but which are beyond the scope of this document. Community debate about
- on-going topics of interest will probably result in gradual extensions of
- what is known about trusted DBMSs. Thus, volumes in the CDS will be issued
- both regularly (to document the state of the community debate) and by
- exception (to record new problems and new solutions).
-
- PART 1 TECHNICAL CONTEXT
-
- TC-1 INTRODUCTION
-
- Modern computing systems are rarely conceived and built by a single
- organization. Rather, the rule is that systems are constructed by
- assembling parts?hardware, firmware, and software?produced independently
- by various organizations or vendors.
-
- This fact introduces a fundamental difficulty into the task of evaluating
- a "system" for conformance to the trust requirements of the Trusted
- Computer System Evaluation Criteria (TCSEC). [8] This difficulty stems
- from the fact that assessment (either evaluation of a product or
- certification of a system) entails a global perspective of the entire
- system under consideration. There are not yet widely accepted methods of
- factoring the various aspects of a trust assessment and then reassembling
- the results into a statement about the whole.
-
- These conflicting perspectives of local production and global evaluation
- analysis are particularly evident in the field of database management, but
- they are by no means limited to that field. Thus the publication of this
- Interpretation requires consideration of how to deal with systems built in
- parts in the absence of a general treatment of the topic. On the other
- hand, any treatment of the issue in the context of trusted database
- management will have significant influence in other fields where the same
- or similar problems arise, just because of community review and NCSC
- publication. The approach taken in this document is to address the issues
- of evaluating systems built of parts in a way that is independent of the
- field of trusted database management. This conscious attitude of
- generality is intended to make clear the distinction between the larger
- system-of-parts issues and the more specific DBMS issues.
-
- PART 1, "TECHNICAL CONTEXT," is divided into six sections. Section TC-2,
- "Reference Monitor Perspective," summarizes the role of the reference
- monitor concept in both the TCSEC and the assessing of a system for its
- trust characteristics. Section TC-3, "Need for Evaluation by Parts," deals
- with the need to extend the reference monitor perspective slightly to
- begin to address the evaluation of systems constructed of separate parts.
- Section TC-4, "TCB Subsets," is the heart of PART 1. That section
- introduces a conservative extension to the reference validation mechanism,
- TCB subsets. This extension provides the basis for being able to undertake
- evaluation of systems built in parts in a way that allows re-use of the
- results of separate evaluations (whether those evaluations were performed
- before the current evaluation was begun or whether the separate
- evaluations overlap in time). Section TC-5, "General Interpreted
- Requirements," outlines the application of the TCSEC requirements to
- individual TCB subsets when an evaluation by parts is being done. Section
- TC-6, "Design Choices" describes the general process of applying TCB
- subsets and meeting the conditions for evaluation by parts. The treatment
- in this section is general and not limited to DBMSs; DBMS-specific issues
- are discussed in the appendices.
-
- TC-2 REFERENCE MONITOR PERSPECTIVE
-
- Building or evaluating a system for compliance with the requirements of a
- particular class in the TCSEC is based on the perspective of the Trusted
- Computing Base (TCB). The notion of the TCB is central to the entire
- concept of assessing systems for trust. The reference monitor described in
- the Anderson report [1] is the basis of the notion of a TCB, as described
- in the TCSEC:
-
- For convenience, these evaluation criteria use the term Trusted Computing
- Base to refer to the reference validation mechanism, beit a security
- kernel, front-end security filter, or the entire trusted computer system.
- [8, p. 67] Even in those lower classes (below B2) where the reference
- monitor concept and reference validation mechanisms are not mentioned
- explicitly, the perspective of the reference monitor and its
- implementation as a reference validation mechanism is present.
- Specifically, there are requirements for (1) identifying the policy being
- enforced, (2) identifying subjects and objects, (3) providing evidence
- that the operation of the reference validation mechanism matches the
- high-level description of the user interface, and (4) demonstrating
- isolation of the TCB.
-
- Therefore, all TCSEC evaluations share the initial conceptual steps of
- identifying the mediation policy, the subjects, and the objects. Starting
- from a global system perspective, the initial step is to identify the
- access mediation policy that will be enforced. One must then identify
- those active system entities that are candidates for being the "subjects"
- whose access to objects the TCB will mediate. Similarly, one must identify
- those passive entities, those data repositories, that are candidates for
- being the "objects," access to which the TCB will mediate.
-
- As usual, the existence of an abstraction within a system does not make it
- necessarily a reference-monitor object, i.e., one visible at the TCB
- interface. This is because the TCB will make use of system abstractions
- for both its internal processes and its storage requirements. Those
- entities, while being stored in system "objects," will not be available to
- untrusted processes (that is, they are not exported by the TCB). Thus the
- analytical, iterative step is the separation of candidate subjects and
- objects into those that are mediated by the TCB and those that are not.
-
- The various trust classes include requirements, at varying levels of
- completeness and rigor, that the basic reference monitor perspective of
- mediating access of subjects to objects be implemented in a correct,
- self-protecting, and non-bypassable manner. The core requirements of the
- TCSEC classes focus on these reference monitor imperatives. The
- increasingly strict requirements for visibility into the system design and
- implementation (structure, documentation, testing, configuration, and
- distribution requirements) all support the notion of checking the system's
- conformance to its identified intent with regard to the subjects, objects,
- and policy.
-
- TC-3 NEED FOR EVALUATION BY PARTS
-
- The need to be able to evaluate and certify systems built in parts is
- increasingly evident. This need is seen in a variety of contexts:
-
- The need to evaluate and certify systems built out of parts sold by
- different vendors, a situation especially prevalent in the field of
- trusted DBMSs.
-
- The need to re-assess systems that have undergone either small- or
- large-scale improvements and are already evaluated and placed on the
- Evaluated Products List (EPL).
-
- The general problem of "families of systems," systems that exist on a
- spectrum of hardware bases or that can be customized for a user's specific
- needs.
-
- In all such cases, two related versions of a system are largely similar.
- It should be possible to undertake evaluations and certifications in such
- a way that the entire assessment does not have to be re-done for every
- slight variation that appears. The current state of technology, however,
- places limitations on what can be accomplished in this regard; it is not
- currently possible to determine the trust characteristics of a system on
- the basis of an arbitrary collection of subparts. The overall task of
- trust assessment entails so many interrelated subtasks that the ability to
- separate and reassemble is not well understood.
-
- In this circumstance of needing to be able to accommodate evaluation of a
- system built in parts and the lack of consensus about how this can be done
- in a technically sound fashion, a conservative approach must be adopted.
- The following are required: (1) a clear description of what "parts" will
- be considered for separate evaluation; (2) a clear description of the
- conditions under which such an evaluation by parts will be undertaken; and
- (3) a general interpretation of TCSEC requirements as they would apply
- when a system is being evaluated by parts. The "parts" that will be
- considered by separate evaluation are called "TCB subsets," the topic of
- Section TC-4 below.
-
- TC-4 TCB SUBSETS
-
- TC-4.1 INTRODUCTION
-
- To attempt an evaluation of a TCB by splitting it into parts, there must
- be available a precise definition of what parts are candidates for
- separate evaluation (that is, for evaluation by parts) as well as any
- other conditions that must be satisfied before an evaluation by parts will
- be undertaken. This section defines "TCB subset" as a strict and
- conservative extension of the traditional concept of the reference
- validation mechanism (RVM) as a method of delineating which parts of a TCB
- can be candidates for separate evaluation. The definition of TCB subsets,
- as well as explanatory and motivational material, is included below in
- Section TC-4.2, "TCB Subsets Context." Section TC-4.3 addresses the
- conditions that must be satisfied by a TCB divided into a set of TCB
- subsets before evaluation by parts will be undertaken. These conditions
- assure that the structure of and relationships among TCB subsets will
- satisfy TCSEC requirements, especially those derived from the reference
- monitor concept.
-
- TC-4.2 TCB SUBSETS CONTEXT
-
- TC-4.2.1 DEFINITION OF TCB SUBSETS
-
- A TCB subset M is a set of software, firmware, and hardware (where any of
- these three could be absent) that mediates the access of a set S of
- subjects to a set O of objects on the basis of a stated access control
- policy P and satisfies the properties:
-
- 1) M mediates every access to objects in O by subjects in S;
- 2) M is tamper resistant; and
- 3) M is small enough to be subject to analysis and tests, the
- completeness of which can be assured.
-
- M uses resources provided by an explicit set of more primitive TCB
- subsets to create the objects of O, create and manage its data
- structures, and enforce the policy P. If there are no TCB subsets
- more primitive than M, then M uses only hardware resources to
- instantiate its objects, to create and manage its own data
- structures, and to enforce its policy.
- The above definition does not explicitly prohibit an access control
- policy P that allows trusted subjects. The implications for the
- evaluation process when a TCB subset's policy allows or does not
- allow such trusted subjects are substantial and are discussed in
- Section TC-6.4. As described in TC-4.3, one of the conditions for an
- evaluation by parts of a TCB made up of TCB subsets is that all the
- trusted subjects of each TCB subset be included in that TCB subset.
-
-
- TC-4.2.2 MOTIVATION
-
- The definition of "TCB subset" is intended to parallel the definitions of
- the reference monitor and reference validation mechanism found in the
- Anderson report [1] and included in the TCSEC itself. "The term Trusted
- Computing Base [refers] to the reference validation mechanism, be it
- security kernel, front-end security filter, or the entire trusted computer
- system." [8, p. 67] "TCB subset" is defined exactly like a reference
- validation mechanism, with only one difference, that it does not
- necessarily extend to the hardware. Rather, a TCB subset uses either
- hardware resources or the resources provided by other, more primitive TCB
- subsets. Thus TCB subsets build on abstract machines, either physical
- hardware machines or other TCB subsets. Just like reference validation
- mechanisms, a TCB subset must enforce a defined access control policy.
-
- TC-4.3 CONDITIONS FOR EVALUATION BY PARTS
-
- Building or evaluating a system using the definition of TCB subsets in the
- section above requires meeting six conditions in addition to demonstrating
- that the candidate TCB subsets satisfy the properties appropriate to the
- evaluation target class. The conditions are as follows:
-
- The candidate TCB subsets are identified;
-
- The system policy is allocated to the candidate TCB subsets;
-
- Each candidateTCB subset M[i] includes all the trusted subjects with
- respect to its technical policies P[i];
-
- The TCB subset structure or architecture is explicitly described;
-
- Each TCB subset occupies distinct subset-domains; and
-
- The more primitive TCB subsets provide support for the RVM arguments for
- less primitve TCB subsets.
-
- These conditions are described below.
-
- TC-4.3.1 CANDIDATE TCB SUBSETS
-
- The first condition is that the relevant elements of each candidate TCB
- subset M[i] be identified. The hardware, firmware, and software which
- compose the TCB subset need to be clearly identified, along with the
- subjects and objects. In terms of Section TC-4.2.1, this condition is the
- identification of M[i], S[i], and O[i]. There may be no objects mediated
- by more than one TCB subset. That is, there cannot be an object O that is
- both in O[i] and O[j].
-
- TC-4.3.2 POLICY ALLOCATION
-
- The next condition is policy allocation, the description of the technical
- policy P[i] for each identified M[i] along with the relation of these
- policies to the system policy P. The policies P[i] will be expressed in
- terms of subjects in S[i] and objects in O[i]. Thus, to satisfy the TCSEC
- requirement that the (composite) TCB enforce its stated policy P, each
- rule in P must be traceable through the structure of the candidate TCB
- subsets to the TCB subset(s) where that enforcement occurs. See Sections
- TC-5.2.1.1 and TC-5.2.1.4.
-
- TC-4.3.3 TRUSTED SUBJECTS INCLUDED
-
- Every trusted subject with respect to P[i] must be part of the TCB subset
- M[i]. This condition makes possible separate evaluation of TCB subsets
- with respect to "local" requirements. When this condition is not met,
- evaluation of candidate TCB subsets cannot be guaranteed on an evaluation
- by parts basis. This situation is treated in Section 6.4.
-
- TC-4.3.4 TCB SUBSET STRUCTURE
-
- The TCB subsets will exhibit a structure based on the ordering implied by
- dependency. TCB subset A is less primitive than TCB subset B if (a) A
- directly depends on B or (b) a chain of TCB subsets from A to B exists
- such that each element of the chain directly depends on its successor in
- the chain. In this case we use the phrase "TCB subset B is more primitive
- than TCB subset A" synonymously.
-
- The sense of "directly depend" in (a) is exactly the following: it is not
- possible to verify the implementation of A with respect to its
- specification without a statement about the specification of B.
-
- More precisely, for a candidate TCB subset M, let sM denote the
- specification of M. The specification will include, as a minimum, the
- statement of the technical policy P of M. Further, let vM denote the
- (engineering) demonstrations of the correctimplementation of M with
- respect to its specification.
-
- A (candidate) TCB subset A depends (for its correctness)" on (candidate)
- TCB subset B if and only if the arguments of vA assume, wholly or in part,
- that sB has been implemented correctly. (See Appendix B, item 5 for
- additional discussion.)
-
- The proposed structure of TCB subsets has to be identified. The order must
- be a partial order. (Without a partial order, there could be circular
- chains of dependencies that would inhibit separate evaluations of the TCB
- subsets.)
-
- TC-4.3.5 SEPARATE SUBSET-DOMAINS
-
- The candidate TCB subsets must operate in near isolation from each other,
- with the only interaction between them being that explicitly asserted as
- part of the interface. In the case of reference monitors, many existing
- implementations have relied on the domain concept [23] which supports the
- assertions of non-bypassability and self protection. A natural extension
- of the domain concept will be required for isolation of TCB subsets from
- each other and from non-TCB entities.
-
- A subset-domain is a set of system domains.
-
- Each candidate TCB subset must occupy a distinct subset-domain such that
- modify-access to a TCB subset's subset-domain is permitted only to that
- TCB subset and (possibly) to more primitive TCB subsets. This requirement
- ensures that the structure of subset-domains with respect to access is
- consonant with the dependency relation among TCB subsets.
-
- TC-4.3.6 SUPPORT FOR RVM ARGUMENTS
-
- Candidate TCB subsets must satisfy the three RVM properties included in
- the definition in TC-4.2.1 in order to complete evaluation by parts
- successfully. TCB subsets that build on resources and functionality
- provided by more primitive TCB subsets must rely on assured and
- evaluatable characteristics of those more primitive TCB subsets. A
- convincing argument must be advanced that the features, characteristics,
- and assurances provided by the more primitive TCB subsets are capable of
- supporting RVM arguments for the less primitive TCB subsets.
-
- The first property (mediating every access) requires that there is no way
- of bypassing the mediation provided by TCB subset M for its objects,
- either directly or by unexpected side-effects of interactions with other
- TCB subsets. A variety of approaches could suffice for demonstrating this
- property.
-
- The second property (tamper resistance) requires that the policy-critical
- code and data for the less primitive TCB subset be protected from any
- alteration not specifically allowed by the TCB subset. A variety of
- approaches could suffice for demonstrating this property.
-
- The third property (completeness of testing and analysis for correctness)
- requires the (engineering) demonstrations vM[i] of the correctnessof each
- less primitive candidate TCB subset M[i]. Aconvincing argument must
- therefore be advanced that the specifications sM[k] for all of the more
- primitive TCB subsets M[k] on which M[i] depends will suffice for
- establishing vM[i].
-
- TC-4.4 EVALUATION ALTERNATIVES
-
- As noted earlier, the need to evaluate systems whose elements are
- developed separately, possibly by independent developers, results in the
- need to define TCB subsets. That is not to say, however, that design by
- TCB subsetting and the subsequent evaluation by parts are the only
- alternatives. Rather, there are three distinct possibilities.
-
- A system TCB, regardless of any internal structure, may be viewed as a
- single entity. In such a case, the evaluation may proceed essentially as
- an evaluation against the TCSEC. This case is examined in Section TC-6.2.
-
- A system TCB may be presented as a subsetted architecture composed of a
- number of candidate TCB subsets. Given that each of the candidate TCB
- subsets satisfies the conditions set forth in Section TC-4.3, an
- evaluation by parts is possible. This case is described in Section TC-6.3.
-
- It may be possible to satisfy only some of the conditions for evaluation
- by parts. This situation might arise when a previously evaluated TCB or
- TCB subset is modified to accommodate the policy-enforcing elements of a
- new application layer. A special case of this situation is described in
- Section TC-6.4. In such cases, depending upon the particulars, it may be
- possible to realize some of the savings in evaluation effort. However, no
- general statements can be made for these cases.
-
- TC-5 GENERAL INTERPRETED REQUIREMENTS
-
- TC-5.1 OVERVIEW
-
- This section provides specific interpretations of those TCSEC requirements
- that are particularly relevant for subsetted architectures and evaluation
- by parts. Its organization is derived from the structure of the TCSEC
- requirements. For each relevant TCSEC requirement there is a discussion of
- how that requirement is interpreted in an evaluation by parts.
-
- For conciseness, only the requirements headings applicable for A1 systems
- are included below. Thus, the interpretation guidance below should be
- applied only as demanded by the requirements for the target class of the
- candidate trusted system. For a system targeted at an evaluation class
- below A1, only those requirements that pertain to the target class apply
- to the TCB subsets making up that system.
-
- A listing of the requirements and interpretations by TCSEC class is
- presented in Appendix A. The rationale for the applicability of the TCSEC
- requirements to TCB subsets alone or to the TCB as an entirety is
- described in Appendix B, item 7.]
-
- TC-5.2 DETAILED REQUIREMENTS
-
- TC-5.2.1 SECURITY POLICY
-
- TC-5.2.1.1 Discretionary Access Control
-
- The discretionary access control requirements apply as stated in the TCSEC
- to every TCB subset whose policy includes discretionary access control of
- its subjects to its objects. Any TCB subset whose policy does not include
- such discretionary access control is exempt from this requirement.
-
- TC-5.2.1.2 Object Reuse
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB.
-
- TC-5.2.1.3 Labels
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- Label Integrity
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- Exportation of Labeled Information
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- Subject Sensitivity Labels
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- Device Labels
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects
- and has attached physical or virtual devices. Any TCB subset whose policy
- does not include such mandatory access control or has no attached physical
- or virtual devices is exempt from this requirement. This requirement can
- be satisifed by the cooperative action of more than one TCB subset.
-
- TC-5.2.1.4 Mandatory Access Control
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- TC-5.2.2 ACCOUNTABILITY
-
- TC-5.2.2.1 Identification and Authentication
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- If the TCB is composed of TCB subsets, one TCB subset may either rely on a
- mechanism in another TCB subset to provide identification and
- authentication services or provide the services directly. Similarly, that
- TCB subset may rely on a mechanism in another more primitive TCB subset to
- ensure that the security level of subjects external to the TCB that may be
- created to act on behalf of the individual user are dominated by the
- clearance and authorization of that user. Each TCB subset may maintain its
- own identification and authentication data or one central repository may
- be maintained. If each TCB subset has its own data, then the information
- for each individual user must be consistent among all subsets.
-
- Trusted Path
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- When TCB subsets are used, the requirement for trusted path at levels B2
- and above remains applicable to the entire TCB. The need for trusted path
- "when positive TCB-to-user connection is required (e.g., login, change
- subject security level)" can require user interaction with virtually any
- TCB subset within the TCB. The implementation of trusted path could be
- localized in a single TCB subset. Alternatively, it could be implemented
- in more than one TCB subset if the separate implementations together
- comply with the system security policy.
-
- TC-5.2.2.2 Audit
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- A TCB subset may maintain its own security audit log, distinct from that
- maintained by more primitive TCB subsets, or it may use an audit interface
- provided by a different TCB subset allowing the audit records it generates
- to be processed by that TCB subset.
-
- If the TCB subset uses different user identifications than a more
- primitive TCB subset, there shall be a means to associate audit records
- generated by different TCB subsets for the same individual with each
- other, either at the time they are generated or later.
-
- Any TCB subset wherein events may occur that require notification of the
- security administrator
-
- shall be able to do the following: (1) detect the occurrence of these
- events, (2) initiate the recording of the audit trail entry, and (3)
- initiate the notification of the security administrator. The ability to
- terminate events (2) and (3) above may be provided either in the TCB
- subset within which they occur, or in the TCB subset(s) where actions that
- lead to the event were initiated.
-
- The monitoring and notification requirements may require cooperation
- between multiple distinct TCB subsets or multiple instantiations of the
- same TCB subset. For example, to detect the accumulation of events for a
- single user it may be necessary to collect events from several subjects in
- distinct processes that are surrogates for the same user. As another
- example, there may be a single TCB subset that collects events from a
- number of other TCB subset instantiations and, based on its analysis of
- them, notifies the security administrator.
-
- TC-5.2.3 ASSURANCE
-
- TC-5.2.3.1 Operational Assurance
-
- System Architecture
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following
-
- additional interpretations.The TCB must provide domains for execution that
- are allocated to and used by TCB subsets according to the subset-domain
- condition for evaluation by parts. A most primitive TCB subset must
- provide domains for execution. A less primitive TCB subset must make use
- of domains provided by a more primitive TCB subset. A less primitive TCB
- subset may provide further execution domains but is not required to do so.
-
- Similarly, the TCB must provide distinct address spaces for untrusted
- processes. A most primitive TCB subset must provide distinct address
- spaces for its subjects. A less primitive TCB subset must make use of the
- distinct address space provided by a more primitive TCB subset. A less
- primitive TCB subset may provide more fine-grained distinct address
- spaces, but is not required to do so.
-
- In general, requirements specifically referring to hardware or firmware
- apply only to TCB subsets that include hardware or firmware. The exception
- is the requirement that the TCB make effective use of available hardware.
- This requirement applies to those TCB subsets that use resources provided
- by more primitive TCB subsets in lieu of hardware. Those TCB subsets are
- required to make effective use of the protection-relevant features
- exported to it by the more primitive TCB subsets (e.g., execution domains,
- support for distinct address spaces) to separate those elements that are
- protection-critical from those that are not.
-
- System Integrity
-
- This requirement applies as stated in the TCSEC to every TCB subset that
- includes hardware or firmware. Any TCB subset that does not include
- hardware or firmware is exempt from this requirement.
-
- Covert Channel Analysis
-
- This requirement applies as stated in the TCSEC to the entire TCB. When
- the TCB is made up entirely of TCB subsets meeting the conditions for
- evaluation by parts, analysis of the individual TCB subsets satisfies this
- requirement. Otherwise, covert channel analysis of the entire TCB must be
- performed (even if the results of covert channel analysis of the
- individual TCB subsets were available).
-
- Trusted Facility Management
-
- This requirement applies as stated in the TCSEC to the entire TCB. Any
- "operator" or "administrator" functions intrinsic to an individual TCB
- subset must be supported by that TCB subset or by a more primitive TCB
- subset.
-
- Trusted Recovery
-
- This requirement applies as stated in the TCSEC to the entire TCB and to
- the individual TCB subsets. The cooperative recovery actions of the TCB
- subsets making up the TCB must provide trusted recovery for the overall
- TCB. Otherwise, trusted recovery evaluation must address the entire TCB
- (even if the individual TCB subsets meet the trusted recovery
- requirements).
-
- TC-5.2.3.2 Life-Cycle Assurance
-
- Security Testing
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset satisfies
- the requirement for the entire TCB. Otherwise, security testing of the
- entire TCB must be performed (even if the results of testing the
- individual TCB subsets were available).
-
- Design Specification and Verification
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following specific additional interpretations. It must be demonstrated
- that the securitypolicy enforced by the composite TCB is represented by
- the collection of policy models for the individual TCB subsets.
-
- The argument that the descriptive top level specification (DTLS) and
- formal top level specification (FTLS) are consistent with the TCB
- interface applies to the entire TCB. There is required an explicit and
- convincing description of how the set of top level specifications (one for
- each TCB subset) describes the TCB interface in terms of exceptions,
- errors, and effects.
-
- Configuration Management
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB, with the following additional interpretation.
-
- Because subsets of the TCB may be developed independently, a single
- configuration management system may not be feasible. However, the
- combination of configuration management systems used to support all the
- TCB subsets must meet all the stated requirements. The information
- describing the interrelations between separate TCB subsets and separate
- security policy models falls into the category of "all documentation and
- code associated with the current version of the TCB" in the TCSEC
- requirements.
-
- Trusted Distribution
-
- This requirement applies as stated in the TCSEC to the entire TCB. It can
- be met by satisfying the requirements for each TCB subset if procedures
- exist for assuring that all TCB subsets upon which a particular TCB subset
- depends (that is, the more primitive TCB subsets) are exactly the same
- version as specified for the TCB subset in question.
-
- TC-5.2.4 DOCUMENTATION
-
- TC-5.2.4.1 DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB. This collection of guides must include descriptions of every TCB
- subset in the TCB and explicit cross-references to other related user's
- guides to other TCB subsets, as required. In addition, interactions
- between mechanisms within different TCB subsets must be clearly described.
-
- TC-5.2.4.2 Trusted Facility Manual
-
- This requirement applies as stated in the TCSEC to the TCB and to every
- TCB subset in the TCB.
-
- This requirement can be met by providing a set of manuals, one for each
- distinct (non-replicated) TCB subset. Each manual shall address the
- functions and privileges to be controlled for the associated TCB subset.
- Additionally, it must clearly show the interfaces to, and the interaction
- with, more primitive TCB subsets. The manual for each TCB subset shall
- identify the functions and privileges of the TCB subsets on which the
- associated TCB subset depends. Also, the TCB subset's manual shall
- identify which, if any, configuration options of the more primitive TCB
- subsets are to be used for the composite TCB to operate securely.
-
- Any pre-defined roles supported (e.g., database administrator) by the TCB
- subset shall be addressed.
-
- The means for correlating multiple audit logs and synonymous user
- identifications from multiple TCB subsets (if such exist) shall also be
- addressed. The trusted facility manual shall describe the composite TCB so
- that the interactions among the TCB subsets can be readily determined.
- Other manuals may be referenced in this determination. The manuals that
- address the distinct modules of the TCB and the generation of the TCB need
- to be integrated with the other trusted facility manuals only to the
- extent that they are affected by the use and operation (versus the
- development) of the composite TCB.
-
- The TCB modules that contain the reference validation mechanism must be
- associated with the TCB subset to which they belong. The procedure for
- generating a new TCB after modifying only one (or several) TCB subsets
- must be described. This may be accommodated by independent regeneration of
- the individual TCB subsets or by regeneration of only the affected TCB
- subsets.
-
- TC-5.2.4.3 Test Documentation
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- TC-5.2.4.4 Design Documentation
-
- This requirement applies as stated in the TCSEC to the composite TCB, with
- the following specific additional interpretations:
-
- Requirements concerning models, FTLS and DTLS, apply to individual TCB
- subsets.
-
- The requirement concerning the description of interfaces between modules
- of the TCB includes the interfaces between TCB subsets.
-
- The documentation of the implementation of a reference validation
- mechanism must include justification for meeting the conditions for
- evaluation by parts.
-
- The A1 requirement to describe clearly non-FTLS internals of the TCB
- applies to TCB subsets.
-
- TC-5.3 SUMMARY OF THE REQUIREMENTS
-
- The requirements interpretations in Section TC-5.2 above can be grouped
- into two categories: those that apply to individual TCB subsets and those
- that apply totally or in part to the overall TCB. For purposes of
- exposition, the former category will be termed "local requirements," that
- is, those for which separate analysis of the individual TCB subsets
- suffices to determine compliance for the composite TCB. The latter are
- termed "global requirements," that is, those which require analysis of the
- entire system and for which separate analysis of the individual TCB
- subsets does not suffice.
-
- TC-5.3.1 LOCAL REQUIREMENTS
-
- Discretionary Access Control;
- Object Reuse;
- Labels (except Subject Sensitivity Labels);
- Mandatory Access Control;
- System Architecture (except domains for
-
- execution and distinct address spaces);
-
- System Integrity;
- Configuration Management;
- Security Features User's Guide;
- Design Documentation
- models,
- DTLSs,
- FTLSs, and
- non-FTLS internals.
-
- TC-5.3.2 GLOBAL REQUIREMENTS
-
- Subject Sensitivity Labels;
-
- Identification and Authentication;
-
- Trusted Path;
-
- Audit;
-
- System Architecture domains for execution, and distinct address spaces;
-
- Covert Channel Analysis;
-
- Trusted Facility Management;
-
- Trusted Recovery (also applies to
-
- individual TCB subsets); Security Testing; Design Specification and
- Verification correspondence between system policy and the set of TCB
- subset models consistency of TCB interface with the
-
- set of TCB subset DTLSs, and consistency ofTCB interface with the set of
- TCB subset FTLSs; Trusted Distribution; Trusted Facility Manual (also
- applies to individual TCB subsets);
-
- Test Documentation; and Design Documentation (except models, DTLSs, FTLSs,
- and non-FTLS internals).
-
- TC-6 DESIGN CHOICE
-
- TC-6.1 OVERVIEW
-
- This section examines the several design choices available for
- constructing systems in parts and the consequences of each when attempting
- to perform an evaluation by parts. The first case described is that of a
- TCB evaluated under the TCSEC without benefit of TCB subset structuring.
- This case is of value for several reasons: it serves as a reference point;
- it can be considered the degenerate case of subsetting; and it is always
- an option to evaluate any TCB, regardless of internal structure, as a
- monolith. The second and third cases are presented in terms of a
-
- configuration of exactly two subsets; the
-
- generalization to more than two TCB subsets is
-
- straightforward. The second case is that of a
-
- subsetted architecture that exactly satisfies the
-
- conditions for evaluation by parts. The third case represents a special
- case of an altered TCB, one which is implemented using trusted subjects.
-
- Note that no evaluation using TCB subsets and evaluation by parts results
- in a TCB subset receiving an evaluation rating. Rather, the entire system,
- with its composite TCB, is evaluated and receives a rating.
-
- However, evaluation by parts is intended to allow the
-
- results of local analysis of individual TCB subsets to be distinguishable
- and separately referencable. For further discussion of this topic, see
- Appendix B, item 10.
-
- TC-6.2 A SINGLE TCB SUBSET
-
- The evaluation of a TCB consisting of a single TCB subset is equivalent to
- a straightforward evaluation against the TCSEC. The conditions for
- evaluation by parts (Section TC-4.3) reduce to requirements found in the
- TCSEC itself.
-
- TC-6.2.1 ANALYSIS OF THE CONDITIONS
-
- TC-6.2.1.1 Condition 1: Candidate TCB Subsets
-
- The TCB (hardware, software, and firmware), as distinguished from the rest
- of the computing system, must be identified. This is a basic requirement
- for TCSEC evaluation. Similarly, the subjects and objects within the
- system must be identified. The requirement that no more than one TCB
- subset mediate access to any particular object is satisfied, because there
- is only one TCB subset.
-
- TC-6.2.1.2 Condition 2: Policy Allocation
-
- The policy P enforced by the TCB (subset) must be identified. The
- demonstration that the TCB (subset) enforces that policy will be a
- description of how the TCB performs access mediation between the system's
- subjects and objects according a system-level description of limitations
- on access (the technical policy P[i] of the definition). The tracing of
- the policy to the system design and behavior is part of the stated TCSEC
- requirements.
-
- TC-6.2.1.3 Condition 3: Trusted Subjects Included
-
- This condition is satisfied in the same manner as it is in evaluations
- under the TCSEC. Specifically, the TCB boundary is shown to be the
- interface that is presented to untrusted subjects.
-
- TC-6.2.1.4 Condition 4: TCB Subset Structure
-
- Satisfaction of this condition (TC-4.3.4) is immediate, because there is
- only one TCB subset.
-
- TC-6.2.1.5 Condition 5: Separate Subset-Domains
-
- Satisfaction of the separate subset-domain condition (TC-4.3.5) is
- identical to the C1 through A1 requirement that "the TCB maintain a domain
- for its own execution that protects it from external interference or
- tampering." [8, p. 13 et al.]
-
- TC-6.2.1.6 Condition 6: Support for RVM Arguments
-
- Satisfaction of this condition (TC-4.3.6) is immediate, inasmuch as there
- are no less primitive TCB subsets that must be demonstrated to satisfy RVM
- requirements.
-
- TC-6.2.2 EVALUATION S CONSEQUENCE
-
- In this case, the evaluation of the (single) TCB subset proceeds exactly
- like an evaluation under the TCSEC. Demonstration that the candidate
- system meets all the global and local requirements (as they apply to the
- target evaluation class) includes the consideration of each requirement as
- it applies system's philosophy of protection, design, documentation, and
- implementation. The system must be shown to exhibit the properties of a
- reference validation mechanism, appropriate to the target class.
-
- TC-6.3 TWO TCB SUBSETS, MEETING THE CONDITIONS
-
- This case is of a TCB that consists of two candidate TCB subsets, A and B,
- where A is the most primitive TCB subset. That is, B uses the abstractions
- provided by A (the objects, in particular) as its resource for the
- construction and exportation of its own abstractions. B also uses the
- abstractions provided by A for its metadata (that is, internal data
- structures) that make it possible for B to instantiate its exported
- abstractions as well as keep records that enable it to correctly enforce
- its stated policy. In terms of the discussion of Section TC-4.3.4, TCB
- subset B directly depends on TCB subset A. It will be assumed that TCB
- subset A enforces mandatory and discretionary policies on its objects and
- that TCB subset B enforces a discretionary policy on the objects it
- exports. Additionally, all trusted subjects of A are contained within A.
- Thus, every subject of A (including all the active entities that make up
- the logic of B) operates at a single sensitivity level. It will further be
- assumed for th is example that the mechanisms for domains and thus for
- subset-domains are independent of the mandatory and discretionary access
- control policy enforcement mechanisms.
-
- TC-6.3.1 ANALYSIS OF THE CONDITIONS
-
- TC-6.3.1.1 Condition 1: Candidate TCB subsets
-
- The TCB (hardware, software, and firmware), as distinguished from the rest
- of the computing system, must be identified. This is a basic requirement
- for TCSEC evaluation. Similarly, the subjects and objects within the
- system must be identified.
-
- In this case, all the hardware, software, and firmware that make up the
- TCB must be identified as being part of either TCB subset A or TCB subset
- B. The subjects and objects mediated by A (call them the "A-subjects" and
- "A-objects" for this discussion) must be identified. Similarly the
- B-subjects and B-objects must also be identified.
-
- The additional requirement in Section TC-4.3.1 that "there may not be any
- objects mediated by more than one TCB subset" means that there can be no
- B-object that is also an A-object.
-
- TC-6.3.1.2 Condition 2: Policy Allocation
-
- The policy P enforced by the whole TCB must be identified. In addition,
- the policy enforced by A (call it the A-policy), stated in terms of the
- A-subjects and the A-objects, must be identified. Similarly, the B-policy,
- stated in terms of the B-subjects and the B-objects, must be identified.
-
- TC-6.3.1.3 Condition 3: Trusted Subjects included
-
- As was stated above, TCB Subset A contains all its own trusted subjects.
- There may be trusted subjects with respect to the policy of A, but all
- such subjects execute in the subset-domain of A.
-
- TC-6.3.1.4 Condition 4: TCB Subset Structure
-
- Because B directly uses the A-objects and its logic is embodied in
- A-subjects, the structure of the TCB subsets is precisely "TCB subset A is
- more primitive than TCB subset B." This is a partial order.
-
- TC-6.3.1.5 Condition 5: Separate Subset-Domains
-
- Satisfaction of the separate subset-domain condition requires that a set
- of domains provided by the system be identified as being the domains
- "occupied" by A and B. The domain, or domains, occupied by A is exactly
- the "domain for its own execution" found in the TCSEC requirements. The
- domain or domains occupied by TCB subset B must not be modifiable by any
- code or other system entity except possibly by TCB subset A.
-
- TC-6.3.1.6 Condition 6: Support for RVM Arguments
-
- Satisfying the condition for RVM arguments requires demonstrating the
- plausibility of being able to establish the three requisite properties of
- an RVM. The first property requires that no B-subject be allowed to access
- B-objects without those accesses being mediated by TCB subset B. The
- tamper resistance property requires that TCB subset A provide a way that
- TCB subset B can be designed and implemented such that A-subjects that are
- not part of B's implementation cannot tamper with B's policy-critical code
- or data. The third RVM property must be satisfied by the individual TCB
- subsets. The degree to which each TCB subset must satisfy this property is
- commensurate with the evaluation class of the TCB.
-
- TC-6.3.2 EVALUATION CONSEQUENCES
-
- In this case, the evaluation of the two TCB subsets requires that each
- meet TCSEC requirements applicable to each TCB subset viewed individually
- and that the two TCB subsets combine in a way to meet all the TCSEC
- requirements stated for the target class.
-
- All local requirements are imposed on the two TCB subsets, A and B,
- individually. If each TCB subset can meet the requirements of the target
- class, viewed as if it were a separate TCB, the only areas where
- additional evaluation or accreditation work might be required are those
- areas where the sum of the analysis of the parts is not necessarily
- complete and convincing. Those areas requiring additional work are exactly
- the set of global requirements described in Section TC-5.3.2.
-
- Demonstrating that the candidate system meets the TCSEC requirements (as
- they apply to the target evaluation class) requires that both A and B be
- evaluated with respect to the local requirements of the target class and
- that the composite TCB be evaluated for global requirements. In this case,
- full testing of TCB subset A against all the requirements (both local and
- global) simplifies the task of demonstrating satisfaction of the global
- requirements, both for B and for the entire TCB.
-
- Suppose, for example, that TCB subset A has been subjected to security
- testing appropriate to the target class and has been shown to be
- adequately resistant to penetration attacks. This means that within the
- confidence level provided by the testing requirement, no A-subject can
- subvert A's enforcement of its policy. In this situation, every active
- entity in B is an A-subject and hence B can neither penetrate A nor be
- induced to do so by any B-subject. Thus, no further testing of A will be
- required to determine whether the entire TCB is resistant to penetration;
- any additional penetration testing can be limited to determining the
- ability of B to withstand assault.
-
- Similarly, if A has been searched for covert channels (as required for its
- target class requirements), then no further search for covert channels
- will be required, either in the analysis of B or in the overall
- consideration of the entire TCB. Note that if B implements a mandatory
- access control policy (e.g., integrity), then it would be necessary to
- perform a covert channel analysis on B, but no further covert channel
- analysis of A would be required.
-
- The ability of users to determine the current sensitivity level of
- B-subjects operating on their behalf will have to be shown by considering
- the TCB subsets A and B together. This requirement is satisfied
- immediately if the argument relies exclusively on A meeting the
- requirement.
-
- TC-6.4 TWO TCB SUBSETS, NOT MEETING THE CONDITIONS
-
- This case also concerns a TCB that consists of two candidate TCB subsets,
- C and D. C is the most primitive TCB subset. That is, D uses the
- abstractions provided by C (the objects, in particular) as its resource
- for the construction and exportation of its own abstractions. D also uses
- the abstractions provided by C for its metadata (that is, internal data
- structures) that make it possible for D to instantiate its exported
- abstractions as well as keep records that enable it to correctly enforce
- its stated policy. In terms of the discussion of Section TC-4.3.4, TCB
- subset D directly depends on TCB subset C. Additionally, D is trusted with
- respect to C. That is, some of the C-subjects which make up TCB subset D
- execute as trusted processes of C. Here also, as in the previous example,
- it is assumed that C implements mandatory and discretionary policies over
- its objects. Further, the intent of D is to implement a discretionary
- policy over the objects it exports. However, because D includes subjects
- which are trusted relative to C's policy demonstration of the full and
- correct enforcement of the mandatory policy requires analysis of both C
- and D and is no longer localized to TCB subset C. It will be assumed that
- the mechanisms for domains and thus for subset-domains are independent of
- the mandatory and discretionary access control policy enforcement
- mechanisms.
-
- This case can be viewed as a special case of a previously evaluated TCB
- which has been altered. However, the alteration takes the form of a less
- primitive subset which is implemented, at least in part, with trusted
- subjects (i.e., some of the C-subjects are trusted subjects which execute
- in the subset-domain of D). Although this case may appear, intuitively, to
- be different from that of arbitrary alteration of a previously evaluated
- TCB, the example demonstrates that such an approach makes it impossible to
- perform an evaluation by parts.
-
- TC-6.4.1 ANALYSIS OF THE CONDITIONS
-
- TC-6.4.1.1 Condition 1: Candidate TCB Subsets
-
- The identification of the TCB (hardware, software, and firmware) as
- distinguished from the rest of the computing system is a basic requirement
- for TCSEC evaluation. Likewise, the subjects and objects within the system
- must be identified.
-
- In this case, all the hardware, software, and firmware that make up the
- TCB must be identified as being part of either TCB subset C or TCB subset
- D. The C-subjects and C-objects mediated by C have to be identified.
- Similarly the D-subjects and D-objects must also be identified.
-
- The additional requirement in Section TC-4.3.1 that "there may not be any
- objects mediated by more than one TCB subset" means there can be no
- D-object that is also a C-object.
-
- TC-6.4.1.2 Condition 2: Policy Allocation
-
- The policy P enforced by the whole TCB must be identified. In addition,
- the individual policy enforced by C (call it the C-policy) must be
- identified in terms of the C-subjects and the C-objects. Similarly, the
- D-policy, stated in terms of theD-subjects and the D-objects, must be
- stated. In this case, the C-policy will include the strict enforcement of
- a mandatory access control policy that allows trusted subjects to execute
- in the subset-domains which compose TCB subset D.
-
- TC-6.4.1.3 Condition 3: Trusted Subjects
-
- Included This condition is not satisfied because D includes at least one
- subject that is trusted with respect to C. Hence a subject that is trusted
- with respect to the policy of C is outside C, and evaluation by parts is
- not an option. If TCB subset C had previously been evaluated, then this is
- an example of an altered TCB, albeit a special case. The change consists
- of the addition of one or more trusted C-subjects in D whose effect on the
- behavior of C cannot be predicted a priori. An assessment of the impact of
- D on the behavior of C cannot be made strictly by an examination of the
- trusted subjects and the definition of C's interface. A global assessment
- of C and D is required.
-
- TC-6.4.1.4 Condition 4: TCB Subset Structure
-
- Because D directly uses the C-objects and its logic is embodied in
- C-subjects, the structure of the TCB subsets is precisely "TCB subset C is
- more primitive than TCB subset D." This is a partial order.
-
- TC-6.4.1.5 Condition 5: Separate Subset-Domains
-
- Satisfying the separate subset-domain condition (TC-4.3.5) requires
- identifying the set of system domains (likely administered by the most
- primitive TCB subset C) as the domains "occupied" by C and D. The domain,
- or domains, occupied by C is exactly the "domain for its own execution"
- found in the TCSEC requirements. The domain or domains occupied by TCB
- subset D must not be modifiable by any code or other system entity except
- possibly by a part of TCB subset C.
-
- TC-6.4.1.6 Condition 6: Support for RVM Arguments
-
- Satisfying the condition for RVM arguments requires demonstrating the
- plausibility of being able to establish the three requisite properties of
- an RVM. The first property requires that no B-subject be allowed to access
- B-objects without those accesses being mediated by TCB subset B. The
- tamper resistance property requires that TCB subset A provide a way that
- TCB subset B can be designed and implemented such that A-subjects that are
- not part of B's implementation cannot tamper with B's policy-critical code
- or data. The third RVM property must be satisfied by the individual TCB
- subsets. The degree to which each TCB subset must satisfy this property is
- commensurate with the evaluation class of the TCB.
-
- TC-6.4.2 EVALUATION CONSEQUENCES
-
- In this example, the conditions for evaluation by parts are not satisfied
- and thus, thef ull potential for savings in evaluation effort cannot, in
- general, be realized. A clear option in such cases is to view the system
- as a monolithic TCB and proceed accordingly. However, because this case
- represents an example of an altered TCB, it admits of a wide spectrum of
- specific sub-cases. Thus, if the analysis of the system proceeds in
- parallel to that required for evaluation by parts it may be possible, in
- special cases, to identify elements of the analysis of the more primitive
- candidate TCB subset which can be successfully argued to be unaffected by
- the alterations. Some evaluation effort, often significant, can be saved,
- but unlike evaluation by parts, how much can only be estimated by
- consideration of the implementation specifics. For example, in this
- specific case, the local analysis of TCB subset C represents a reasonable
- candidate for analysis that need not be redone.
-
- TC-6.5 SUMMARY
-
- The three cases described above illustrate the effects of various TCB
- subsetting situations as they relate to the evaluation requirements. A
- monolithic evaluation proceeds exactly as described in the TCSEC, with
- requirements being applied to the entire TCB. When all the conditions for
- evaluation by parts are satisfied, considerable savings in evaluation
- effort are realized. The evaluation of a new system configuration that
- includes exactly the same TCB subset that was previously evaluated (such
- as the TCB subsets A and B in the Section TC-6.3) is limited to (a) local
- analysis of the individual TCB subsets (by reference to earlier analysis,
- if available) and (b) a simpler global analysis, because each TCB subset
- is an exact analog of a TCB.
-
- When the conditions for evaluation by parts are not satisfied, no general
- statements can be made about the factorability of analysis or the
- reusability of previous analysis. The extent to which previous evaluation
- evidence and results remain valid can be determined only on a case-by-case
- basis.
-
- PART 2 INTERPRETED REQUIREMENTS
-
- IR-1 OVERVIEW AND CONTEXT
-
- Part 2, "INTERPRETED REQUIREMENTS," provides specific interpretations of
- those TCSEC requirements which are deemed to be either DBMS-specific (or,
- more generally, application-specific) or particularly relevant to DBMSs.
- All of the requirements in the TCSEC apply in any case.
-
- For the topics included below, the interpretations provide clarification
- of the TCSEC requirements. As is the case for the TCSEC, the interpreted
- requirements at any class include those specified for that class in
- addition to interpretations for lower classes that have not been
- superseded or altered.
-
- Section IR-2 presents an overall summary of the TCSEC requirements, as
- interpreted in the more detailed sections that follow. Sections IR-3
- through IR-7 address individual requirements interpretations for labels,
- audit, system architecture, design specification and verification, and
- design documentation, respectively. The format is an initial discussion of
- the topic in general, followed by specific requirements and
- interpretations that apply to database management systems. A listing of
- the requirements and interpretations organized by TCSEC class is presented
- in Appendix A.
-
- IR-2 SUMMARY OF THE INTERPRETATIONS
-
- This section provides specific interpretations of those TCSEC requirements
- that are particularly relevant for subsetted architectures and evaluation
- by parts. Its organization is derived from the structure of the TCSEC
- requirements. For each relevant TCSEC requirement there is a discussion of
- how that requirement is interpreted for a DBMS.
-
- IR-2.1 SECURITY POLICY
-
- IR-2.1.1 DISCRETIONARY ACCESS CONTROL
-
- The requirement for discretionary access control is not changed in the
- context of this document and therefore applies as stated in the TCSEC.
-
- IR-2.1.2 OBJECT REUSE
-
- The requirement for object reuse is not changed in the context of this
- document and therefore applies as stated in the TCSEC.
-
- IR-2.1.3 LABELS
-
- The requirement for labels is treated in Section IR-3 of this document.
-
- IR-2.1.4 MANDATORY ACCESS CONTROL
-
- The requirement for mandatory access control is not changed in the context
- of this document and therefore applies as stated in the TCSEC. However,
- there are several subtle ramifications of this requirement of which a
- developer or evaluator should be aware. A brief discussion can be found in
- Appendix B, item 8, "Content-Dependent and Context-Dependent Access
- Control."
-
- IR-2.2 ACCOUNTABILITY
-
- IR-2.2.1 IDENTIFICATION AND AUTHENTICATION
-
- The requirement for identification and authentication is not changed in
- the context of this document and therefore applies as stated in the TCSEC.
-
- IR-2.2.2 AUDIT
-
- The requirement for audit is treated in Section IR-4 of this document.
-
- IR-2.3 ASSURANCE
-
- IR-2.3.1 OPERATIONAL ASSURANCE
-
- IR-2.3.1.1 System Architecture
-
- The requirement for system architecture is treated in Section IR-5 of this
- document.
-
- IR-2.3.1.2 System Integrity
-
- The requirement for system integrity is not changed in the context of this
- document and therefore applies as stated in the TCSEC.
-
- IR-2.3.1.3 Covert Channel Analysis
-
- The requirement for covert channel analysis is not changed in the context
- of this document and therefore applies as stated in the TCSEC.
-
- IR-2.3.1.4 Trusted Facility Management
-
- The requirement for trusted facility management is not changed in the
- context of this document and therefore applies as stated in the TCSEC.
-
- IR-2.3.1.5 Trusted Recovery
-
- The requirement for trusted recovery is not changed in the context of this
- document and therefore applies as stated in the TCSEC.
-
- IR-2.3.2 LIFE CYCLE ASSURANCE
-
- IR-2.3.2.1 Security Testing
-
- The requirement for security testing is not changed in the context of this
- document and therefore applies as stated in the TCSEC. IR-2.3.2.2 Design
- Specification and Verification The requirement for design specification
- and verification is treated in Section IR-6 of this document.
-
- IR-2.3.2.3 Configuration Management
-
- The requirement for configuration management is not changed in the context
- of this document and therefore applies as stated in the TCSEC.
-
- IR-2.3.2.4 Trusted Distribution
-
- The requirement for trusted distribution is not changed in the context of
- this document and therefore applies as stated in the TCSEC.
-
- IR-2.4 DOCUMENTATION
-
- IR-2.4.1 SECURITY FEATURES USER'S GUIDE
-
- The requirement for a security features user's guide is not changed in the
- context of this document and therefore applies as stated in the TCSEC.
-
- IR-2.4.2 TRUSTED FACILITY MANUAL
-
- The requirement for a trusted facility manual is not changed in the
- context of this document and therefore applies as stated in the TCSEC.
-
- IR-2.4.3 TEST DOCUMENTATION
-
- The requirement for test documentation is not changed in the context of
- this document and therefore applies as stated in the TCSEC.
-
- IR-2.4.4 DESIGN DOCUMENTATION
-
- The requirement for design documentation is treated in Section IR-7 of
- this document.
-
- IR-3 LABELS
-
- IR-3.1 GENERAL DISCUSSION
-
- The labels requirements of the TCSEC are entirely applicable to database
- management systems. The basic difference between the TCSEC labeling
- requirements as they apply to operating systems and DBMSs involves which
- storage objects are labeled rather than how the labels are handled. This
- section discusses special considerations in implementing and evaluating
- labeling mechanisms in database management systems. Of particular
- importance is the selection of the storage objects that are to be labeled.
-
- Beginning at the B1 evaluation class, trusted database management systems
- are required to associate labels with all storage objects under their
- control. The granularity of storage objects to be protected shall be
- chosen by the DBMS designer.
-
- Stored view definitions (that is, named query commands) that are visible
- at the TCB boundary must be stored in labeled objects. The TCB must
- mediate access both to the view definition and to the view instantiation
- (that is, the set of labeled objects accessed as the result of executing
- the query command contained in the view definition).
-
- It has been proposed in several designs that views be used as a mechanism
- to implement context- or content-dependent labeling. The intuitive
- attractiveness of this approach is undeniable, but the implementation
- details must be carefully worked out to achieve a sound implementation. A
- brief discussion of this topic can be found in Appendix B, item 8,
- "Content-Dependent and Context-Dependent Access Control." TCB designers
- and evaluators may make distinctions between objects that are explicitly
- labeled or implicitly labeled. Such distinctions are meaningful only
- within the confines of the TCB; all storage objects are explicitly labeled
- from a point of view outside the TCB. For example, consider an object of
- one type (e.g., table or file) within the TCB that "contains" many
- (reference monitor) objects of another type (e.g., tuples and records).
- The file could have an explicit label associated with it, and some of the
- records could have explicit labels associated with them. Those records
- that have no explicit label would be implicitly labeled by the label of
- the file.
-
- For database management systems, the objects that store the base data of
- the database (e.g., files, records, relations, and tuples), as well as
- those objects that store the metadata (e.g., directories, indices,
- schemas, data dictionaries, discretionary authorization tables, recovery
- logs, and transaction logs), must be labeled. Objects that need not be
- labeled include internal resources that are not user visible (e.g.,
- printer daemon scratch files and resource allocation tables). The
- requirement for importing data (labeled and unlabeled) is the same as in
- the TCSEC. For additional information, see Appendix B, item 9, "Bulk
- Loading of a Database."
-
- IR-3.2 SPECIFIC INTERPRETATIONS
-
- CLASS (B1): LABELED SECURITY PROTECTION
-
- There are no interpretations for this class.
-
- CLASS (B2): STRUCTURED PROTECTION
-
- Statement from TCSEC
-
- Sensitivity labels associated with each ADP system resource . . . that is
- directly or indirectly accessible by subjects external to the TCB shall be
- maintained by the TCB.
-
- Interpretation
-
- Internal TCB variables that are not visible to untrusted subjects need not
- be labeled, provided that they are not directly or indirectly accessible
- by subjects external to the TCB. However, it is important to understand
- that such internal variables can function as covert signaling channels
- when untrusted subjects are able to detect changes in these variables by
- observing system behavior.
-
- CLASS (B3): SECURITY DOMAINS
-
- There are no additional requirements.
-
- CLASS (A1): VERIFIED DESIGN
-
- There are no additional requirements.
-
- IR-4 AUDIT
-
- IR-4.1 GENERAL DISCUSSION
-
- The audit requirements of the TCSEC apply to database management systems.
- This section discusses special considerations in designing and evaluating
- audit mechanisms in database management systems. The TCB must be capable
- of maintaining an audit trail of accesses and attempted accesses to the
- objects protected by the mandatory and discretionary security policies.
- Two examples are given to illustrate auditing techniques for discretionary
- access control decisions.
-
- Example 1. Consider a DBMS TCB providing discretionary controls on defined
- views of the database. Because the named object presented at the TCB
- interface is the view definition (not the records instantiated through the
- view), all that needs to be auditable is the use of the view by any
- untrusted subject.
-
- Example 2.Consider a DBMS TCB that enforces discretionary access control
- on individual data records. When a user enters a query, the construction
- of a response may involve a search over many records that are not returned
- to the user because they did not satisfy the query. Records that do
- satisfy the query but to which the user does not have access should be
- auditable. Records that do not satisfy the query need not be auditable.
- That is, in the context of audit, access permission to the user and
- satisfaction of a query are to be kept separate.
-
- There is no need to audit operations that are strictly internal to the
- TCB. Separate security audit logs may be maintained by the operating
- system and the database management system. Likewise, separate
- identifications for the same user may be maintained by the operating
- system and the database management system. The correlation of separate
- audit logs may be done either at the time they are generated or at some
- later time.
-
- The emphasis of the audit criterion is to provide individual
- accountability for actions by users. This goal is not the same as that for
- a backup and recovery log. There is no requirement to integrate the audit
- log with the backup and recovery log, although such an integrated log is
- not prohibited. At the designer's discretion, there may be a selectable
- capability to reduce the number of audit records generated in response to
- queries that involve many access control decisions.
-
- IR-4.2 SPECIFIC INTERPRETATIONS CLASS (C2): CONTROLLED ACCESS
- PROTECTION
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, and inserts), not just the invocation of the database
- management system. The auditing mechanism shall have the capability of
- auditing all mediated accesses which are visible to users. That is, each
- discretionary access control policy decision shall be auditable.
- Individual operations performed by trusted software, if totally
- transparent to the user, need not be auditable. If the total audit
- requirement is met by the use of more than one audit log, a method of
- correlation must be available.
-
- CLASS (B1): LABELED SECURITY PROTECTION
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, and inserts), not just the invocation of the database
- management system. The auditing mechanism shall have the capability of
- auditing all mediated accesses which are visible to the user. That is,
- each discretionary access control policy decision and each mandatory
- access control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be auditable. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- CLASS (B2): STRUCTURED PROTECTION
-
- There is no interpretation for the additional requirements.
-
- CLASS (B3): SECURITY DOMAINS
-
- There is no interpretation for the additional requirements.
-
- CLASS (A1): VERIFIED DESIGN
-
- There are no additional requirements.
-
- IR-5 SYSTEM ARCHITECTURE
-
- IR-5.1GENERAL DISCUSSION
-
- The system architecture requirements of the TCSEC apply to database
- management systems. The interpretations provided are a duplication of the
- general interpreted requirements that apply to an evaluation by parts.
- They are included because DBMS evaluations often involve multiple TCB
- subsets.
-
- IR-5.2 SPECIFIC INTERPRETATIONS
-
- CLASS (C1): DISCRETIONARY SECURITY PROTECTION
-
- Statement from TCSEC
-
- The TCB shall maintain a domain for its own execution that protects it
- from external interference or tampering.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to each TCB subset.
-
- CLASS (C2): CONTROLLED ACCESS PROTECTION
-
- There is no interpretation for the additional requirements.
-
- CLASS (B1): LABELED SECURITY PROTECTION
-
- There is no interpretation for the additional requirements.
-
- CLASS (B2): STRUCTURED PROTECTION
-
- Statement from TCSEC
-
- The user interface to the TCB shall be completely defined and all elements
- of the TCB identified.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as the user interface to the
- whole TCB.
-
- Statement from TCSEC
-
- It shall make effective use of available hardware to separate those
- elements that are protection-critical from those that are not.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, each TCB subset must make use
- of facilities provided to it by more primitive TCB subsets, such as
- support for execution domains and for distinct address spaces, to achieve
- the required separation.
-
- CLASS (B3): SECURITY DOMAINS
-
- There is no interpretation for the additional requirements.
-
- CLASS (A1): VERIFIED DESIGN
-
- There are no additional requirements.
-
- IR-6 DESIGN SPECIFICATION AND VERIFICATION
-
- IR-6.1 GENERAL DISCUSSION
-
- The design specification and verification requirements of the TCSEC, with
- the related documentation requirements, apply to database management
- systems. The interpretations provided include a duplication of general
- interpreted requirements that apply to an evaluation by parts. They are
- included because of the likelihood that a DBMS evaluation will involve
- multiple TCB subsets.
-
- In the database context, the set of candidates for "subject" and "object"
- can be larger than normally encountered in trusted operating systems.
- Where a database system builds on an underlying trusted operating system,
- for example, the set of candidate subjects for the two TCB subsets
- includes both the active entities created by the operating system and
- those active entities created by the trusted portion of the DBMS. The set
- of candidates for objects is large.
-
- Examples are files, segments, buffers, structures, pages, relations,
- tables, tuples, rows, columns, elements, entities, relationships,
- procedures, metadata, system tables, query trees, query plans, locking
- mechanisms, rollback mechanisms, indices, recovery and backupmechanisms,
- precalculated operations (such as joins), view definitions, view
- instantiations, constraints, authorization tables, data dictionary tables,
- and audit logs.
-
- The requirements in the TCSEC for showing how the various representations
- of the system being evaluated fit together can be represented as in Figure
- IR-1. For monolithic TCBs, the policy must be stated; the model must be
- developed, maintained, and shown to be sufficient to enforce the policy;
- and the DTLS (FTLS for A1) must be constructed and shown to correspond
- both to the model and to the TCB implementation. These steps allow a chain
- of reasoning to proceed from the stated policy to the assertion that the
- system in question actually enforces the policy.
-
- In the case of multiple TCB subsets, the intent is the same. Tracing all
- policy requirements to
-
- the actual system implementation must be possible, and vice versa. The
- current dilemma is that the theory and techniques for subdividing a model
- into a set of models (or a top level specification into a set of top level
- specifications) have not yet been established. Likewise neither theory or
- techniques have been established for composing a set of models or top
- level specifications into a unified model or top level specification. The
- absence of rigorous methods does not preclude an evaluation using a
- subsetted TCB.
-
- The process of mapping policy to implementation is possible for each TCB
- subset, using the same techniques required for a monolithic TCB. For
- subsetted TCBs, designers and evaluators must explicitly show how the
- policy, model and specifications for each TCB subset meet the TCSEC
- requirements. In addition, convincing informal arguments must be given to
- show how the collection of TCB subsets enforces the policy of the
- composite TCB.
-
- Because morerigorous composition methods are unavailable, convincing
- informal arguments are appropriate for evaluation of TCBs up to and
- including Class A1.
-
- The TCSEC requirements concerning the mapping from policy to
- implementation for a TCB composed of multiple TCB subsets raise these
- crucial topics:
-
- The allocation of policy to the TCB subsets,
-
- The relation of the models for the TCB subsets to the overall system
- policy, and
-
- The relation of the top level specification for each TCB subset to the
- entire system.
-
- Allocation of policy to the TCB subsets is a precise division of the
- policy for the entire system, as addressed in the policy allocation
- condition of Section TC-4.3.
-
- The second topic, above, requires that the policy for each TCB subset be
- stated. Additionally, it is required that there be an informal convincing
- argument that the collection of models represents the policy enforced by
- the entire system.
-
- The third topic, the way in which the set of top level specifications for
- the individual TCB subsets describes the composite TCB interface with
- respect to exceptions, errors and effects, is treated in a similar
- fashion. The top level specifications for each TCB subset must meet the
- requirement. There is, in addition, a requirement for an informal,
- convincing description of how the set of top level specifications
- describes the TCB interface with respect to exceptions, errors, and
- effects. At the A1 level, there is no requirement for additional formal
- specification or formal proofs beyond the specification and proofs
- specific to the individual TCB subsets.
-
- Rather than formally composing the policies, models, and specifications
- and performing a single monolithic evaluation, a series of separate
- evaluations may be performed (one for each TCB subset). The evaluations
- are then tied together by presentation of sufficient informal arguments
- that the individual policies collectively represent the policy enforced by
- the entire system, that the individual models collectively represent the
- system's policy, that the individual specifications represent the TCB
- interface, and that the source code of each TCB subset is consistent with
- its top level specification.
-
- Note that satisfactory completion of these requirements is logically
- equivalent to demonstrating that a "unified" model for the entire TCB is
- consistent with the policy enforced by the system, that a "unified" top
- level specification corresponds to the model, and that the "unified" top
- level specification(s) corresponds to the source code. These interpreted
- requirements, which do not mandate a "unified" top level specification,
- are technically achievable interpretations of the policy-tracing
- requirements in the case of multiple TCB subsets.
-
- IR-6.2 SPECIFIC INTERPRETATIONS
-
- CLASS (B1): LABELED SECURITY PROTECTION
-
- Statement from TCSEC
-
- An informal or formal model of the security
-
- policy supported by the TCB shall be maintained over the life cycle of the
- ADP system and demonstrated to be consistent with its axioms.
-
- Interpretation
-
- If the TCB is composed of multiple TCB
-
- subsets, this requirement applies to the security policy of each TCB
- subset. An informal argument that the set of policy models represents the
- "security policy supported by the [composite] TCB" must be provided.
-
- CLASS (B2): STRUCTURED PROTECTION
-
- Statement from TCSEC
-
- A formal model of the security policy supported by the TCB shall be
- maintained over the life cycle of the ADP system and demonstrated to be
- consistent with its axioms.
-
- Interpretation
-
- If the TCB is composed of multiple TCB
-
- subsets, this requirement applies to the security policy of each TCB
- subset. An informal argument that the set of policy models represents the
- "security policy supported by the [composite] TCB" must be provided.
-
- Statement from TCSEC
-
- A descriptive top-level specification (DTLS) of the TCB shall be
- maintained that completely and accurately describes the TCB in terms of
- exceptions, error messages, and effects.
-
- Interpretation
-
- If the TCB is composed of multiple TCB
-
- subsets, this requirement applies to the DTLS of each TCB subset. An
- informal argument that the set of DTLSs accurately describes the TCB must
- be provided. If there is a multifaceted policy (e.g., both mandatory
- access control and discretionary access control policies) in a particular
- TCB subset, then all facets must be represented in the DTLS and in the TCB
- subset's model.
-
- Statement from TCSEC
-
- The descriptive top-level specification (DTLS) shall be shown to be an
- accurate description of the TCB interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- CLASS (B3): SECURITY DOMAINS
-
- Statement from TCSEC
-
- A convincing argument shall be given that the DTLS is consistent with the
- model.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to individual TCB subsets. Enforcement of all policies must be shown to
- occur in all situations (e.g., state transitions) required by the formal
- security policy model. In the case of a discretionary access control
- policy, the presence of the access control check at all identified state
- transitions is the total of what is required for demonstrating consistency
- between the DTLS and the model. This may be verified by inspection of the
- DTLS (that is, by visually checking that exception checks required by the
- model are present in the DTLS). For the mandatory access control policy,
- the DTLS must be shown by a convincing argument to be consistent with the
- model.
-
- CLASS (A1): VERIFIED DESIGN
-
- Statement from TCSEC
-
- A formal top-level specification (FTLS) of the TCB shall be maintained
- that accurately describes the TCB in terms of exceptions, error messages,
- and effects.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the FTLS of each TCB subset. An informal argument that the set of FTLSs
- accurately describes the TCB must be provided.
-
- If there is a multifaceted policy (e.g., both mandatory access control and
- discretionary access control policies) in a particular TCB subset, then
- all facets must be represented in the FTLS and in the TCB subset's model.
-
- Statement from TCSEC
-
- The FTLS shall be shown to be an accurate description of the TCB
- interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- Statement from TCSEC
-
- . . . a combination of formal and informal techniques shall be used to
- show that the FTLS is consistent with the model.
-
- Interpretation
-
- If the TCB is composed of multiple TCB
-
- subsets, this requirement applies to individual TCB subsets. Enforcement
- of all policies must be shown to occur in all situations (e.g., state
- transitions) required by the formal security policy model at the required
- occasions. In the case of a discretionary access control policy, the
- presence of the access control check at all identified state transitions
- is the total of what is required for demonstrating consistency between the
- FTLS and the model. This may be verified by inspection of the FTLS (that
- is, by visually checking that exception checks required by the model are
- present in the FTLS). For the mandatory access control policy, the FTLS
- must be shown by a combination of formal and informal techniques to be
- consistent with the model.
-
- IR-7 DESIGN DOCUMENTATION
-
- IR-7.1 GENERAL DISCUSSION
-
- The design documentation requirement of the
-
- TCSEC applies to database management systems.
-
- The interpretations provided are a duplication of the general interpreted
- requirements that apply to an evaluation by parts. They are included
- because DBMS evaluations often involve multiple TCB subsets.
-
- IR-7.2 SPECIFIC INTERPRETATIONS
-
- CLASS (C1): DISCRETIONARY SECURITY PROTECTION
-
- Statement from TCSEC
-
- If the TCB is composed of distinct modules, the interfaces between these
- modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between TCB subsets.
-
- CLASS (C2): CONTROLLED ACCESS PROTECTION
-
- There are no additional requirements.
-
- CLASS (B1): LABELED SECURITY PROTECTIONStatement from TCSEC
-
- The specific TCB protection mechanisms shall be identified and an
- explanation given to show that they satisfy the model.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and shall include the protection mechanisms which support
- the conditions for TCB subset structure and separate subset-domains.
-
- CLASS (B2): STRUCTURED PROTECTION
-
- Statement from TCSEC
-
- The interfaces between the TCB modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between different TCB subsets.
-
- Statement from TCSEC
-
- The descriptive top-level specification (DTLS) shall be shown to be an
- accurate description of the TCB interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB implements the reference monitor
- concept and give an explanation of why it is tamper resistant, cannot be
- bypassed, and is correctly implemented.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to each TCB subset with respect to its specific
- technical policy. In addition, there must be documented an informal
- argument that the cooperative action of the TCB subsets makes the TCB
- itself tamper resistant, non-bypassable, and correct.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB is structured to facilitate
- testing and to enforce least privilege.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement is
- interpreted to apply to individual TCB subsets as well as to the overall
- TCB.
-
- CLASS (B3): SECURITY DOMAINS
-
- Statement from TCSEC
-
- The TCB implementation shall be informally shown to be consistent with the
- DTLS.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to individual TCB subsets.
-
- CLASS (A1): VERIFIED DESIGN
-
- Statement from TCSEC
-
- The TCB implementation shall be informally shown to be consistent with the
- FTLS.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to individual TCB subsets.
-
- SUMMARY OF THE INTERPRETATIONS BY CLASS Appendix A
-
- This section is a presentation of all the interpreted requirements
- organized by TCSEC class. It includes all the requirements which are
- either relevant to subsetted architectures or are DBMS-specific. Any TCSEC
- requirements not explicitly identified herein apply as stated in the
- TCSEC.
-
- CLASS (C1): DISCRETIONARY SECURITY PROTECTION
-
- C1-1 SECURITY POLICY
-
- C1-1.1 DISCRETIONARY ACCESS CONTROL
-
- The discretionary access control requirements apply as stated in the TCSEC
- to every TCB subset whose policy includes discretionary access control of
- its subjects to its objects. Any TCB subset whose policy does not include
- such discretionary access control is exempt from this requirement.
-
- C1-2 ACCOUNTABILITY
-
- C1-2.1 IDENTIFICATION AND AUTHENTICATION
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- If the TCB is composed of TCB subsets, one TCB subset may either rely on a
- mechanism in another TCB subset to provide identification and
- authentication services or provide the services directly. Each TCB subset
- may maintain its own identification and authentication data or one central
- repository may be maintained. If each TCB subset has its own data, then
- the information for each individual user must be consistent among all
- subsets.
-
- C1-3 ASSURANCE
-
- C1-3.1 OPERATIONAL ASSURANCE
-
- C1-3.1.1 SYSTEM ARCHITECTURE
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following additional interpretations.
-
- The TCB must provide domains for execution that are allocated to and used
- by TCB subsets according to the subset-domain condition for evaluation by
- parts. A most primitive TCB subset must provide domains forexecution. A
- less primitive TCB subset must make use of domains provided by a more
- primitive TCB subset. A less primitive TCB subset may provide further
- execution domains but is not required to do so.
-
- Statement from TCSEC
-
- The TCB shall maintain a domain for its own execution that
- protects it from external interference or tampering.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to each TCB subset.
-
- C1-3.1.2 SYSTEM INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset that
- includes hardware or firmware. Any TCB subset that does not include
- hardware or firmware is exempt from this requirement.
-
- C1-3.2 LIFE CYCLE ASSURANCE
-
- C1-3.2.1 SECURITY TESTING
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset satisfies
- the requirement for the entire TCB. Otherwise, security testing of the
- entire TCB must be performed (even if the results of testing the
- individual TCB subsets were available).
-
- C1-4 DOCUMENTATION
-
- C1-4.1 SECURITY FEATURES USER'S GUIDE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB. This collection of guides must include descriptions of every TCB
- subset in the TCB and explicit cross-references to other related user's
- guides to other TCB subsets, as required. In addition, interactions
- between mechanisms within different TCB subsets must be clearly described.
-
- C1-4.2 TRUSTED FACILITY MANUAL
-
- This requirement applies as stated in the TCSEC to the TCB and to every
- TCB subset in the TCB. This requirement can be met by providing a set of
- manuals, one for each distinct (non-replicated) TCB subset. Each manual
- shall address the functions and privileges to be controlled for the
- associated TCB subset. Additionally, it must clearly show the interfaces
- to, and the interaction with, more primitive TCB subsets. The manual for
- each TCB subset shall identify the functions and privileges of the TCB
- subsets on which the associated TCB subset depends. Also, the TCB subset's
- manual shall identify which, if any, configuration options of the more
- primitive TCB subsets are to be used for the composite TCB to operate
- securely.
-
- Any pre-defined roles supported (e.g., database administrator) by the TCB
- subset shall be addressed.
-
- The means for correlating multiple audit logs and synonymous user
- identifications from multiple TCB subsets (if such exist) shall also be
- addressed. The trusted facility manual shall describe the composite TCB so
- that the interactions among the TCB subsets can be readily determined.
- Other manuals may be referenced in this determination. The manuals that
- address the distinct modules of the TCB and the generation of the TCB need
- to be integrated with the other trusted facility manuals only to the
- extent that they are affected by the use and operation (versus the
- development) of the composite TCB.
-
- C1-4.3 TEST DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- C1-4.4 DESIGN DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- Statement from TCSEC
-
- If the TCB is composed of distinct modules, the interfaces between these
- modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between TCB subsets.
-
- CLASS (C2): CONTROLLED ACCESS PROTECTION
-
- C2-1 SECURITY POLICY
-
- C2-1.1 DISCRETIONARY ACCESS CONTROL
-
- The discretionary access control requirements apply as stated in the TCSEC
- to every TCB subset whose policy includes discretionary access control of
- its subjects to its objects. Any TCB subset whose policy does not include
- such discretionary access control is exempt from this requirement.
-
- C2-1.2 OBJECT REUSE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB.
-
- C2-2 ACCOUNTABILITY
-
- C2-2.1 IDENTIFICATION AND AUTHENTICATION
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- If the TCB is composed of TCB subsets, one TCB subset may either rely on a
- mechanism in another TCB subset to provide identification and
- authentication services or provide the services directly. Each TCB subset
- may maintain its own identification and authentication data or one central
- repository may be maintained. If each TCB subset has its own data, then
- the information for each individual user must be consistent among all
- subsets.
-
- C2-2.2 AUDIT
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- A TCB subset may maintain its own security audit log, distinct from that
- maintained by more primitive TCB subsets, or it may use an audit interface
- provided by a different TCB subset allowing the audit records it generates
- to be processed by that TCB subset.
-
- If the TCB subset uses different user identifications than a more
- primitive TCB subset, there shall be a means to associate audit records
- generated by different TCB subsets for the same individual with each
- other, either at the time they are generated or later.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of access to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by users (e.g., updates, retrievals, and
- inserts), not just the invocation of the database management system. The
- auditing mechanism shall have the capability of auditing all mediated
- accesses which are visible to users. That is, each discretionary access
- control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be auditable. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- C2-3 ASSURANCE
-
- C2-3.1 OPERATIONAL ASSURANCE
-
- C2-3.1.1 SYSTEM ARCHITECTURE
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following additional interpretations. The TCB must provide domains for
- execution that are allocated to and used by TCB subsets according to the
- subset-domain condition for evaluation by parts. A most primitive TCB
- subset must provide domains for execution. A less primitive TCB subset
- must make use of domains provided by a more primitive TCB subset. A less
- primitive TCB subset may provide further execution domains but is not
- required to do so.
-
- Statement from TCSEC
-
- The TCB shall maintain a domain for its own execution that protects it
- from external interference or tampering.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to each TCB subset.
-
- C2-3.1.2 SYSTEM INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset that
- includes hardware or firmware. Any TCB subset that does not include
- hardware or firmware is exempt from this requirement.
-
- C2-3.2 LIFE CYCLE ASSURANCE
-
- C2-3.2.1 SECURITY TESTING
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset satisfies
- the requirement for the entire TCB. Otherwise, security testing of the
- entire TCB must be performed (even if the results of testing the
- individual TCB subsets were available).
-
- C2-4 DOCUMENTATION
-
- C2-4.1 SECURITY FEATURES USER'S GUIDE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB. This collection of guides must include descriptions of every TCB
- subset in the TCB and explicit cross-references to other related user's
- guides to other TCB subsets, as required. In addition, interactions
- between mechanisms within different TCB subsets must be clearly described.
-
- C2-4.2 TRUSTED FACILITY MANUAL
-
- This requirement applies as stated in the TCSEC to the TCB and to every
- TCB subset in the TCB. This requirement can be met by providing a set of
- manuals, one for each distinct (non-replicated) TCB subset. Each manual
- shall address the functions and privileges to be controlled for the
- associated TCB subset. Additionally, it must clearly show the interfaces
- to, and the interaction with, more primitive TCB subsets. The manual for
- each TCB subset shall identify the functions and privileges of the TCB
- subsets on which the associated TCB subset depends. Also, the TCB subset's
- manual shall identify which, if any, configuration options of the more
- primitive TCB subsets are to be used for the composite TCB to operate
- securely.
-
- Any pre-defined roles supported (e.g., database administrator) by the TCB
- subset shall be addressed.
-
- The means for correlating multiple audit logs and synonymous user
- identifications from multiple TCB subsets (if such exist) shall also be
- addressed.
-
- The trusted facility manual shall describe the composite TCB so that the
- interactions among the TCB subsets can be readily determined. Other
- manuals may be referenced in this determination. The manuals that address
- the distinct modules of the TCB and the generation of the TCB need to be
- integrated with the other trusted facility manuals only to the extent that
- they are affected by the use and operation (versus the development) of the
- composite TCB.
-
- C2-4.3 TEST DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- C2-4.4 DESIGN DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- Statement from TCSEC
-
- If the TCB is composed of distinct modules, the interface between these
- modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between TCB subsets.
-
- CLASS (B1): LABELED SECURITY PROTECTION SECURITY POLICY
-
- B1-1 SECURITY POLICY
-
- B1-1.1 DISCRETIONARY ACCESS CONTROL
-
- The discretionary access control requirements apply as stated in the TCSEC
- to every TCB subset whose policy includes discretionary access control of
- its subjects to its objects. Any TCB subset whose policy does not include
- such discretionary access control is exempt from this requirement.
-
- B1-1.2 OBJECT REUSE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB.
-
- B1-1.3 LABELS
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B1-1.3.1 LABEL INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B1-1.3.2 EXPORTATION OF LABELED INFORMATION
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B1-1.4 MANDATORY ACCESS CONTROL
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B1-2 ACCOUNTABILITY
-
- B1-2.1 IDENTIFICATION AND AUTHENTICATION
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement. If the TCB is composed of TCB subsets, one TCB subset may
- either rely on a mechanism in another TCB subset to provide identification
- and authentication services or provide the services directly. Similarly,
- that TCB subset may rely on a mechanism in another more primitive TCB
- subset to ensure that the security level of subjects external to the TCB
- that may be created to act on behalf of the individual user are dominated
- by the clearance and authorization of that user. Each TCB subset may
- maintain its own identification and authentication data or one central
- repository may be maintained. If each TCB subset has its own data, then
- the information for each individual user must be consistent among all
- subsets.
-
- B1-2.2 AUDIT
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- A TCB subset may maintain its own security audit log, distinct from that
- maintained by more primitive TCB subsets, or it may use an audit interface
- provided by a different TCB subset allowing the audit records it generates
- to be processed by that TCB subset.
-
- If the TCB subset uses different user identifications than a more
- primitive TCB subset, there shall be a means to associate audit records
- generated by different TCB subsets for the same individual with each
- other, either at the time they are generated or later.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of access to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, and inserts), not just the invocation of the database
- management system. The auditing mechanism shall have the capability of
- auditing all mediated accesses which are visible to users. That is, each
- discretionary access control policy decision shall be auditable.
- Individual operations performed by trusted software, if totally
- transparent to the user, need not be auditable. If the total audit
- requirement is met by the use of more than one audit log, a method of
- correlation must be available.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, and inserts), not just the invocation of the database
- management system. The auditing mechanism shall have the capability of
- auditing all mediated accesses which are visible to the user. That is,
- each discretionary access control policy decision and each mandatory
- access control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be auditable. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- B1-3 ASSURANCE
-
- B1-3.1 OPERATIONAL ASSURANCE
-
- B1-3.1.1 SYSTEM ARCHITECTURE
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following additional interpretations. The TCB must provide domains for
- execution that are allocated to and used by TCB subsets according to the
- subset-domain condition for evaluation by parts. A most primitive TCB
- subset must provide domains for execution. A less primitive TCB subset
- must make use of domains provided by a more primitive TCB subset. A less
- primitive TCB subset may provide further execution domains but is not
- required to do so.
-
- Similarly, the TCB must provide distinct address spaces for untrusted
- processes. A most primitive TCB subset must provide distinct address
- spaces for its subjects. A less primitive TCB subset must make use of the
- distinct address space provided by a more primitive TCB subset. A less
- primitive TCB subset may provide more fine-grained distinct address
- spaces, but is not required to do so.
-
- Statement from TCSEC
-
- The TCB shall maintain a domain for its own execution that protects it
- from external interference or tampering.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to each TCB subset.
-
- B1-3.1.2 SYSTEM INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset that
- includes hardware or firmware. Any TCB subset that does not include
- hardware or firmware is exempt from this requirement.
-
- B1-3.2 LIFE CYCLE ASSURANCE
-
- B1-3.2.1 SECURITY TESTING
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset satisfies
- the requirement for the entire TCB. Otherwise, security testing of the
- entire TCB must be performed (even if the results of testing the
- individual TCB subsets were available).
-
- B1-3.2.2 DESIGN SPECIFICATION AND VERIFICATION
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following specific additional interpretations.
-
- It must be demonstrated that the security policy enforced by the composite
- TCB is represented by the collection of policy models for the individual
- TCB subsets.
-
- Statement from TCSEC
-
- An informal or formal model of the security policy supported by the TCB
- shall be maintained over the life cycle of the ADP system and demonstrated
- to be consistent with its axioms.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the security policy of each TCB subset. An informal argument that the
- set of policy models represents the "security policy supported by the
- [composite] TCB" must be provided.
-
- B1-4 DOCUMENTATION
-
- B1-4.1 SECURITY FEATURES USER'S GUIDE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB. This collection of guides must include descriptions of every TCB
- subset in the TCB and explicit cross-references to other related user's
- guides to other TCB subsets, as required. In addition, interactions
- between mechanisms within different TCB subsets must be clearly described.
-
- B1-4.2 TRUSTED FACILITY MANUAL
-
- This requirement applies as stated in the TCSEC to the TCB and to every
- TCB subset in the TCB. This requirement can be met by providing a set of
- manuals, one for each distinct (non-replicated) TCB subset. Each manual
- shall address the functions and privileges to be controlled for the
- associated TCB subset. Additionally, it must clearly show the interfaces
- to, and the interaction with, more primitive TCB subsets. The manual for
- each TCB subset shall identify the functions and privileges of the TCB
- subsets on which the associated TCB subset depends. Also, the TCB subset's
- manual shall identify which, if any, configuration options of the more
- primitive TCB subsets are to be used for the composite TCB to operate
- securely.
-
- Any pre-defined roles supported (e.g., database administrator) by the TCB
- subset shall be addressed.
-
- The means for correlating multiple audit logs and synonymous user
- identifications from multiple TCB subsets (if such exist) shall also be
- addressed.
-
- The trusted facility manual shall describe the composite TCB so that the
- interactions among the TCB subsets can be readily determined. Other
- manuals may be referenced in this determination. The manuals that address
- the distinct modules of the TCB and the generation of the TCB need to be
- integrated with the other trusted facility manuals only to the extent that
- they are affected by the use and operation (versus the development) of the
- composite TCB.
-
- B1-4.3 TEST DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- B1-4.4 DESIGN DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB, with
- the following specific additional interpretation:
-
- Requirements concerning models and DTLSs apply to individual TCB subsets.
-
- Statement from TCSEC
-
- If the TCB is composed of distinct modules, the interface between these
- modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between TCB subsets.
-
- Statement from TCSEC
-
- The specific TCB protection mechanisms shall be identified and an
- explanation given to show that they satisfy the model.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and shall include the protection mechanisms which support
- the conditions for TCB subset structure and separatesubset-domains.
-
- CLASS (B2): STRUCTURED PROTECTION
-
- B2-1 SECURITY POLICY
-
- B2-1.1 DISCRETIONARY ACCESS CONTROL
-
- The discretionary access control requirements apply as stated in the TCSEC
- to every TCB subset whose policy includes discretionary access control of
- its subjects to its objects. Any TCB subset whose policy does not include
- such discretionary access control is exempt from this requirement.
-
- B2-1.2 OBJECT REUSE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB.
-
- B2-1.3 LABELS
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- Statement from TCSEC
-
- Sensitivity labels associated with each ADP system resource . . . that is
- directly or indirectly accessible by subjects external to the TCB shall be
- maintained by the TCB
-
- Interpretation
-
- Internal TCB variables that are not visible to untrusted subjects need not
- be labeled, provided that they are not directly or indirectly accessible
- by subjects external to the TCB. However, it is important to understand
- that such internal variables can function as covert signaling channels
- when untrusted subjects are able to detect changes in these variables by
- observing system behavior.
-
- B2-1.3.1 LABEL INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B2-1.3.2 EXPORTATION OF LABELED INFORMATION
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B2-1.3.3 SUBJECT SENSITIVITY LABELS
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- B2-1.3.4 DEVICE LABELS
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects
- and has attached physical or virtual devices. Any TCB subset whose policy
- does not include such mandatory access control or has no attached physical
- or virtual devices is exempt from this requirement. This requirement can
- be satisifed by the cooperative action of more than one TCB subset.
-
- B2-1.4 MANDATORY ACCESS CONTROL
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B2-2 ACCOUNTABILITY
-
- B2-2.1 IDENTIFICATION AND AUTHENTICATION
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- If the TCB is composed of TCB subsets, one TCB subset may either rely on a
- mechanism in another TCB subset to provide identification and
- authentication services or provide the services directly. Similarly, that
- TCB subset may rely on a mechanism in another more primitive TCB subset to
- ensure that the security level of subjects external to the TCB that may be
- created to act on behalf of the individual user are dominated by the
- clearance and authorization of that user. Each TCB subset may maintain its
- own identification and authentication data or one central repository may
- be maintained. If each TCB subset has its own data, then the information
- for each individual user must be consistent among all subsets.
-
- B2-2.1.1 TRUSTED PATH
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement. When TCB subsets are used, the requirement for trusted path
- at levels B2 and above remains applicable to the entire TCB. The
- implementation of trusted path could be localized in a single TCB subset.
- Alternatively, it could be implemented in more than one TCB subset if the
- separate implementations together comply with the system security policy.
-
- B2-2.2 AUDIT
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- A TCB subset may maintain its own security audit log, distinct from that
- maintained by more primitive TCB subsets, or it may use an audit interface
- provided by a different TCB subset allowing the audit records it generates
- to be processed by that TCB subset.
-
- If the TCB subset uses different user identifications than a more
- primitive TCB subset, there shall be a means to associate audit records
- generated by different TCB subsets for the same individual with each
- other, either at the time they are generated or later.
-
- Any TCB subset wherein events may occur that require notification of the
- security administrator shall be able to:
-
- (1) detect the occurrence of these events,
-
- (2) initiate the recording of the audit trail entry, and
-
- (3) initiate the notification of the security administrator.
-
- The ability to terminate events (2) and (3) above may be provided either
- in the TCB subset within which they occur, or in the TCB subset(s) where
- actions that lead to the event were initiated.
-
- The monitoring and notification requirements may require cooperation
- between multiple distinct TCB subsets or multiple instantiations of the
- same TCB subset. For example, to detect the accumulation of events for a
- single user it may be necessary to collect events from several subjects in
- distinct processes that are surrogates for the same user. As another
- example, there may be a single TCB subset that collects events from a
- number of other TCB subset instantiations and, based on its analysis of
- them, notifies the security administrator.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, inserts), not just the invocation of the database management
- system. The auditing mechanism shall have the capability of auditing all
- mediated accesses which are visible to the user. That is, each
- discretionary access control policy decision and each mandatory access
- control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be auditable. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, and inserts), not just the invocation of the database
- management system. The auditing mechanism shall have the capability of
- auditing all mediated accesses which are visible to the user. That is,
- each discretionary access control policy decision and each mandatory
- access control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be auditable. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- B2-3 ASSURANCE
-
- B2-3.1 OPERATIONAL ASSURANCE
-
- B2-3.1.1 SYSTEM ARCHITECTURE
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following additional interpretations.
-
- The TCB must provide domains for execution that are allocated to and used
- by TCB subsets according to the subset-domain condition for evaluation by
- parts. A most primitive TCB subset must provide domains for execution. A
- less primitive TCB subset must make use of domains provided by a more
- primitive TCB subset. A less primitive TCB subset may provide further
- execution domains but is not required to do so.
-
- Similarly, the TCB must provide distinct address spaces for untrusted
- processes. A most primitive TCB subset must provide distinct address
- spaces for its subjects. A less primitive TCB subset must make use of the
- distinct address space provided by a more primitive TCB subset. A less
- primitive TCB subset may provide more fine-grained distinct address
- spaces, but is not required to do so.
-
- In general, requirements specifically referring to hardware or firmware
- apply only to TCB subsets that include hardware or firmware. The exception
- is the requirement that the TCB make effective use of available hardware.
- This requirement applies to those TCB subsets that use resources provided
- by more primitive TCB subsets in lieu of hardware. Those TCB subsets are
- required to make effective use of the protection-relevant features
- exported to it by the more primitive TCB subsets (e.g., execution domains,
- support for distinct address spaces) to separate those elements that are
- protection-critical from those that are not.
-
- Statement from TCSEC
-
- The TCB shall maintain a domain for its own execution that protects it
- from external interference or tampering.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to each TCB subset.
-
- Statement from TCSEC
-
- The user interface to the TCB shall be completely defined and all elements
- of the TCB identified.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as the user interface to the
- whole TCB.
-
- Statement from TCSEC
-
- It shall make effective use of available hardware to separate those
- elements that are protection-critical from those that are not.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, each TCB subset must make use
- of facilities provided to it by more primitive TCB subsets, such as
- support for execution domains and for distinct address spaces, to achieve
- the required separation.
-
- B2-3.1.2 SYSTEM INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset that
- includes hardware or firmware. Any TCB subset that does not include
- hardware or firmware is exempt from this requirement.
-
- B2-3.1.3 COVERT CHANNEL ANALYSIS
-
- This requirement applies as stated in the TCSEC to the entire TCB. When
- the TCB is made up entirely of TCB subsets meeting the conditions for
- evaluation by parts, analysis of the individual TCB subsets satisfies this
- requirement. Otherwise, covert channel analysis of the entire TCB must be
- performed (even if the results of covert channel analysis of the
- individual TCB subsets were available).
-
- B2-3.1.4 TRUSTED FACILITY MANAGEMENT
-
- This requirement applies as stated in the TCSEC to the entire TCB. Any
- "operator" or "administrator" functions intrinsic to an individual TCB
- subset must be supported by that TCB subset or by a more primitive TCB
- subset.
-
- B2-3.2 LIFE CYCLE ASSURANCE
-
- B2-3.2.1 SECURITY TESTING
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset satisfies
- the requirement for the entire TCB. Otherwise, security testing of the
- entire TCB must be performed (even if the results of testing the
- individual TCB subsets were available).
-
- B2-3.2.2 DESIGN SPECIFICATION AND VERIFICATION
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following specific additional interpretations.
-
- It must be demonstrated that the security policy enforced by the composite
- TCB is represented by the collection of policy models for the individual
- TCB subsets.
-
- The argument that the descriptive top level specification (DTLS) is
- consistent with the TCB interface applies to the entire TCB. There is
- required an explicit and convincing description of how the set of top
- level specifications (one for each TCB subset) describes the TCB interface
- in terms of exceptions, errors, and effects.
-
- Statement from TCSEC
-
- A formal model of the security policy supported by the TCB shall be
- maintained over the life cycle of the ADP system and demonstrated to be
- consistent with its axioms.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the security policy of each TCB subset. An informal argument that the
- set of policy models represents the "security policy supported by the
- [composite] TCB" must be provided.
-
- Statement from TCSEC
-
- A descriptive top-level specification (DTLS) of the TCB shall be
- maintained that completely and accurately describes the TCB in terms of
- exceptions, error messages, and effects.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the DTLS of each TCB subset. An informal argument that the set of DTLSs
- accurately describes the TCB must be provided.
-
- If there is a multifaceted policy (e.g., both mandatory access control and
- discretionary access control policies) in a particular TCB subset, then
- all facets must be represented in the DTLS and in the TCB subset's model.
-
- Statement from TCSEC
-
- The descriptive top-level specification (DTLS) shall be shown to be an
- accurate description of the TCB interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- B2-3.2.3 Configuration Management
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB, with the following additional interpretation. Because subsets of the
- TCB may be developed independently, a single configuration management
- system may not be feasible. However, the combination of configuration
- management systems used to support all the TCB subsets must meet all the
- stated requirements. The information describing the interrelations between
- separate TCB subsets and separate security policy models falls into the
- category of "all documentation and code associated with the current
- version of the TCB" in the TCSEC requirements.
-
- B2-4 DOCUMENTATION
-
- B2-4.1 SECURITY FEATURES USER'S GUIDE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB. This collection of guides must include descriptions of every TCB
- subset in the TCB and explicit cross-references to other related user's
- guides to other TCB subsets, as required. In addition, interactions
- between mechanisms within different TCB subsets must be clearly described.
-
- B2-4.2 TRUSTED FACILITY MANUAL
-
- This requirement applies as stated in the TCSEC to the TCB and to every
- TCB subset in the TCB. This requirement can be met by providing a set of
- manuals, one for each distinct (non-replicated) TCB subset. Each manual
- shall address the functions and privileges to be controlled for the
- associated TCB subset. Additionally, it must clearly show the interfaces
- to, and the interaction with, more primitive TCB subsets. The manual for
- each TCB subset shall identify the functions and privileges of the TCB
- subsets on which the associated TCB subset depends. Also, the TCB subset's
- manual shall identify which, if any, configuration options of the more
- primitive TCB subsets are to be used for the composite TCB to operate
- securely.
-
- Any pre-defined roles supported (e.g., database administrator) by the TCB
- subset shall be addressed. The means for correlating multiple audit logs
- and synonymous user identifications from multiple TCB subsets (if such
- exist) shall also be addressed.
-
- The trusted facility manual shall describe the composite TCB so that the
- interactions among the TCB subsets can be readily determined. Other
- manuals may be referenced in this determination. The manuals that address
- the distinct modules of the TCB and the generation of the TCB need to be
- integrated with the other trusted facility manuals only to the extent that
- they are affected by the use and operation (versus the development) of the
- composite TCB.
-
- The TCB modules that contain the reference validation mechanism must be
- associated with the TCB subset to which they belong. The procedure for
- generating a new TCB after modifying only one (or several) TCB subsets
- must be described. This may be accommodated by independent regeneration of
- the individual TCB subsets or by regeneration of only the affected TCB
- subsets.
-
- B2-4.3 TEST DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- B2-4.4 DESIGN DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB, with
- the following specific addditional interpretations. Requirements
- concerning models and DTLSs apply to individual TCB subsets. The
- requirement concerning the description of interfaces between modules of
- the TCB includes the interfaces between TCB subsets. The documentation of
- the implementation of a reference validation mechanism must include
- justification for meeting the conditions for evaluation by parts.
-
- Statement from TCSEC
-
- The interfaces between the TCB modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between TCB subsets.
-
- Statement from TCSEC
-
- The specific TCB protection mechanisms shall be identified and an
- explanation given to show that they satisfy the model.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this
- requirement applies to each TCB subset and shall include
- the protection mechanisms which support the conditions for
- TCB subset structure and separate subset-domains.
-
- Statement from TCSEC
-
- The descriptive top-level specification (DTLS) shall be shown to be an
- accurate description of the TCB interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB implements the reference monitor
- concept and give an explanation of why it is tamper resistant, cannot be
- bypassed, and is correctly implemented.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to each TCB subset with respect to its specific
- technical policy. In addition, there must be documented an informal
- argument that the cooperative action of the TCB subsets makes the TCB
- itself tamper resistant, non-bypassable, and correct.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB is structured to facilitate
- testing and to enforce least privilege.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement is
- interpreted to apply to individual TCB subsets as well as to the overall
- TCB.
-
- CLASS (B3): SECURITY DOMAINS
-
- B3-1 SECURITY POLICY
-
- B3-1.1 DISCRETIONARY ACCESS CONTROL
-
- The discretionary access control requirements apply as stated in the TCSEC
- to every TCB subset whose policy includes discretionary access control of
- its subjects to its objects. Any TCB subset whose policy does not include
- such discretionary access control is exempt from this requirement.
-
- B3-1.2 OBJECT REUSE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB.
-
- B3-1.3 LABELS
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- Statement from TCSEC
-
- Sensitivity labels associated with each ADP system resource . . . that is
- directly or indirectly accessible by subjects external to the TCB shall be
- maintained by the TCB
-
- Interpretation
-
- Internal TCB variables that are not visible to untrusted subjects need not
- be labeled, provided that they are not directly or indirectly accessible
- by subjects external to the TCB. However, it is important to understand
- that such internal variables can function as covert signaling channels
- when untrusted subjects are able to detect changes in these variables by
- observing system behavior.
-
- B3-1.3.1 LABEL INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B3-1.3.2 EXPORTATION OF LABELED INFORMATION
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B3-1.3.3 SUBJECT SENSITIVITY LABELS
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- B3-1.3.4 DEVICE LABELS
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects
- and has attached physical or virtual devices. Any TCB subset whose policy
- does not include such mandatory access control or has no attached physical
- or virtual devices is exempt from this requirement. This requirement can
- be satisifed by the cooperative action of more than one TCB subset.
-
- B3-1.4 MANDATORY ACCESS CONTROL
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- B3-2 ACCOUNTABILITY
-
- B3-2.1 IDENTIFICATION AND AUTHENTICATION
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- If the TCB is composed of TCB subsets, one TCB subset may either rely on a
- mechanism in another TCB subset to provide identification and
- authentication services or provide the services directly. Similarly, that
- TCB subset may rely on a mechanism in another more primitive TCB subset to
- ensure that the security level of subjects external to the TCB that may be
- created to act on behalf of the individual user are dominated by the
- clearance and authorization of that user. Each TCB subset may maintain its
- own identification and authentication data or one central repository may
- be maintained. If each TCB subset has its own data, then the information
- for each individual user must be consistent among all subsets.
-
- B3-2.1.1 TRUSTED PATH
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- When TCB subsets are used, the requirement for trusted path at levels B2
- and above remains applicable to the entire TCB. The need for trusted path
- "when positive TCB-to-user connection is required (e.g., login, change
- subject security level)" can require user interaction with virtually any
- TCB subset within the TCB. The implementation of trusted path could be
- localized in a single TCB subset. Alternatively, it could be implemented
- in more than one TCB subset if the separate implementations together
- comply with the system security policy.
-
- B3-2.2 AUDIT
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement. A TCB subset may maintain its own security audit log,
- distinct from that maintained by more primitive TCB subsets, or it may use
- an audit interface provided by a different TCB subset allowing the audit
- records it generates to be processed by that TCB subset. If the TCB subset
- uses different user identifications than a more primitive TCB subset,
- there shall be a means to associate audit records generated by different
- TCB subsets for the same individual with each other, either at the time
- they are generated or at some later time.
-
- Any TCB subset wherein events may occur that require notification of the
- security administrator shall be able to: (1) detect the occurrence of
- these events, (2) initiate the recording of the audit trail entry, and (3)
- initiate the notification of the security administrator The ability to
- terminate events (2) and (3) above may be provided either in the TCB
- subset within which they occur, or in the TCB subset(s) where actions that
- lead to the event were initiated. The monitoring and notification
- requirements may require cooperation between multiple distinct TCB subsets
- or multiple instantiations of the same TCB subset. For example, to detect
- the accumulation of events for a single user it may be necessary to
- collect events from several subjects in distinct processes that are
- surrogates for the same user. As another example, there may be a single
- TCB subset that collects events from a number of other TCB subset
- instantiations and, based on its analysis of them, notifies the security
- administrator.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, inserts), not just the invocation of the database management
- system. The auditing mechanism shall have the capability of auditing all
- mediated accesses which are visible to the user. That is, each
- discretionary access control policy decision and each mandatory access
- control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be audited. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, and inserts), not just the invocation of the database
- management system. The auditing mechanism shall have the capability of
- auditing all mediated accesses which are visible to the user. That is,
- each discretionary access control policy decision and each mandatory
- access control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be auditable. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- B3-3 ASSURANCE
-
- B3-3.1 OPERATIONAL ASSURANCE 1
-
- B3-3.1.1 System Architecture
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following additional interpretations. The TCB must provide domains for
- execution that are allocated to and used by TCB subsets according to the
- subset-domain condition for evaluation by parts. A most primitive TCB
- subset must provide domains for execution. A less primitive TCB subset
- must make use of domains provided by a more primitive TCB subset. A less
- primitive TCB subset may provide further execution domains but is not
- required to do so.
-
- Similarly, the TCB must provide distinct address spaces for untrusted
- processes. A most primitive TCB subset must provide distinct address
- spaces for its subjects. A less primitive TCB subset must make use of the
- distinct address space provided by a more primitive TCB subset. A less
- primitive TCB subset may provide more fine-grained distinct address
- spaces, but is not required to do so.
-
- In general, requirements specifically referring to hardware or firmware
- apply only to TCB subsets that include hardware or firmware. However, the
- requirement that the TCB make effective use of hardware requires that a
- less primitive TCB subset make effective use of the protection-relevant
- features exported to it by the more primitive TCB subsets (e.g., execution
- domains, support for distinct address spaces) to separate those elements
- that are protection-critical from those that are not.
-
- Statement from TCSEC
-
- The TCB shall maintain a domain for its own execution that protects it
- from external interference or tampering.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to each TCB subset.
-
- Statement from TCSEC
-
- The user interface to the TCB shall be completely defined and all elements
- of the TCB identified.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as the user interface to the
- whole TCB.
-
- Statement from TCSEC
-
- It shall make effective use of available hardware to separate those
- elements that are protection-critical from those that are not.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, each TCB subset must make use
- of facilities provided to it by more primitive TCB subsets, such as
- support for execution domains and for distinct address spaces, to achieve
- the required separation.
-
- B3-3.1.2 SYSTEM INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset that
- includes hardware or firmware. Any TCB subset that does not include
- hardware or firmware is exempt from this requirement.
-
- B3-3.1.3 COVERT CHANNEL ANALYSIS
-
- This requirement applies as stated in the TCSEC to the entire TCB. When
- the TCB is made up entirely of TCB subsets meeting the conditions for
- evaluation by parts, analysis of the individual TCB subsets satisfies this
- requirement. Otherwise, covert channel analysis of the entire TCB must be
- performed (even if the results of covert channel analysis of the
- individual TCB subsets were available).
-
- B3-3.1.4 TRUSTED FACILITY MANAGEMENT
-
- This requirement applies as stated in the TCSEC to the entire TCB. Any
- "operator" or "administrator" functions intrinsic to an individual TCB
- subset must be supported by that TCB subset or by a more primitive TCB
- subset.
-
- B3-3.1.5 TRUSTED RECOVERY
-
- This requirement applies as stated in the TCSEC to the entire TCB and to
- the individual TCB subsets. The cooperative recovery actions of the TCB
- subsets making up the TCB must provide trusted recovery for the overall
- TCB. Otherwise, trusted recovery evaluation must address the entire TCB
- (even if the individual TCB subsets meet the trusted recovery
- requirements).
-
- B3-3.2 LIFE CYCLE ASSURANCE
-
- B3-3.2.1 SECURITY TESTING
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset satisfies
- the requirement for the entire TCB.
-
- Otherwise, security testing of the entire TCB must be performed (even if
- the results of testing the individual TCB subsets were available).
-
- B3-3.2.2 DESIGN SPECIFICATION AND VERIFICATION
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following specific additional interpretations.
-
- It must be demonstrated that the security policy enforced by the composite
- TCB is represented by the collection of policy models for the individual
- TCB subsets.
-
- The argument that the descriptive top level specification (DTLS) is
- consistent with the TCB interface applies to the entire TCB. There is
- required an explicit and convincing description of how the set of top
- level specifications (one for each TCB subset) describes the TCB interface
- in terms of exceptions, errors, and effects.
-
- Statement from TCSEC
-
- A formal model of the security policy supported by the TCB shall be
- maintained over the life cycle of the ADP system and demonstrated to be
- consistent with its axioms.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the security policy of each TCB subset. An informal argument that the
- set of policy models represents the "security policy supported by the
- [composite] TCB" must be provided.
-
- Statement from TCSEC
-
- A descriptive top-level specification (DTLS) of the TCB shall be
- maintained that completely and accurately describes the TCB in terms of
- exceptions, error messages, and effects.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the DTLS of each TCB subset. An informal argument that the set of DTLSs
- accurately describes the TCB must be provided.
-
- If there is a multifaceted policy (e.g., both mandatory access control and
- discretionary access control policies) in a particular TCB subset, then
- all facets must be represented in the DTLS and in the TCB subset's model.
-
- Statement from TCSEC
-
- The descriptive top-level specification (DTLS) shall be shown to be an
- accurate description of the TCB interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- Statement from TCSEC
-
- A convincing argument shall be given that the DTLS is consistent with the
- model.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to individual TCB subsets. Enforcement of all policies must be shown to
- occur in all situations (e.g., state transitions) required by the formal
- security policy model. In the case of a discretionary access control
- policy, the presence of the access control check at all identified state
- transitions is the total of what is required for demonstrating consistency
- between the DTLS and the model. This may be verified by inspection of the
- DTLS (that is, by visually checking that exception checks required by the
- model are present in the DTLS). For the mandatory access control policy,
- the DTLS must be shown by a convincing argument to be consistent with the
- model.
-
- B3-3.2.3 CONFIGURATION MANAGEMENT
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB, with the following additional interpretation.
-
- Because subsets of the TCB may be developed independently, a single
- configuration management system may not be feasible. However, the
- combination of configuration management systems used to support all the
- TCB subsets must meet all the stated requirements. The information
- describing the interrelations between separate TCB subsets and separate
- security policy models falls into the category of "all documentation and
- code associated with the current version of the TCB" in the TCSEC
- requirements.
-
- B3-4 DOCUMENTATION
-
- B3-4.1 SECURITY FEATURES USER'S GUIDE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB. This collection of guides must include descriptions of every TCB
- subset in the TCB and explicit cross-references to other related user's
- guides to other TCB subsets, as required. In addition, interactions
- between mechanisms within different TCB subsets must be clearly described.
-
- B3-4.2 TRUSTED FACILITY MANUAL
-
- This requirement applies as stated in the TCSEC to the TCB and to every
- TCB subset in the TCB. This requirement can be met by providing a set of
- manuals, one for each distinct (non-replicated) TCB subset. Each manual
- shall address the functions and privileges to be controlled for the
- associated TCB subset. Additionally, it must clearly show the interfaces
- to, and the interaction with, more primitive TCB subsets. The manual for
- each TCB subset shall identify the functions and privileges of the TCB
- subsets on which the associated TCB subset depends. Also, the TCB subset's
- manual shall identify which, if any, configuration options of the more
- primitive TCB subsets are to be used for the composite TCB to operate
- securely.
-
- Any pre-defined roles supported (e.g., database administrator) by the TCB
- subset shall be addressed.
-
- The means for correlating multiple audit logs and synonymous user
- identifications from multiple TCB subsets (if such exist) shall also be
- addressed.
-
- The trusted facility manual shall describe the composite TCB so that the
- interactions among the TCB subsets can be readily determined. Other
- manuals may be referenced in this determination. The manuals that address
- the distinct modules of the TCB and the generation of the TCB need to be
- integrated with the other trusted facility manuals only to the extent that
- they are affected by the use and operation (versus the development) of the
- composite TCB.
-
- The TCB modules that contain the reference validation mechanism must be
- associated with the TCB subset to which they belong. The procedure for
- generating a new TCB after modifying only one (or several) TCB subsets
- must be described. This may be accommodated by independent regeneration of
- the individual TCB subsets or by regeneration of only the affected TCB
- subsets.
-
- B3-4.3 TEST DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- B3-4.4 DESIGN DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB, with
- the following addtional specific interpretations Requirements concerning
- models and DTLSs apply to individual TCB subsets. The requirement
- concerning the description of interfaces between modules of the TCB
- includes the interfaces between TCB subsets. The documentation of the
- implementation of a reference validation mechanism must include
- justification for meeting the conditions for evaluation by parts.
-
- Statement from TCSEC
-
- The interfaces between the TCB modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between TCB subsets.
-
- Statement from TCSEC
-
- The specific TCB protection mechanisms shall be identified and an
- explanation given to show that they satisfy the model.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and shall include the protection mechanisms which support
- the conditions for TCB subset structure and separate subset-domains.
-
- Statement from TCSEC
-
- The descriptive top-level specification (DTLS) shall be shown to be an
- accurate description of the TCB interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB implements the reference monitor
- concept and give an explanation of why it is tamper resistant, cannot be
- bypassed, and is correctly implemented.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this
- requirement is interpreted to apply to each TCB subset with
- respect to its specific technical policy. In addition,
- there must be documented an informal argument that the
- cooperative action of the TCB subsets makes the TCB itself
- tamper resistant, non-bypassable, and correct.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB is structured to facilitate
- testing and to enforce least privilege.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement is
- interpreted to apply to individual TCB subsets as well as to the overall
- TCB.
-
- Statement from TCSEC
-
- The TCB implementation shall be informally shown to be consistent with the
- DTLS.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to individual TCB subsets.
-
- CLASS (A1): VERIFIED DESIGN
-
- A1-1 SECURITY POLICY
-
- A1-1.1 DISCRETIONARY ACCESS CONTROL
-
- The discretionary access control requirements apply as stated in the TCSEC
- to every TCB subset whose policy includes discretionary access control of
- its subjects to its objects. Any TCB subset whose policy does not include
- such discretionary access control is exempt from this requirement.
-
- A1-1.2 OBJECT REUSE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB.
-
- A1-1.3 LABELS
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- Statement from TCSEC
-
- Sensitivity labels associated with each ADP system resource . . . that is
- directly or indirectly accessible by subjects external to the TCB shall be
- maintained by the TCB
-
- Interpretation
-
- Internal TCB variables that are not visible to untrusted subjects need not
- be labeled, provided that they are not directly or indirectly accessible
- by subjects external to the TCB. However, it is important to understand
- that such internal variables can function as covert signaling channels
- when untrusted subjects are able to detect changes in these variables by
- observing system behavior.
-
- A1-1.3.1 LABEL INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- A1-1.3.2 EXPORTATION OF LABELED INFORMATION
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- A1-1.3.3 SUBJECT SENSITIVITY LABELS
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- A1-1.3.4 DEVICE LABELS
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects
- and has attached physical or virtual devices. Any TCB subset whose policy
- does not include such mandatory access control or has no attached physical
- or virtual devices is exempt from this requirement. This requirement can
- be satisifed by the cooperative action of more than one TCB subset.
-
- A1-1.4 MANDATORY ACCESS CONTROL
-
- This requirement applies as stated in the TCSEC to every TCB subset whose
- policy includes mandatory access control of its subjects to its objects.
- Any TCB subset whose policy does not include such mandatory access control
- is exempt from this requirement.
-
- A1-2 ACCOUNTABILITY
-
- A1-2.1 IDENTIFICATION AND AUTHENTICATION
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- If the TCB is composed of TCB subsets, one TCB subset may either rely on a
- mechanism in another TCB subset to provide identification and
- authentication services or provide the services directly. Similarly, that
- TCB subset may rely on a mechanism in another more primitive TCB subset to
- ensure that the security level of subjects external to the TCB that may be
- created to act on behalf of the individual user are dominated by the
- clearance and authorization of that user. Each TCB subset may maintain its
- own identification and authentication data or one central repository may
- be maintained. If each TCB subset has its own data, then the information
- for each individual user must be consistent among all subsets.
-
- A1-2.1.1 TRUSTED PATH
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement.
-
- When TCB subsets are used, the requirement for trusted path at levels B2
- and above remains applicable to the entire TCB. The need for trusted path
- "when positive TCB-to-user connection is required (e.g., login, change
- subject security level)" can require user interaction with virtually any
- TCB subset within the TCB. The implementation of trusted path could be
- localized in a single TCB subset. Alternatively, it could be implemented
- in more than one TCB subset if the separate implementations together
- comply with the system security policy.
-
- A1-2.2 AUDIT
-
- This requirement applies as stated in the TCSEC to the entire TCB. The
- cooperative action of the TCB subsets making up the TCB must satisfy the
- requirement. A TCB subset may maintain its own security audit log,
- distinct from that maintained by more primitive TCB subsets, or it may use
- an audit interface provided by a different TCB subset allowing the audit
- records it generates to be processed by that TCB subset.
-
- If the TCB subset uses different user identifications than a more
- primitive TCB subset, there shall be a means to associate audit records
- generated by different TCB subsets for the same individual with each
- other, either at the time they are generated or at some later time.
-
- Any TCB subset wherein events may occur that require notification of the
- security administrator shall be able to: (1) detect the occurrence of
- these events, (2) initiate the recording of the audit trail entry, and (3)
- initiate the notification of the security administrator. The ability to
- terminate events (2) and (3) above may be provided either in the TCB
- subset within which they occur, or in the TCB subset(s) where actions that
- lead to the event were initiated.
-
- The monitoring and notification requirements may require cooperation
- between multiple distinct TCB subsets or multiple instantiations of the
- same TCB subset. For example, to detect the accumulation of events for a
- single user it may be necessary to collect events from several subjects in
- distinct processes that are surrogates for the same user. As another
- example, there may be a single TCB subset that collects events from a
- number of other TCB subset instantiations and, based on its analysis of
- them, notifies the security administrator.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, inserts), not just the invocation of the database management
- system. The auditing mechanism shall have the capability of auditing all
- mediated accesses which are visible to the user. That is, each
- discretionary access control policy decision and each mandatory access
- control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be audited. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- Statement from TCSEC
-
- The TCB shall be able to create, maintain, and protect from modification .
- . . an audit trail of accesses to the objects it protects.
-
- Interpretation
-
- Auditable events, in the case of a database management system, are the
- individual operations initiated by untrusted users (e.g., updates,
- retrievals, and inserts), not just the invocation of the database
- management system. The auditing mechanism shall have the capability of
- auditing all mediated accesses which are visible to the user. That is,
- each discretionary access control policy decision and each mandatory
- access control policy decision shall be auditable. Individual operations
- performed by trusted software, if totally transparent to the user, need
- not be auditable. If the total audit requirement is met by the use of more
- than one audit log, a method of correlation must be available.
-
- A1-3 ASSURANCE
-
- A1-3.1 OPERATIONAL ASSURANCE
-
- A1-3.1.1 SYSTEM ARCHITECTURE
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following additional interpretations.The TCB must provide domains for
- execution that are allocated to and used by TCB subsets according to the
- subset-domain condition for evaluation by parts. A most primitive TCB
- subset must provide domains for execution. A less primitive TCB subset
- must make use of domains provided by a more primitive TCB subset. A less
- primitive TCB subset may provide further execution domains but is not
- required to do so.
-
- Similarly, the TCB must provide distinct address spaces for untrusted
- processes. A most primitive TCB subset must provide distinct address
- spaces for its subjects. A less primitive TCB subset must make use of the
- distinct address space provided by a more primitive TCB subset. A less
- primitive TCB subset may provide more fine-grained distinct address
- spaces, but is not required to do so. In general, requirements
- specifically referring to hardware or firmware apply only to TCB subsets
- that include hardware or firmware. However, the requirement that the TCB
- make effective use of hardware requires that a less primitive TCB subset
- make effective use of the protection-relevant features exported to it by
- the more primitive TCB subsets (e.g., execution domains, support for
- distinct address spaces) to separate those elements that are
- protection-critical from those that are not.
-
- Statement from TCSEC
-
- The TCB shall maintain a domain for its own execution that protects it
- from external interference or tampering.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to each TCB subset.
-
- Statement from TCSEC
-
- The user interface to the TCB shall be completely defined and all elements
- of the TCB identified.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as the user interface to the
- whole TCB.
-
- Statement from TCSEC
-
- It shall make effective use of available hardware to separate those
- elements that are protection-critical from those that are not.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, each TCB subset must make use
- of facilities provided to it by more primitive TCB subsets, such as
- support for execution domains and for distinct address spaces, to achieve
- the required separation.
-
- A1-3.1.2 SYSTEM INTEGRITY
-
- This requirement applies as stated in the TCSEC to every TCB subset that
- includes hardware or firmware. Any TCB subset that does not include
- hardware or firmware is exempt from this requirement.
-
- A1-3.1.3 COVERT CHANNEL ANALYSIS
-
- This requirement applies as stated in the TCSEC to the entire TCB. When
- the TCB is made up entirely of TCB subsets meeting the conditions for
- evaluation by parts, analysis of the individual TCB subsets satisfies this
- requirement. Otherwise, covert channel analysis of the entire TCB must be
- performed (even if the results of covert channel analysis of the
- individual TCB subsets were available).
-
- A1-3.1.4 TRUSTED FACILITY MANAGEMENT
-
- This requirement applies as stated in the TCSEC to the entire TCB. Any
- "operator" or "administrator" functions intrinsic to an individual TCB
- subset must be supported by that TCB subset or by a more primitive TCB
- subset.
-
- A1-3.1.5 TRUSTED RECOVERY
-
- This requirement applies as stated in the TCSEC to the entire TCB and to
- the individual TCB subsets. The cooperative recovery actions of the TCB
- subsets making up the TCB must provide trusted recovery for the overall
- TCB. Otherwise, trusted recovery evaluation must address the entire TCB
- (even if the individual TCB subsets meet the trusted recovery
- requirements).
-
- A1-3.2 LIFE CYCLE ASSURANCE
-
- A1-3.2.1 SECURITY TESTING
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset satisfies
- the requirement for the entire TCB.
-
- Otherwise, security testing of the entire TCB must be performed (even if
- the results of testing the individual TCB subsets were available).
-
- A1-3.2.2 DESIGN SPECIFICATION AND VERIFICATION
-
- This requirement applies as stated in the TCSEC to every TCB subset, with
- the following specific additional interpretations.
-
- It must be demonstrated that the security policy enforced by the composite
- TCB is represented by the collection of policy models for the individual
- TCB subsets.
-
- The argument that the descriptive top level specification (DTLS) and
- formal top level specification (FTLS) are consistent with the TCB
- interface applies to the entire TCB. There is required an explicit and
- convincing description of how the set of top level specifications (one for
- each TCB subset) describes the TCB interface in terms of exceptions,
- errors, and effects.
-
- Statement from TCSEC
-
- A formal model of the security policy supported by the TCB shall be
- maintained over the life cycle of the ADP system and demonstrated to be
- consistent with its axioms.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the security policy of each TCB subset. An informal argument that the
- set of policy models represents the "security policy supported by the
- [composite] TCB" must be provided.
-
- Statement from TCSEC
-
- A descriptive top-level specification (DTLS) of the TCB shall be
- maintained that completely and accurately describes the TCB in terms of
- exceptions, error messages, and effects.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the DTLS of each TCB subset. An informal argument that the set of DTLSs
- accurately describes the TCB must be provided.
-
- If there is a multifaceted policy (e.g., both mandatory access control and
- discretionary access control policies) in a particular TCB subset, then
- all facets must be represented in the DTLS and in the TCB subset's model.
-
- Statement from TCSEC
-
- A formal top-level specification (FTLS) of the TCB shall be maintained
- that accurately describes the TCB in terms of exceptions, error messages,
- and effects.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to the FTLS of each TCB subset. An informal argument that the set of FTLSs
- accurately describes the TCB must be provided.
-
- If there is a multifaceted policy (e.g., both mandatory access control and
- discretionary access control policies) in a particular TCB subset, then
- all facets must be represented in the FTLS and in the TCB subset's model.
-
- Statement from TCSEC
-
- The FTLS shall be shown to be an accurate description of the TCB
- interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- Statement from TCSEC
-
- A convincing argument shall be given that the DTLS is consistent with the
- model.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to individual TCB subsets. Enforcement of all policies must be shown to
- occur in all situations (e.g., state transitions) required by the formal
- security policy model. In the case of a discretionary access control
- policy, the presence of the access control check at all identified state
- transitions is the total of what is required for demonstrating consistency
- between the DTLS and the model. This may be verified by inspection of the
- DTLS (that is, by visually checking that exception checks required by the
- model are present in the DTLS). For the mandatory access control policy,
- the DTLS must be shown by a convincing argument to be consistent with the
- model.
-
- Statement from TCSEC
-
- . . . a combination of formal and informal techniques shall be used to
- show that the FTLS is consistent with the model.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement applies
- to individual TCB subsets. Enforcement of all policies must be shown to
- occur in all situations (e.g., state transitions) required by the formal
- security policy model at the required occasions. In the case of a
- discretionary access control policy, the presence of the access control
- check at all identified state transitions is the total of what is required
- for demonstrating consistency between the FTLS and the model. This may be
- verified by inspection of the FTLS (that is, by visually checking that
- exception checks required by the model are present in the FTLS). For the
- mandatory access control policy, the FTLS must be shown by a combination
- of formal and informal techniques to be consistent with the model.
-
- A1-3.2.3 CONFIGURATION MANAGEMENT
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB, with the following additional interpretation.
-
- Because subsets of the TCB may be developed independently, a single
- configuration management system may not be feasible. However, the
- combination of configuration management systems used to support all the
- TCB subsets must meet all the stated requirements. The information
- describing the interrelations between separate TCB subsets and separate
- security policy models falls into the category of "all documentation and
- code associated with the current version of the TCB" in the TCSEC
- requirements.
-
- A1-3.2.4 TRUSTED DISTRIBUTION
-
- This requirement applies as stated in the TCSEC to the entire TCB. It can
- be met by satisfying the requirements for each TCB subset if procedures
- exist for assuring that all TCB subsets upon which a particular TCB subset
- depends (that is, the more primitive TCB subsets) are exactly the same
- version as specified for the TCB subset in question.
-
- A1-4 DOCUMENTATION
-
- A1-4.1 SECURITY FEATURES USER'S GUIDE
-
- This requirement applies as stated in the TCSEC to every TCB subset in the
- TCB. This collection of guides must include descriptions of every TCB
- subset in the TCB and explicit cross-references to other related user's
- guides to other TCB subsets, as required. In addition, interactions
- between mechanisms within different TCB subsets must be clearly described.
-
- A1-4.2 TRUSTED FACILITY MANUAL
-
- This requirement applies as stated in the TCSEC to the TCB and to every
- TCB subset in the TCB. This requirement can be met by providing a set of
- manuals, one for each distinct (non-replicated) TCB subset. Each manual
- shall address the functions and privileges to be controlled for the
- associated TCB subset. Additionally, it must clearly show the interfaces
- to, and the interaction with, more primitive TCB subsets. The manual for
- each TCB subset shall identify the functions and privileges of the TCB
- subsets on which the associated TCB subset depends. Also, the TCB subset's
- manual shall identify which, if any, configuration options of the more
- primitive TCB subsets are to be used for the composite TCB to operate
- securely.
-
- Any pre-defined roles supported (e.g., database administrator) by the TCB
- subset shall be addressed. The means for correlating multiple audit logs
- and synonymous user identifications from multiple TCB subsets (if such
- exist) shall also be addressed.
-
- The trusted facility manual shall describe the composite TCB so that the
- interactions among the TCB subsets can be readily determined. Other
- manuals may be referenced in this determination. The manuals that address
- the distinct modules of the TCB and the generation of the TCB need to be
- integrated with the other trusted facility manuals only to the extent that
- they are affected by the use and operation (versus the development) of the
- composite TCB.
-
- The TCB modules that contain the reference validation mechanism must be
- associated with the TCB subset to which they belong. The procedure for
- generating a new TCB after modifying only one (or several) TCB subsets
- must be described. This may be accommodated by independent regeneration of
- the individual TCB subsets or by regeneration of only the affected TCB
- subsets.
-
- A1-4.3 TEST DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB.
-
- A1-4.4 DESIGN DOCUMENTATION
-
- This requirement applies as stated in the TCSEC to the composite TCB, with
- the following specific additional interpretations:
-
- Requirements concerning models, FTLS and DTLS, apply to individual TCB
- subsets.
-
- The requirement concerning the description of interfaces between modules
- of the TCB includes the interfaces between TCB subsets.
-
- The documentation of the implementation of a reference validation
- mechanism must include justification for meeting the conditions for
- evaluation by parts.
-
- The A1 requirement to describe clearly non-FTLS internals of the TCB
- applies to TCB subsets.
-
- Statement from TCSEC
-
- The interfaces between the TCB modules shall be described.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and the interfaces between TCB subsets.
-
- Statement from TCSEC
-
- The specific TCB protection mechanisms shall be identified and an
- explanation given to show that they satisfy the model.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- each TCB subset and shall include the protection mechanisms which support
- the conditions for TCB subset structure and separate subset-domains.
-
- Statement from TCSEC
-
- The descriptive top-level specification (DTLS) shall be shown to be an
- accurate description of the TCB interface.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement applies to
- the interface between the TCB subsets as well as to the user interface of
- the composite TCB. The TCB interface description shall include an
- explanation of how to describe the total TCB accurately, in the context of
- the multiple TCB subset DTLSs.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB implements the reference monitor
- concept and give an explanation of why it is tamper resistant, cannot be
- bypassed, and is correctly implemented.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to each TCB subset with respect to its specific
- technical policy. In addition, there must be documented an informal
- argument that the cooperative action of the TCB subsets makes the TCB
- itself tamper resistant, non-bypassable, and correct.
-
- Statement from TCSEC
-
- The TCB implementation shall be informally shown to be consistent with the
- DTLS.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to individual TCB subsets.
-
- Statement from TCSEC
-
- The TCB implementation shall be informally shown to be consistent with the
- FTLS.
-
- Interpretation
-
- If the TCB is composed of multiple TCB subsets, this requirement is
- interpreted to apply to individual TCB subsets.
-
- Statement from TCSEC
-
- Documentation shall describe how the TCB is structured to facilitate
- testing and to enforce least privilege.
-
- Interpretation
-
- If the TCB is composed of multiple subsets, this requirement is
- interpreted to apply to individual TCB subsets as well as to the overall
- TCB.
-
- APPENDIX B
-
- GENERAL ITEMS
-
- 1. PERSPECTIVE ON ASSURANCE
-
- This Trusted Database Management System Interpretation (TDI) of the
- Trusted Computer System Evaluation Criteria (TCSEC) derives its
- perspective on assurance directly from the reference monitor concept as
- recorded in the Anderson Report [1] and as embodied in the TCSEC. In both
- the reference monitor concept and in the TCSEC, the assessment of a system
- for trust characteristics involves a single, global review of the system
- at issue. That same perspective of an even, global review of a candidate
- trusted database management system (DBMS) is present in the TDI, in that
- only complete systems will be considered for assessment. That is, neither
- software packages in isolation nor systems that satisfy only a subset of
- the TCSEC. requirements will be considered for evaluation or
- accreditation. The interpretation of requirements, both in Part 1,
- "Technical Context," and Part 2, "Interpreted Requirements," is consistent
- with both community experience in designing and assessing trusted systems,
- and the precedents of the reference monitor concept and the TCSEC. The
- interpretations, therefore, provide special guidance for the task of
- evaluating (or accrediting) candidate systems composed of distinguishable
- parts. However, the interpretations neither attenuate nor delete TCSEC
- requirements.
-
- It is worth noting that the introduction of the TCSEC with its metric for
- the evaluation of whole systems had as one goal the simplification of the
- task of accrediting computer systems for use in the processing of
- sensitive information. The evaluation process was not intended to replace
- the accreditation process but to provide input to that process. It must be
- recognized that there will be occasions when a fielded suite of computer
- systems, each evaluated against the TCSEC requirements at a particular
- class, will not be able to be assigned a TCSEC class, nor is it necessary
- to be able to make such an assignment. The accreditation decision includes
- the assessment of risk of a particular system configuration in a
- particular environment; a decision to connect a suite of TCSEC evaluated
- systems may have to be made without a uniformly applied TCSEC-like
- assessment over the entire system.
-
- 2. PROCUREMENT OPTIONS
-
- The Trusted Computing System Evaluation Criteria (TCSEC) and its published
- interpretations, including this Trusted Database Management System
- Interpretation, have as a primary purpose the "provision [of] a basis for
- specifying security requirements in acquisition specifications." [8, p. 2]
- In the area of trusted DBMS and trusted systems that include database
- management functionality, there is a range of options open to an
- acquisition organization. These options need to be understood by the
- acquisition managers and their staffs to allow them the greatest possible
- flexibility in matching operational requirements with a combination of
- available products and the state of the art in system integration and
- development.
-
- The fundamental point is the distinction between the target trust class
- (that is, C1, C2, B1, B2, B3, or A1) needed for a particular installation
- and the degree of trusted DBMS functionality that is required. Succinctly,
- a system that requires a particular level of trust (B2, for example) and
- DBMS functionality does not necessarily require an evaluated trusted DBMS
- at the level of B2. In fact, if the statement of required capability
- allows it, meeting the requirement without a trusted DBMS could well be
- the preferred risk-reducing approach. This is generally true because the
- more sophisticated the trusted DBMS requirement, the more likely it is
- that the current vendor base will not be able to supply the needed
- functionality (with the requisite assurance) from the normal product line.
- Further, even if one can specify carefully just what additional assured
- capability is needed so that a program-specific development can be
- undertaken, the lack of community experience and consensus on advanced
- trusted DBMS issues and implementations introduces the potential for
-
- significant programmatic, schedule, and cost risks.
-
- Although a full description of options for the acquisition manager is
- beyond the scope of this document, a representative description of some of
- the options that could be considered is included below. The options
- include (1) multiple copies of a DBMS running at different levels, each
- maintaining single-level databases; (2) a single copy of a DBMS, but with
- each database maintained at a single sensitivity level (i.e., no sharing
- of data between databases); (3) a single copy supporting single level
- databases, but with limited sharing, perhaps of a "snapshot" nature; and
- (4) DBMSs that allow databases that include data of several sensitivity
- levels. This option admits of subcases from the very simple to the very
- complex.
-
- To illustrate the options listed above, consider a command post where a
- commander's staff uses a single computer system. Included on the staff are
- logistics, weather, and intelligence organizations, each dealing with
- information of differing (maximum) sensitivity. If all three organizations
- require similar DBMS functions, there might be a variety of ways to
- provide that functionality.
-
- (1) If the product DBMS-1 suited the needs of each of the
- organizations and there were no requirement to share data between
- them, then three copies of DBMS-1 could be used, running at, for
- example, TOP SECRET, SECRET, and CONFIDENTIAL, respectively, and
- maintaining separate single-level databases. If the organizational
- missions do not require multilevel operations or sharing, this option
- could be perfectly suited to the operational need. In this case,
- every copy of DBMS-1 would be running as an application outside the
- TCB and would not have to be evaluated at all, neither as a product
- nor as a developed system. The advantages of this option are that
- commercial, off-the-shelf systems can be used (both the DBMS and the
- underlying trusted operating system) and no evaluation risk is
- entailed.
-
- The disadvantages are the limited flexibility and the hidden fact that the
- installation procedures for many DBMSs require the insertion of code into
- the heart of the underlying computer system, insertions that would
- undermine the evaluation rating and thus theconfidence in the trusted
- operating system.
-
- (2) A cost advantage could be realized in the preceding case if there
- were a product, DBMS-2, such that a single copy could provide DBMS
- functionality at all three levels. This capability requires that the
- base trusted operating system and the DBMS itself are designed so
- that the DBMS code uses scratch space to allow the code to be shared
- without the potential for mixing control or metadata in workspaces,
- indices, and stacks. Not all commercial DBMSs have this property, so
- this option will be less available than case (1). Note that in this
- case also, the databases themselves are single-level and the
- workspace used by the DBMS itself will have to be single-level.
-
- (3) If the operational requirements are that the intelligence and
- logistics organizations must have access to the weather data maintained by
- the weather organization, the simplest technical solution would be to
- periodically provide a snapshot of the needed weather data for use by the
- other organizations. The database management system DBMS-2 above could
- provide a solution in this case if a portion of the weather database could
- be copied onto diskette (or even into another file) for the other
- organizations to incorporate into their own DBMS operations. The
- disadvantage of this approach is that the information will not be as
- current as that available to the weather organization itself. Frequently,
- however, that lack of currency may be a reasonable price to pay for the
- enormous reductions in cost and risk in procurement and maintenance.
-
- (4) If the operational requirements will not allow anything less than
- real-time sharing of information, then DBMS-2 will not be sufficient. At
- this point, the operational requirements have forced the inclusion of the
- most sophisticated solution to a trusted system with DBMS requirements, a
- true multilevel DBMS. In this case, it remains a valuable goal to minimize
- the complexity of the needed sharing. If the DBMS is providing a
- functionality that looks like tables to the user, then it is less complex
- if each table is at a single level than if each row (or each column) could
- be at a different sensitivity level. The most complex situation is when
- each entry in the table could be at a different sensitivity level. During
- the procurement and development process, it would be worthwhile to
- structure the procurement to favor solutions that are as simple as
- possible from a multilevel trusted DBMS standpoint.
-
- 3. ALTERATION OF PREVIOUSLY EVALUATED TCB
-
- The discussion in Part 1, "Technical Context" arose from consideration of
- the conditions under which it is possible to add an application layer,
- such as a DBMS, to another TCB in such a way as to allow the system rating
- to be determined by evaluating the system elements (i.e., the subsets)
- separately. The benefit to both the applications vendor and the evaluators
- derives from the fact that the DBMS operates as an untrusted subject
- relative to the underlying TCB (even though the DBMS enforces its own
- policy). Therefore, there is no need to re-examine previous evaluation
- evidence; any and ll actions performed by the application layer are
- completely constrained in accordance with the security policy defined for
- the underlying TCB.
-
- The savings in evaluation effort is predicated on the assumption that the
- vendor of the application layer makes no changes of any kind to the other
- TCB. In effect, the argument made by the vendor is as follows:
-
- (a) The underlying TCB enforces policy P[i].
-
- The validity of the claims about the underlying TCB has already been
- established, and these claims remain valid because the underlying TCB has
- not been altered in any way and because the DBMS is completely constrained
- by that policy (i.e., P[i] cannot be violated by any action of the DBMS).
-
- (b) The application is a TCB subset which enforces policy P[k]
-
- Thus, the policy enforced by the composite system (i.e., the policy
- enforced at the user interface of the composite TCB) is merely a
- combination of the policies of the individual TCB subsets.
-
- Because there is neither theory nor experience which allows one to make
- general, a priori statements about the effects of arbitrary changes, any
- alterations to a previously evaluated product must, in general, be
- considered to result in a product whose security attributes, and thus
- whose rating, is unknown. Thus, if the previously evaluated product is
- altered, argument (a) cannot be made merely by referencing the published
- evaluation report. It becomes the responsibility of the DBMS vendor to
- state P[i] (i.e., identify the policy enforced by the altered product) and
- to demonstrate that the implementation satisfies the appropriate TCSEC
- requirements. Hence, at least some evaluation evidence focused on the
- underlying TCB must be provided by the vendor of the application layer.
- The amount of evidence required will be determined by the type, extent,
- and amount of change, as well as the characteristics of the original TCB.
-
- This is not to say, however, that changes always invalidate all previous
- evaluation evidence. Rather, that there is no way to predict what effect
- arbitrary change will have on that evidence. Clearly, some changes will
- invalidate a substantial part, if not all, of the previous evaluation
- results, requiring a completely new evaluation. In some cases it will be
- virtually impossible to determine the full effect of even relatively
- simple changes, whereas in other instances it may be possible to determine
- the effects of at least some changes quite precisely. In a
- well-modularized system, changes to the internals of a module might be
- shown to have no functional or security effect outside of the module. Even
- changes to the module that alter its interface might be shown to have
- effects which do not propagate beyond those modules which have a direct
- interface to the altered module.
-
- In either case however, at least some evidence must be produced about the
- underlying, altered TCB. Thus, the vendor who alters the product which is
- hosting his application becomes responsible for any and all evidence
- required to substantiate the claims being made for both the application
- and the underlying TCB.
-
- In fact, it is always the case that the DBMS vendor is responsible for all
- the evidence required to demonstrate that the system (i.e., the trusted
- components of the application plus the underlying TCB) has the level of
- trust claimed for it. In the case of strict subsetting for evaluation by
- parts, in which the application is layered onto an unaltered,
- previously-evaluated TCB, part of the evidence is satisfied by referencing
- the previous evaluation results and the commercially-available
- specifications for that portion of the system. However, if the previously
- evaluated TCB has been altered, the applications vendor is now responsible
- for demonstrating that the underlying TCB has the level of trust being
- claimed for it. How much, if any, of the previous evaluation evidence is
- still valid is a matter to be resolved.
-
- The development of the subsetting notion has been motivated by the need
- for evaluating systems whose elements may have been developed by different
- vendors. Consequently, the discussion of TCB subsets has been largely
- focused on the topic of extending the policy enforcement attributes of
- previously evaluated TCBs. However, the notion of TCB subsetting provides
- a perfectly general design method. A TCB can be structured and policy
- enforcement allocated to simplify both analysis and evaluation. To the
- extent that each TCB subset in a subsetted system satisfies the conditions
- of TC-4.3, the evaluation can be factored along policy lines, and a rating
- for the composite system determined.
-
- 4. SATISFYING RVM REQUIREMENTS
-
- The evaluation of a system whose TCB is made up of a set of TCB subsets
- follows a logical flow that makes it an orderly process. The initial step
- is satisfying the conditions for evaluation by parts. Those conditions are
- as follows:
-
- Identification of the candidate TCB subsets;
-
- Allocation of the policy (the clear statement of the technical policies
- enforced by the individual TCB subsets, stated in terms of the subjects
- and objects for that TCB subset);
-
- Demonstration that each candidate TCB subset contains its own trusted
- subjects;
-
- Specification of the structure of the TCB subsets (as a collection of
- abstract machines);
-
- Identification of sets of domains (called "subset-domains") assigned for
- the execution of the individual TCB subsets; and
-
- Identification of what externally stated properties of TCB subsets will be
- used to argue convincingly and independently for the RVM nature of each of
- the constituent TCB subsets.
-
- The successful completion of this step, especially the "support for RVM
- arguments" will result in a conditional approval of two items: a set of
- goals in the evaluation of the more primitive TCB subsets and the
- feasibility of being able to argue the RVM properties of less primitive
- TCB subsets using no more information about the more primitive TCB subsets
- than the identified goals. The goals for the more primitive TCB subsets
- will be a set of mechanisms, characteristics, or properties whose proper,
- assured functioning will have to be demonstrated. Examples are domain
- mechanisms, mandatory integrity policy enforcement mechanisms, and a
- special category of object with associated content-preservation
- guarantees. These mechanisms or characteristics or properties are strictly
- a function of the more primitive TCB subset and will have to be evaluated
- and approved in a (possibly) later part of the evaluation process. The
- conditional approval of the feasibility of constructing an independent RVM
- argument for less primitive TCB subsets relies on an interplay between the
- proposed mechanisms of the more primitive TCB subset and the anticipated
- needs of the RVM argument for the less primitive TCB subset.
-
- The next steps of the evaluation process, with regards to the reference
- validation mechanism requirements, involve the independent evaluation of
- the TCB subsets. TCB subsets that have been identified as providing
- features or mechanisms on which other TCB subsets will rely for RVM
- arguments will have to be demonstrated to provide the stated mechanisms
- with the same level of assurance as the target evaluation class of the
- entire system. If all the identified mechanisms can be validated, the
- conditional approval of the "support for RVM arguments" condition remains
- unchanged. If some mechanism cannot be properly established from either a
- functional or an assurance perspective, then the conditional approval of
- that portion of the "support" condition is withdrawn and the evaluation
- effort must regroup.
-
- TCB subsets that were projected to be able to complete RVM arguments
- successfully using no more than the identified "support" mechanisms and
- features will have to have full RVM arguments advanced and accepted by the
- evaluation team. There are three possible outcomes: (1) it could be shown
- that the TCB subset in question does not meet the RVM requirements; (2) it
- could be shown, using the external descriptions and assurances of the
- mechanisms of the more primitive TCB subsets, that the less primitive TCB
- subset does meet the RVM requirements; or (3) it might be impossible to
- determine whether or not the TCB subset meets the requirements. In case
- (1), the TCB subset failed to meet its reference validation mechanism
- requirements and the design team must regroup. In case (2), the TCB subset
- satisfies its reference validation mechanism requirements. In case (3),
- the conditional approval of the "support for RVM arguments" condition will
- be withdrawn and the design and evaluation teams will have to agree on an
- alternate course of action.
-
- In the case that an attempt to establish RVM properties for a less
- primitive TCB subset could not be completed (case (3) above), it might
- well be that additional mechanisms or features of the more primitive TCB
- subset would allow the RVM arguments to be completed successfully. In that
- case, the evaluation team and the design team would have to establish a
- new, augmented set of mechanisms for the "support" condition. The
- evaluation could then continue with the new mechanism requiring validation
- by the evaluation team and the argument for the RVM properties of the less
- primitive TCB subset having to be re-attempted.
-
- It is important to note that the dependency of the less primitive TCB
- subsets on the assured policies and RVM supporting mechanisms makes it
- imperative that the evaluation of the whole TCB be done by a single
- evaluation team through the final determination that the system complies
- with the full
-
- set of requirements for the target class. Thus, in particular, an
- evaluation team addressing an evaluation by parts (including the case of a
- TCB subset that has been previously evaluated and placed on the EPL) must
- be kept together for the entire evaluation. Local evaluation of one TCB
- subset does not justify dissolving the responsible subteam. Later results,
- global or local to another TCB subset, could require a full evaluation
- team current on all aspects of the evaluated configuration. This does not
- mean, of course, that the original evaluation team for a previously
- evaluated EPL product has to be reassembled. A new team, part of which may
- be delegated prime responsibility for that TCB subset, suffices, as long
- as the full team is kept together for the whole evaluation.
-
- 5. SUBSET DEPENDENCY
-
- For candidate TCB subset M, sM denotes the specification of M, including
- as a minimum, the statement of the technical policy P of M. The term vM
- denotes the (engineering) demonstrations of the correctness of the
- implementation of M with respect to its specification. A (candidate) TCB
- subset A "depends (for its correctness)" on (candidate) TCB subset B if
- and only if the arguments within vA assume the correctness of the
- implementation of B with respect to sB.
-
- In less precise terms, the specification sM defines what M is supposed to
- do. M does whatever its implementation allows, features and all. How well
- M does compared to what sM says it should do is encompassed in the
- engineering arguments vM. If, in the argument vA, one has to assume that
- all or part of sB accurately describes what B does, A "depends" on B for
- its correctness.
-
- Example 1: Use of Provided Objects
-
- Suppose TCB subset B provides "file" as a mediated object under its
- technical policy P[B] and that candidate TCB subset A uses B-files to
- store data and executables. If vA uses the fact that different B-files are
- distinct and access to them is constrained by the technical policy P[B]
- (assumptions that are nearly certain to apply), then vA is relying on the
- fact that sB and B match and in this case, A depends on B.
-
- Example 2: Mutually Suspicious Systems
-
- Suppose A and B are mutually suspicious airline reservation systems hosted
- in two interconnected systems belonging to two distinct organizations. It
- is assumed that sA and sB both provide for a capability to accept
- reservations over the network from "foreign" systems using a mutually
- defined protocol. The protocol is carefully and completely specified
- (within both sA and sB) and both vA and vB demonstrate, to the desired
- level of satisfaction, that A and B are correct with respect to sA and sB,
- respectively. A does not depend for its correctness on B because sA is
- complete: for whatever sequence of bits it receives from B, sA specifies
- exactly what behavior A must exhibit, and vA demonstrates that it does
- exhibit that behavior. Similarly, B does not depend upon A for its
- correctness. Neither A nor B depends on the other.
-
- There may well exist a "system specification" that specifies the desired
- behavior of the entire system, but that is irrelevant to the arguments
- that A and B are individually correct with respect to their own
- specifications. It may even be the case that both A and B are individually
- correct, while the combined system is incorrect with respect to the
- "system specification." That is, two correct subsystems can be combined
- improperly with respect to the desired "system specification."
-
- Example 3: Use of Remotely Provided Functionality
-
- Suppose A is a mail server and B a generic SQL DBMS. The specification sA
- (as might be expected) makes no mention of a DBMS; it simply specifies the
- interface behavior (to its human clients) of the mail system. In vA,
- however, we find that the software for A uses tables provided by B to
- store messages. A and B are on separate, interconnected machines. Neither
- sB nor vB make mention of the mail system at all. As in the preceding
- example, sB completely specifies the behavior of B for all received bit
- patterns and sequences. Here, A depends upon B, but B does not depend on
- A. Note that data flow in both directions is completely legitimate and
- does not compromise in any way the "integrity" (correctness) of B.
- Dependency is distinct from "data flow."
-
- This example shows that a superficial examination of the "architecture" of
- a domain structure is insufficient to determine which candidate TCB
- subsets depend upon other TCB subsets. Superficially, this architecture is
- the same as the example of mutually suspicious systems above, but here A
- depends on B. It also shows that an examination of the interface
- specifications is insufficient. Finally, it shows that dependency is not
- the same as the notion of "privilege" (as normally understood in the
- context of operating systems to mean loosened restrictions on allowed
- functions and accesses), because there is in this example no sense in
- which B has access to all of A's internal structures. It only has access
- to some of them.
-
- Example 4: Use of Locally Provided Functionality
-
- Suppose A and B are the mail server and SQL DBMS of the preceding example,
- except that A is implemented in a less privileged ring than B. That is,
- the interconnect is replaced by a ring-crossing service call. Obviously, A
- still depends on B and B does not depend on A. The change is that now B
- has potential access to any of A's structures. The general rule for the
- use of domain protection mechanisms (such as rings) is that if B is
- privileged with respect to A, then A necessarily depends on B (simply by
- virtue of B's privilege to access any of A's structures). Thus, a detailed
- examination of sA and vA is unnecessary to establish dependency.
-
- Cautionary Example
-
- Suppose that A and B are "mutually dependent"; that is, A depends on B and
- B depends on A. This means that vA assumes that B is implemented correctly
- with respect to sB, and vB assumes that A is implemented correctly with
- respect to sA. Further suppose that both vA and vB are valid (reasonable
- and compelling). One would hope that it follows from this that both A and
- B are correct. Unfortunately, this is not always the case.
-
- If A and B are both correct with respect to sA and sB, then vA is a valid
- argument with a true premise and is therefore true. The same is true for B
- and vB.
-
- Suppose, however, that A is implemented incorrectly with respect to sA and
- B is implemented incorrectly with respect to sB. vA is a valid argument
- with a false premise; it is thus valid but (possibly) untrue. Similarly,
- vB is valid but (possibly) untrue. This case shows that it is quite
- possible for vA and vB to both be valid while A and B are both
- (individually) incorrectly implemented.
-
- What has been exposed here is a hidden case of circular reasoning: the
- argument that A is correct is based on the assumption that B is correct,
- and the argument that B is correct is based on the assumption that A is
- correct. Thus, vA depends (circularly) on the assumption that A is
- correct, and vA reduces to the following tautology: if vA is correct with
- respect to sA then vA is correct with respect to sA. It is thus possible
- in principle for mutually dependent subsystems A and B to have vA and vB
- to be logically valid while either A or B, or both, are incorrect with
- respect to their specifications (sA or sB).
-
- To make this result concrete, consider two airline reservation systems, A
- and B, based on the mutually suspicious systems of example 2 above.
- Suppose that A maintains information about all flights originating or
- terminating in the United States while B maintains information about
- flights originating or terminating in Europe. Assume sA includes a
- statement that A will generate flight itineraries from an origin to a
- destination, with appropriate provision for connections. "Appropriate
- provision for connections" means allowing enough time to change planes
- without requiring passengers to wait an excessive period of time. Further
- assume that sB includes a similar statement. From the assumption that A
- meets sA and B meets sB, one can construct a valid argument that A meets
- its specification sA for itineraries orginating or terminating in either
- the U.S. or Europe. A similarly valid argument can be made about B. If,
- however, A stores flight segment times in the local time of the airport
- and B stores them i n Greenwich Mean Time, an itinerary generated by
- either A or B that relies on information from the other will be incorrect
- because of the time differences. Thus, A will not generate accurate,
- timely flight itineraries, even though a valid argument that it does can
- be constructed. This difficulty arises from the presumption that A and B
- are mutually dependent.
-
- 6. TAMPER RESISTANCE ARGUMENTS
-
- The requirement to demonstrate that individual TCB subsets exhibit the
- reference validation mechanism tamper resistance property deserves special
- attention. In a subsetted architecture there are two (related) aspects to
- this requirement. The first is the ability of a less primitive TCB subset
- to maintain control over access to the objects that implement its logic
- and data structures. The second is establishing the assurance that
- policy-critical or correctness-critical data used by a TCB subset is
- persistent (that is, that it does not change or become contaminated with
- other data between the execution of instructions).
-
- A less primitive TCB subset will be using objects and subjects provided by
- a more primitive TCB subset. Thus, policy-critical data will be stored in
- objects that are provided by the more primitive TCB subset rather than in
- some system entity created and maintained by the less primitive TCB subset
- itself.
-
- One part of the tamper resistance argument focuses on being able to
- demonstrate that no alteration of either the policy-critical data or of
- the TCB subset's code is possible. That is, no system entity external to a
- TCB subset (with the possible exception of more primitive TCB subsets upon
- which it depends) should be capable of causing arbitrary changes to that
- TCB subset's code or data structures. If a third, not more primitive TCB
- subset (or a subject totally outside the TCB) were able to gain access to
- an object where policy-critical data was stored, the tamper resistance
- property could not be established for the TCB subset in question. For a
- most-primitive TCB subset, a wide variety of techniques could be used to
- limit access to an object in which such policy-critical data is stored
- (e.g., prohibition on the sharing of objects, strict ownership control of
- the ability to extend access permission, and mandatory access controls).
- Similarly, the conditions for evaluation by parts require that the system
- designer identify a set of mechanisms and their assured properties as the
- basis for demonstrating tamper resistance for each TCB subset.
-
- The second topic is the assurance that the contents of the objects that
- store a TCB subset's policy-critical data not change except through the
- execution of that TCB subset's logic. If a data structure that identified
- an exported object (such as tables or tuples or entities) were to have
- extraneous data inserted by a more primitive TCB subset (for example, as a
- result of garbage collection or the random action of memory management),
- then no basis would exist for arguments concerning the correct
- implementation of the less primitive TCB subset. For a most primitive TCB
- subset (which includes supporting hardware), the argument that the
- policy-critical data is kept current and correct can be made strictly on
- the basis of that TCB subset. However, when a TCB subset obtains resources
- from a more primitive TCB subset, the argument cannot be made strictly on
- the basis of the design of the TCB subset. Rather, the argument must
- proceed from assured mechanisms provided by more primitive TCB subsets.
- This is exactl y analogous to the case of a reference validation mechanism
- for which one relies on mechanisms not strictly included in the design of
- the policy-enforcing elements to establish the requisite properties of
- non-bypassability and tamper resistance. A variety of mechanisms might
- provide a basis for demonstrating that the implementation of a TCB subset
- is correct, even though resources are obtained from a more primitive TCB
- subset (e.g., type-enforcement).
-
- 7. RATIONALE FOR LOCAL AND GLOBAL REQUIREMENTS
-
- Section TC-5, "General Interpreted Requirements," lists the requirements
- of the TCSEC according to how the requirements apply to a TCB made up of
- more than one TCB subset. The general rationale for distinguishing which
- requirements can be satisfied by independent analysis and consideration of
- the TCB subsets was to consider the requirements one at a time to
- determine whether satisfaction of the requirement by the individual TCB
- subsets would necessarily mean that the entire system satisfies the stated
- requirement.
-
- For some requirements, such as those for certain documentation, it is
- clear that the requirement is factorable; that is, it is satisfied for the
- composite TCB if it is satisfied for each of the TCB subsets individually.
- For other requirements, individual system characteristics could make
- factorability of a requirement patently obvious, but not all systems would
- enjoy such simple factorability. An example would be trusted path
- requirements for security-related events: if all security-related ev ents
- occur in the most primitive TCB subset, satisfaction of the requirement by
- that TCB subset suffices to demonstrate that the system meets the
- requirement, but for systems that have security-relevant events in less
- primitive TCB subsets, some explanation of the cooperative action of the
- TCB subsets would be required. For still other requirements, one can
- expect that the satisfaction of the requirement for the entire system will
- always require some explanation of the cooperative action of the
- constituent TCB subsets. Provision of a coherent audit record across
- events in several TCB subsets is in this category.
-
- In the paragraphs below, a brief rationale for identifying requirements as
- wholly or partially global is provided. Those requirements that are not
- listed are considered to be completely local.
-
- Subject Sensitivity Labels
-
- At level B2 and above, the TCSEC requires the following:
-
- The TCB shall immediately notify a terminal user of each change in the
- security level associated with that user during an interactive session. A
- terminal user shall be able to query the TCB as desired for a display of
- the subject's complete sensitivity level.
-
- For subsetted architectures, the user interface could be to a TCB subset
- that does not support a mandatory access control policy. Thus, a change
- noted by a more primitive TCB subset that does support such a policy would
- have to be relayed to the user, possibly through cooperative action of the
- full set of TCB subsets. Similarly, a request by a terminal user for the
- complete sensitivity level could be initially received by a TCB subset
- that does not support a mandatory access control policy and will require
- cooperation between TCB subsets to determine the complete subject
- sensitivity level and to provide that information to the requesting user.
-
- Identification and Authentication
-
- The identification and authentication requirements in the TCSEC address
- the need to correctly associate authorizations with subjects. In a TCB
- made of several TCB subsets, it is possible that only one of the TCB
- subsets will provide identification and authentication, which will be used
- by all the less primitive TCB subsets. Alternatively, identification and
- authentication may be provided directly in more than one TCB subset. In
- either case, the TCB subsets have to work cooperatively to use
- identification and authentication data for uniquely identifying users and
- for associating users with auditable actions.
-
- Trusted Path
-
- At B2, the only required uses of trusted path are login and
- authentication. At B3 and above, occasions "when a positive TCB-to-user
- connection is required (e.g., login, change subject security level)" are
- included. In both cases, a system vendor may choose to use trusted path
- for situations where the security-relevant event could be recognized or
- handled in more than one TCB subset. On those occasions, the careful
- coordination of all the involved TCB subsets in the correct handling of
- trusted path situations must be shown. If a single TCB subset implements
- trusted path and all the invocations of trusted path are limited to that
- TCB subset (that is, the flow of control in responding to a trusted path
- initiation never leaves the TCB subset until the response is completed),
- then nothing further would be required. The description of the limitation
- of trusted path to a single TCB subset will suffice for the global part of
- the requirement, leaving only the demonstration of local satisfaction of
- the requireme nt by the identified TCB subset.
-
- Audit
-
- If each of several TCB subsets meets the audit requirements locally, then
- there is the issue of whether the set of audit records meets the
- requirements of being able to note and record individual user actions, and
- at B3 and above, to be able to initiate required action. If not all the
- TCB subsets meet the audit requirements locally, then the requirements
- must be satisfied by the cooperative action of the set of TCB subsets. In
- both cases, consideration of the audit characteristics of all the TCB
- subsets has to be part of determining that the entire TCB meets the audit
- requirements.
-
- System Architecture
-
- For many of the system architecture requirements, demonstrating that a
- requirement is satisfied by all of the consitituent TCB subsets is
- sufficient to demonstrate that it is satisfied for the composite TCB. The
- requirements for the "TCB [to] maintain a domain for its execution" and
- for the TCB to "maintain process isolation through the provision of
- distinct address spaces" could be satisfied by the entire TCB without each
- constituent TCB meeting the requirement.
-
- The requirement for the TCB to maintain a domain for its execution implies
- the need for each TCB subset to have a domain for its own execution,
- isolated from both untrusted portions of the system and from less
- primitive TCB subsets. The exact wording of the TCSEC requirement could be
- read as disallowing a less primitive TCB subset from occupying a domain
- provided by a more primitive TCB subset and to allocate its subjects to
- domains that do not have access to its own domain: the verb "maintain"
- could be (erroneously) read as requiring each TCB subset to create and
- maintain its own domain for execution. The proper interpretation is that
- the TCB as a whole must provide and maintain such domains for execution,
- rather than each individual TCB subset. Similarly, the exact wording of
- the TCSEC requirement on the "maintain[ing] of process isolation through
- the provision of distinct address spaces" could be read as requiring each
- TCB subset to provide distinct address spaces. The proper interpretation
- is that the TCB as a whole must provide and maintain process isolation,
- either through provision and subsequent use of distinct address spaces, or
- through provision of distinct address spaces by every TCB subset.
-
- Covert Channel Analysis
-
- This requirement applies as stated in the TCSEC to the entire TCB. When
- the TCB is made up entirely of TCB subsets meeting the conditions for
- evaluation by parts, analysis of the individual TCB subsets suffices to
- satisfy this analysis requirement. Otherwise, covert channel analysis must
- address the entire TCB (even if the result of covert channel analyses of
- the individual TCB subsets were available).
-
- Trusted Facility Management
-
- The ability to run a trusted system facility properly applies to the
- combination of TCB subsets making up the TCB. This requirement should not
- be difficult to meet, provided that the individual TCB subsets meet the
- requirement and the interactions between the TCB subsets at the facility
- management level are clear.
-
- Trusted Recovery
-
- In the case of "an ADP system failure or other discontinuity," each TCB
- subset in a B3 or above system needs to be able to recover "without a
- protection compromise." Further, the recovery actions of distinct TCB
- subsets needs to be coordinated and combined so that the resulting system
- is not only recovered as far as each TCB subset is concerned, but is also
- recovered as a composite TCB.
-
- Security Testing
-
- This requirement applies as stated in the TCSEC to the entire TCB. If a
- TCB consists of TCB subsets meeting the conditions for evaluation by
- parts, the satisfaction of the requirements by each TCB subset suffices to
- satisfy the requirement for the entire TCB. Otherwise, security testing
- must include testing of the entire TCB (even if the results of testing the
- individual TCB subsets are available).
-
- Design Specification and Verification
-
- For many of the design specification and verification requirements,
- demonstrating that a requirement is satisfied by all of the consitituent
- TCB subsets is sufficient to demonstrate that it is satisfied for the
- composite TCB. The requirements for a "formal model of the security policy
- supported by the TCB" and that the DTLS at B3 and the FTLS at A1 "be an
- accurate description of the TCB interface" apply in a limited way to the
- entire TCB.
-
- After complying security models are provided for the individual TCB
- subsets, a convincing argument is required to explain how the set of
- models represents abstractly the policy of the entire system.
-
- After complying top-level specifications (DTLS at B3 and FTLS at A1) are
- provided for the individual TCB subsets, an explicit and convincing
- description of how the set of top-level specifications describe the TCB
- interface with respect to exceptions, errors and effects must also be
- provided.
-
- 8. CONTENT-DEPENDENT AND CONTEXT-DEPENDENT ACCESS CONTROL
-
- An attractive proposition in a database managment system is to implement
- access controls that depend in some way on the values of the data in a
- storage object or the context in which the information is accessed. For
- example, one might desire to limit access to all personnel records in a
- database according to the salary value (content-dependent access rules).
- On the other hand, a company's earnings report might be held in confidence
- until announced at the stockholders' meeting, at which time it is public
- information (context-dependent access rules).
-
- This document does not encourage or endorse mandatory access control on
- storage objects that are based on the content of data values or on the
- context in which the information is viewed. Given that these are research
- topics, it is prudent to take this conservative stance. Research and
- current practice are insufficient to allow definitive guidance on such
- implementations.
-
- 9. BULK LOADING OF A DATABASE
-
- The bulk loading of a database into (perhaps thousands of) database
- objects must be done with care. If the data to be loaded are unlabeled, it
- may not be practical to require an authorized user to examine the data to
- be loaded into each object and assign it a sensitivity label. Instead it
- may be more practical to assign labels to the data according to the
- sensitivity label of the single-level device that is used to import it. In
- this way, bulk loading may be done in single-level stages.
-
- Even importing labeled multilevel data may prove difficult. The imported
- data records may be organized on the input device in accordance with their
- logical structure, not their sensitivity levels. For some trusted DBMS
- architectures, this requires that the TCB first separate the data by
- sensitivity levels and subsequently load the data into the database as
- single-level structures.
-
- Another problem with bulk loading of labeled data is granularity. It may
- be that the labeling granularity of data on the input device is different
- from the labeling granularity supported by the receiving trusted DBMS. As
- an example, the data being imported may be labeled at the file or field
- level, and the importing DBMS may support labeling at the tuple level. In
- such instances, the data would have to be mapped into objects of the
- proper labeling granularity as the data are being imported.
-
- 10. LOCAL ANALYSIS IN SYSTEM ASSESSMENT
-
- The ability to distinguish and separately reference the results of local
- analysis of TCB subsets is a primary aspect of evaluation by parts, and
- the benefits which accrue are apparent in two, closely related, cases that
- arise in evalutions by parts. These may be thought of as dealing with the
- problems of "hosting" and "porting" although they are actually two aspects
- of the same problemthat of assessing a trusted system constructed of
- previously evaluated parts.
-
- For the first case (i.e., that of "hosting"), consider an operating system
- which has been evaluated against the TCSEC requirements and has received a
- rating. Thus, the operating system is a TCB for which both the local and
- global analysis has been done. The results of the local analysis can now
- be used to support the evaluation of a TCB made up of the operating system
- (or, the more primitive TCB subset) and any proposed TCB extension (or,
- less primitive TCB subset). Suppose, for example, that vendor A chooses
- the rated operating system as the host for a DBMS product, which
- implements an access control policy. As described in TC-6, it is now
- possible, under the
-
- correct conditions, to re-use the results of the local analysis of the
- host operating system in developing a rating for the composite system.
- Even for those cases not meeting all the conditions for evaluation by
- parts, it may be possible that some, if not most, of the previous results
- are still valid. If vendor B also chooses the rated operating system as
- the host for his DBMS product, it will be possible (again, under the
- proper conditions) to develop a rating for the (new) composite system
- without having to repeat the local analysis of the host operating system.
- As an alternate case, suppose a site has need of an electronic mail
- service as well as the DBMS utility. The mail utility will operate in a
- peer-entity relation with the trusted DBMS utility (i.e., both the mail
- service and the DBMS depend on the host operating system, but neither
- depends on the other). Again, having the results of the local analysis of
- the host operating system eases the burden of assessing the security
- characteristics of the user interface to the composite system made up of
- the mail system and the host operating system. In short, the ability to
- distinguish and separately reference the results of the local analysis of
- the host operating system makes it feasible to evaluate the effect of
- adding arbitrary trusted applications, only by performing the local
- analyis for the application and any global analysis required.
-
- For the second case, (i.e., that of "porting") the question becomes that
- of determining the effect of moving a known trusted application, such as a
- DBMS, across arbitrary host systems. Assume that a trusted DBMS product
- meeting the conditions for evaluation by parts has been evaluated on some
- trusted host, and a rating determined for the composite system. Clearly,
- the results of the local analysis of the trusted application available are
- also applicable to the analysis of a composite system made up of the
- trusted application and a different host operating system. Thus, having
- the local analysis of the trusted application will ease the evaluation
- burden associated with porting of trusted applications to different hosts.
- To the extent that the conditions for evaluations by parts have been
- satisfied, the local analysis of the application is valid by reference.
-
- Hence only the local analysis of the host operating system and the
- requisite global analysis is needed to assess the security attributes of
- the new composite system.
-
- 11. RATING MORE COMPLEX SYSTEMS
-
- The view taken by the TCSEC is that of an "atomic" TCB; the TCB is seen to
- be a single entity which is, in some sense, homogeneous. This allows a
- relatively simple measure (i.e., the digraphs) to be assigned to the TCB.
- However, real systems may be more complex, resulting in the inability of a
- single, simple rating to convey the full complexity of the system. This is
- implicitly recognized in TCSEC evaluation reports and EPL entries, in
- which credit may be given to a vendor for meeting TCSEC (functional)
- requirements beyond those necessary to satisfy the rating (e.g., the B3
- discretionary access control feature in a C2 TCB). In short, systems which
- reflect straightforward implementations or extensions of the TCSEC can
- accurately be described with a single digraph. On the other hand, adding
- complexity to systems may violate assumptions which underlie the TCSEC
- rating system, requiring a more complex description if accuracy is to be
- achieved.
-
- If a TCB made up of TCB subsets is consistent with the TCSEC assumptions
- on homogeneity, then a simple digraph suffices for a full and accurate
- description of the security properties of the product. However, to the
- extent that a subsetted architecture introduces complexity not captured by
- the digraphs, the simple TCSEC ratings cannot be applied to the composite
- system. More specifically, for a subsetted TCB to achieve a single rating,
- all the requirements of that class must be satisfied. For example, if a
- discretionary access control-enforcing DBMS TCB subset is added onto a
- previously evaluated B3 product, the entire system can achieve a B3 rating
- if it could also have achieved the B3 rating evaluated as a monolith. That
- is, the new TCB subset must also satisfy all the assurance and
- architectural requirements of B3.
-
- Consider a candidate TCB subset which enforces a discretionary access
- control policy over a new type of object, targeted at a host system which
- has already been evaluated at the B3 level. Examples are a database
- management system providing discretionary access control over tuples, a
- transaction processor providing discretionary access control over
- transactions, and a message system providing discretionary access control
- over messages. If the candidate TCB subset meets all the C2 requirements,
- the problem is what rating will be assigned to the composite system. To
- designate it a "C2" is clearly inaccurate, as well as being unfair to the
- original B3 product vendor. To designate it "B3" may be equally
- inaccurate, and it creates ambiguity in the meaning of the metric used for
- comparing systems. In fact, depending on the details of the specific
- candidate, the composite system could legitimately be rated at any level
- from C2 to B3 under a TCSEC evaluation.
-
- The TCSEC rating system assumes a measure of homogeneity which the above
- example violates thus invalidating the very basis upon which a single
- digraph may be assigned. Hence, a subsetted system such as described
- above, will have to be characterized with a more complex description than
- a single digraph.
-
- Although this may seem undesirable, it will be a more accurate description
- of the system, and it provides sufficient information to allow system
- designers and accreditors to make decisions about sufficiency of security
- for their specific applications. In essence, such an approach is necessary
- for recognizing the additional complexity which can be introduced by
- architectures which allow system elements to be developed separately.
-
- GLOSSARY
-
- candidate TCB subset The identification of the hardware, firmware, and
- software that make up the proposed TCB subset, along with the
- identification of its subjects and objects; one of the conditions for
- evaluation by parts
-
- content-dependent access control Access control in which access is
- determined by the value of the data to be accessed.
-
- context-dependent access control Access control in which access is
- determined by the specific circumstances under which the data is being
- accessed.
-
- database management system A computer system whose main function is to
- facilitate the sharing of a common set of data among many different users.
- It may or may not maintain semantic relationships among the data items.
-
- DBMS Abbreviation for "database management system."
-
- depends A TCB subset A depends (for its correctness) on TCB subset B if
- and only if the (engineering) arguments of the correct implementation of A
- with respect to its specification assume, wholly or in part, that the
- specification of B has been implemented correctly.
-
- domain The set of objects that a subject has the ability to access.
-
- dominated by Security level A is dominated by security level B if (1) the
- clearance/classification in A is less than or equal to the
- clearance/classification in B, and (2) the set of access approvals (e.g.,
- compartment designators) in A is contained in the set of access approvals
- in B (i.e., each access approval appearing in A also appears in B). This
- dominance relation is a special case of a partial order.
-
- dominates "Security level B dominates security level A" is synonymous with
- "security level A is dominated by security level B." See "dominated by."
-
- global requirements Those which require analysis of the entire system and
- for which separate analysis of the individual TCB subsets does not
- suffice. See Section TC-5.3.2 for a summary list.
-
- lattice A partially ordered set for which every pair of elements has a
- greatest lower bound and a least upper bound.
-
- local requirements Those for which separate analysis of the individual TCB
- subsets suffices to determine compliance for the composite TCB. See
- Section TC-5.3.1 for summary list.
-
- metadata (1) Data referring to other data; data (such as data structures,
- indices, and pointers) that are used to instantiate an abstraction (such
- as "process," "task," "segment," "file," or "pipe"). (2) A special
- database, also referred to as a data dictionary, containing descriptions
- of the elements (e.g., relations, domains, entities, or relationships) of
- a database.
-
- monolithic TCB A TCB that consists of a single TCB subset.
-
- object A passive entity that contains or receives information. Access to
- an object potentially implies access to the information it contains.
- Examples of objects are: records, blocks, pages, segments, files,
- directories, directory trees, and programs, as well as bits, bytes, words,
- fields, processors, video displays, keyboards, clocks, printers, network
- nodes, etc.
-
- partial order A relation that is symmetric (a is related to a), transitive
- (if a is related to b and b is related to c, then a is related to c), and
- antisymmetric (if a is related to b and b is related to a, then a and b
- are identical.)
-
- primitive An ordering relation between TCB subsets based on dependency
- (see "depends" above). A TCBsubset B is more primitive than a second TCB
- subset A (and A is less primitive than B) if (a) A directly depends on B
- or (b) a chain of TCB subsets from A to B exists such that each element of
- the chain directly depends on its successor in the chain.
-
- reference monitor concept An access control concept that refers to an
- abstract machine that mediates all accesses to objects by subjects.
-
- reference validation mechanism "An implementation of the reference monitor
- concept . . . that validates each reference to data or programs by any
- user (program) against a list of authorized types of reference for that
- user." It must be tamper proof, must always be invoked, and must be small
- enough to be subject to analysis and tests, the completeness of which can
- be assured. [1]
-
- security policy The set of laws, rules, and practices that regulate how an
- organization manages, protects, and distributes sensitive information.
-
- storage object An object that supports both read and write accesses.
-
- subject An active entity, generally in the form of a person, process, or
- device that causes information to flow among objects or changes the system
- state. Technically, a process/domain pair.
-
- subset-domain A set of system domains. For evaluation by parts, each
- candidate TCB subset must occupy a distinct subset domain such that
- modify-access to a domain within a TCB subset's subset-domain is permitted
- only to that TCB subset and (possibly) to more primitive TCB subsets.
-
- TCB subset A set of software, firmware, and hardware (where any of these
- three could be absent) that mediates the access of a set S of subjects to
- a set O of objects on the basis of a stated access control policy P and
- satisfies the properties:
-
- (1) M mediates every access to objects O by subjects in S;
- (2) M is tamper resistant; and
- (3) M is small enough to be subject to analysis and tests, the
- completeness of which can be assured.
-
- technical policy The set of rules regulating access of subjects to
- objects enforced by a computer system.
-
- Trusted Computing Base (TCB) The totality of protection mechanisms within
- a computer system including hardware, firmware, and software the
- combination of which is responsible for enforcing a security policy. A TCB
- consists of one or more components that together enforce a unified
- security policy over a product or system. The ability of a TCB to
- correctly enforce a security policy depends solely on the mechanisms
- within the TCB and on the correct input by system administrative personnel
- of parameters (e.g., a user's clearance) related to the security policy.
-
- trusted subject A subject that is permitted to have simultaneous view- and
- alter-access to objects of more than one sensitivity level.
-
- user Any person who interacts directly with a computer system.
-
- view That portion of the database that satisfies the conditions specified
- in a query.
-
- view definition A stored query; sometimes loosely referred to as a "view."
-
- BIBLIOGRAPHY
-
- 1. J. P. Anderson, "Computer Security Technology
-
- Planning Study," ESD-TR-73-51 (AD-758206), J. P.
-
- Anderson Co., October 1972.
-
- 2. J. P. Anderson, "On the Feasibility of Connecting
- RECON to an External Network," Technical Report, J. P.
- Anderson Co., March 1981.
- 3. D. E. Bell and L. J. La Padula, "Secure
- Computer Systems: Unified Exposition and Multics Interpretation,"
- MTR-2997, (AY/W 020 445), The MITRE Corporation, Bedford,
- Massachusetts, July 1975.
- 4. D. E. Bell and L. J. La Padula, "Secure
-
- Computer Systems: Mathematical Foundations,"
-
- MTR-2547-I, (AD 770 768), The MITRE Corporation,
-
- Bedford, Massachusetts, March 1973.
-
- 5. L. J. La Padula and D. E. Bell, "Secure
- Computer Systems: A Mathematical Model," MTR 2547-II, (AD 771 543),
- The MITRE Corporation, Bedford, Massachusetts, May 1973.
- 6. D. E. Bell, "Secure Computer Systems: A
- Refinement of the Mathematical Model," MTR 2547-III,
- (AD 780 528), The MITRE Corporation, Bedford,
-
- Massachusetts, December 1973.
-
- 7. D. E. Bell, "Secure Computer Systems: A Network
- Interpretation," Proceedings of the Second Aerospace Computer
- Security Conference, McLean Virginia, December 2-4, 1986, pp. 32-39.
-
- 8. Department of Defense, Department of Defense
-
- Trusted Computer System Evaluation Criteria, DOD
-
- 5200.28-STD, December 1985.
-
- 9. D. E. Denning, "Cryptographic Checksums for
- Multilevel Database Security," Proceedings of the IEEE Symposium on
- Security & Privacy, Oakland, California, April 29-May 2, 1984, pp.
- 52-61.
- 10. D. E. Denning, "Commutative Filters for Reducing
- Inference Threats in Multilevel Database Systems," Proceedings of the
- IEEE Symposium on Security & Privacy, Oakland, California, April
- 22-24, 1985, pp. 134-146.
- 11. E. B. Fernandez, R. C. Summers, and C. Wood,
- Database Security and Integrity, Boston, Massachusetts:
- Addison Wesley, 1981.
- 12. C. Garvey and A. Wu, "ASD Views," Proceedings of the Fourth
- Aerospace Computer Security Applications Conference, Orlando,
- Florida, December 1988, pp. 85-95.
- 13. R. D. Graubart and J. P. L. Woodward, "A
- Preliminary Naval Surveillance DBMS Security Model," Proceedings of
- the IEEE Symposium on Security & Privacy, Oakland, California, April
- 26-28, 1982, pp. 21-37.
- 14. R. D. Graubart, "The Integrity-Lock Approach to
- Secure Database Management," Proceedings of the IEEE
- Symposium on Security & Privacy, Oakland, California,
-
- April 29-May 2, 1984, pp. 62-74.
-
- 15. M. J. Grohn, "A Model of a Protected Data
- Management System," ESD-TR-76-289, I. P. Sharp Associates, Ltd., June
- 1976.
- 16. T. H. Hinke, M. Schaefer et al., "Secure Data
- Management System," RADC-TR-75-266 (AD-A019201), System Development
- Corporation, Santa Monica, California, November 1975.
- 17. C. E. Landwehr, C. L. Heitmeyer, and J.
- McLean, "A Security Model for Military Message Systems," ACM
- Transactions on Computer Systems, Vol. 2, No. 3, August 1984, pp.
- 198-222.
- 18. T. F. Lunt, D. E. Denning, P. G. Neumann, R.
- R. Schell, M. Heckman, and W. R. Shockley, "Final
-
- Report Vol. 1: Security Policy and Policy
-
- Interpretation for a Class A1 Multilevel Secure
-
- Relational Database System," Computer Science
-
- Laboratory, SRI International, Menlo Park, California, 1988.
-
- 19. J. McHugh and B. M. Thuraisingham, "Multilevel
- Security Issues in Distributed Database Management Systems,"
- Computers & Security, Vol. 7, No. 4, Elsevier Advanced Technology
- Publications, August 1988, pp. 387-396.
- 20. National Computer Security Center, Proceedings of the National
- Computer Security Center Invitational Workshop on Database Security,
- Baltimore, Maryland, June 17-20, 1986.
- 21. P. A. Rougeau and E. D. Sturms, "The Sybase
- Secure Dataserver: A Solution to the Multilevel Secure
-
- DBMS Problem," Proceedings of the 10th National
-
- Computer Security Conference, Baltimore, Maryland,
-
- September 21-24, 1987, pp. 211-215.
-
- 22. M. Schaefer, ed., Multilevel Data Management
-
- Security, Air Force Studies Board, Committee on
-
- Multilevel Data Management Security, National Academy Press: Washington,
- D.C., 1983.
-
- 23. M. D. Schroeder and J. H. Saltzer, "A Hardware
- Architecture for Implementing Protection Rings," Communications of
- the ACM, Vol. 15, No. 3, March 1972, pp.157-170.
- 24. W. R. Shockley and R. R. Schell, "TCB Subsets for Incremental
- Evaluation," Proceedings of the Third Aerospace Computer Security
- Conference, Orlando, Florida, December 7-11, 1987, pp. 131-139.
- 25. P. Stachour and B. Thuraisingham, "Design of LDV
- ₧ A Multilevel Secure Database Management System," IEEE
- Transactions on Knowledge and Data Engineering, Vol. 2, No. 2,
- June 1990, pp. 190-209.
-
- 26. M. Stonebraker, "Operating System Support for Database
- Management," Communications of the ACM, Vol. 24, No. 7, July 1981,
- pp. 412-418.
-
- 27. Unisys Corporation, "Secure Distributed Database
- Management System," Final Technical Report, Rome Air Development
- Center Technical Report, RADC-TR-89-314, Vol. 1-5, December 1989.
- 28. J. Wilson, "Views as the Security Objects in a
- Multi-level Secure Relational Database Management System,"
- Proceedings of the 1988 IEEE Symposium on Security & Privacy,
- Oakland, California, April 18-21, 1988, pp. 70-84.
-
-
-
-
-
-
-