From brian@ucsd.Edu Sun Jun 24 22:18:09 1990 From: brian@ucsd.Edu (Brian Kantor) Newsgroups: comp.doc Subject: Computer Security - 1983 Orange Book [part 4 of 5] Date: 23 Jun 90 15:12:20 GMT Distribution: usa Organization: The Avant-Garde of the Now, Ltd. 7.3 Criteria Control Objective for Security Policy 7.3.1 Marking The control objective for marking is: "Systems that are designed to enforce a mandatory security policy must store and preserve the integrity of classification or other sensitivity labels for all information. Labels exported from the system must be accurate representations of the corresonding internal sensitivity labels being exported." DoD 5220.22-M, "Industrial Security Manual for Safeguarding Classified Information," explains in paragraph 11 the reasons for marking information: "Designation by physical marking, notation or other means serves to inform and to warn the holder about the classification designation of the information which requires protection in the interest of national security. The degree of protection against unauthorized disclosure which will be required for a particular level of classification is directly commensurate with the marking designation which is assigned to the material."[11] Marking requirements are given in a number of policy statements. Executive Order 12356 (Sections 1.5.a and 1.5.a.1) requires that classification markings "shall be shown on the face of all classified documents, or clearly associated with other forms of classified information in a manner appropriate to the medium involved."[14] DoD Regulation 5200.1-R (Section 1-500) requires that: ". . . information or material that requires protection against unauthorized disclosure in the interest of national security shall be classified in one of three designations, namely: 'Top Secret,' 'Secret' or 'Confidential.'"[7] (By extension, for use in computer processing, the unofficial designation "Unclassified" is used to indicate information that does not fall under one of the other three designations of classified information.) DoD Regulation 5200.1-R (Section 4-304b) requires that: "ADP systems and word processing systems employing such media shall provide for internal classification marking to assure that classified information contained therein that is reproduced or generated, will bear applicable classification and associated markings." (This regulation provides for the exemption of certain existing systems where "internal classification and applicable associated markings cannot be implemented without extensive system modifications."[7] However, it is clear that future DoD ADP systems must be able to provide applicable and accurate labels for classified and other sensitive information.) DoD Manual 5200.28-M (Section IV, 4-305d) requires the following: "Security Labels - All classified material accessible by or within the ADP system shall be identified as to its security classification and access or dissemination limitations, and all output of the ADP system shall be appropriately marked."[9] 7.3.2 Mandatory Security The control objective for mandatory security is: "Security policies defined for systems that are used to process classified or other specifically categorized sensitive information must include provisions for the enforcement of mandatory access control rules. That is, they must include a set of rules for controlling access based directly on a comparison of the individual's clearance or authorization for the information and the classification or sensitivity designation of the information being sought, and indirectly on considerations of physical and other environmental factors of control. The mandatory access control rules must accurately reflect the laws, regulations, and general policies from which they are derived." There are a number of policy statements that are related to mandatory security. Executive Order 12356 (Section 4.1.a) states that "a person is eligible for access to classified information provided that a determination of trustworthiness has been made by agency heads or designated officials and provided that such access is essential to the accomplishment of lawful and authorized Government purposes."[14] DoD Regulation 5200.1-R (Chapter I, Section 3) defines a Special Access Program as "any program imposing 'need-to-know' or access controls beyond those normally provided for access to Confidential, Secret, or Top Secret information. Such a program includes, but is not limited to, special clearance, adjudication, or investigative requirements, special designation of officials authorized to determine 'need-to-know', or special lists of persons determined to have a 'need-to- know.'"[7, para. 1-328] This passage distinguishes between a 'discretionary' determination of need-to-know and formal need-to-know which is implemented through Special Access Programs. DoD Regulation 5200.1-R, paragraph 7-100 describes general requirements for trustworthiness (clearance) and need-to-know, and states that the individual with possession, knowledge or control of classified information has final responsibility for determining if conditions for access have been met. This regulation further stipulates that "no one has a right to have access to classified information solely by virtue of rank or position." [7, para. 7-100]) DoD Manual 5200.28-M (Section II 2-100) states that, "Personnel who develop, test (debug), maintain, or use programs which are classified or which will be used to access or develop classified material shall have a personnel security clearance and an access authorization (need-to-know), as appropriate for the highest classified and most restrictive category of classified material which they will access under system constraints."[9] DoD Manual 5220.22-M (Paragraph 3.a) defines access as "the ability and opportunity to obtain knowledge of classified information. An individual, in fact, may have access to classified information by being in a place where such information is kept, if the security measures which are in force do not prevent him from gaining knowledge of the classified information."[11] The above mentioned Executive Order, Manual, Directives and Regulations clearly imply that a trusted computer system must assure that the classification labels associated with sensitive data cannot be arbitrarily changed, since this could permit individuals who lack the appropriate clearance to access classified information. Also implied is the requirement that a trusted computer system must control the flow of information so that data from a higher classification cannot be placed in a storage object of lower classification unless its "downgrading" has been authorized. 7.3.3 Discretionary Security The term discretionary security refers to a computer system's ability to control information on an individual basis. It stems from the fact that even though an individual has all the formal clearances for access to specific classified information, each individual's access to information must be based on a demonstrated need-to-know. Because of this, it must be made clear that this requirement is not discretionary in a "take it or leave it" sense. The directives and regulations are explicit in stating that the need-to-know test must be satisfied before access can be granted to the classified information. The control objective for discretionary security is: "Security policies defined for systems that are used to process classified or other sensitive information must include provisions for the enforcement of discretionary access control rules. That is, they must include a consistent set of rules for controlling and limiting access based on identified individuals who have been determined to have a need-to-know for the information." DoD Regulation 5200.1-R (Paragraph 7-100) In addition to excerpts already provided that touch on need-to- know, this section of the regulation stresses the need- to-know principle when it states "no person may have access to classified information unless . . . access is necessary for the performance of official duties."[7] Also, DoD Manual 5220.22-M (Section III 20.a) states that "an individual shall be permitted to have access to classified information only . . . when the contractor determines that access is necessary in the performance of tasks or services essential to the fulfillment of a contract or program, i.e., the individual has a need-to-know."[11] 7.4 Criteria Control Objective for Accountability The control objective for accountability is: "Systems that are used to process or handle classified or other sensitive information must assure individual accountability whenever either a mandatory or discretionary security policy is invoked. Furthermore, to assure accountability the capability must exist for an authorized and competent agent to access and evaluate accountability information by a secure means, within a reasonable amount of time, and without undue difficulty." This control objective is supported by the following citations: DoD Directive 5200.28 (VI.A.1) states: "Each user's identity shall be positively established, and his access to the system, and his activity in the system (including material accessed and actions taken) controlled and open to scrutiny."[8] DoD Manual 5200.28-M (Section V 5-100) states: "An audit log or file (manual, machine, or a combination of both) shall be maintained as a history of the use of the ADP System to permit a regular security review of system activity. (e.g., The log should record security related transactions, including each access to a classified file and the nature of the access, e.g., logins, production of accountable classified outputs, and creation of new classified files. Each classified file successfully accessed [regardless of the number of individual references] during each 'job' or 'interactive session' should also be recorded in the audit log. Much of the material in this log may also be required to assure that the system preserves information entrusted to it.)"[9] DoD Manual 5200.28-M (Section IV 4-305f) states: "Where needed to assure control of access and individual accountability, each user or specific group of users shall be identified to the ADP System by appropriate administrative or hardware/software measures. Such identification measures must be in sufficient detail to enable the ADP System to provide the user only that material which he is authorized."[9] DoD Manual 5200.28-M (Section I 1-102b) states: "Component's Designated Approving Authorities, or their designees for this purpose . . . will assure: . . . . . . . . . . . . . . . . . (4) Maintenance of documentation on operating systems (O/S) and all modifications thereto, and its retention for a sufficient period of time to enable tracing of security- related defects to their point of origin or inclusion in the system. . . . . . . . . . . . . . . . . . (6) Establishment of procedures to discover, recover, handle, and dispose of classified material improperly disclosed through system malfunction or personnel action. (7) Proper disposition and correction of security deficiencies in all approved ADP Systems, and the effective use and disposition of system housekeeping or audit records, records of security violations or security-related system malfunctions, and records of tests of the security features of an ADP System."[9] DoD Manual 5220.22-M (Section XIII 111) states: "Audit Trails a. The general security requirement for any ADP system audit trail is that it provide a documented history of the use of the system. An approved audit trail will permit review of classified system activity and will provide a detailed activity record to facilitate reconstruction of events to determine the magnitude of compromise (if any) should a security malfunction occur. To fulfill this basic requirement, audit trail systems, manual, automated or a combination of both must document significant events occurring in the following areas of concern: (i) preparation of input data and dissemination of output data (i.e., reportable interactivity between users and system support personnel), (ii) activity involved within an ADP environment (e.g., ADP support personnel modification of security and related controls), and (iii) internal machine activity. b. The audit trail for an ADP system approved to process classified information must be based on the above three areas and may be stylized to the particular system. All systems approved for classified processing should contain most if not all of the audit trail records listed below. The contractor's SPP documentation must identify and describe those applicable: 1. Personnel access; 2. Unauthorized and surreptitious entry into the central computer facility or remote terminal areas; 3. Start/stop time of classified processing indicating pertinent systems security initiation and termination events (e.g., upgrading/downgrading actions pursuant to paragraph 107); 4. All functions initiated by ADP system console operators; 5. Disconnects of remote terminals and peripheral devices (paragraph 107c); 6. Log-on and log-off user activity; 7. Unauthorized attempts to access files or programs, as well as all open, close, create, and file destroy actions; 8. Program aborts and anomalies including identification information (i.e., user/program name, time and location of incident, etc.); 9. System hardware additions, deletions and maintenance actions; 10. Generations and modifications affecting the security features of the system software. c. The ADP system security supervisor or designee shall review the audit trail logs at least weekly to assure that all pertinent activity is properly recorded and that appropriate action has been taken to correct any anomaly. The majority of ADP systems in use today can develop audit trail systems in accord with the above; however, special systems such as weapons, communications, communications security, and tactical data exchange and display systems, may not be able to comply with all aspects of the above and may require individualized consideration by the cognizant security office. d. Audit trail records shall be retained for a period of one inspection cycle."[11] 7.5 Criteria Control Objective for Assurance The control objective for assurance is: "Systems that are used to process or handle classified or other sensitive information must be designed to guarantee correct and accurate interpretation of the security policy and must not distort the intent of that policy. Assurance must be provided that correct implementation and operation of the policy exists throughout the system's life-cycle." A basis for this objective can be found in the following sections of DoD Directive 5200.28: DoD Directive 5200.28 (IV.B.1) stipulates: "Generally, security of an ADP system is most effective and economical if the system is designed originally to provide it. Each Department of Defense Component undertaking design of an ADP system which is expected to process, store, use, or produce classified material shall: From the beginning of the design process, consider the security policies, concepts, and measures prescribed in this Directive."[8] DoD Directive 5200.28 (IV.C.5.a) states: "Provision may be made to permit adjustment of ADP system area controls to the level of protection required for the classification category and type(s) of material actually being handled by the system, provided change procedures are developed and implemented which will prevent both the unauthorized access to classified material handled by the system and the unauthorized manipulation of the system and its components. Particular attention shall be given to the continuous protection of automated system security measures, techniques and procedures when the personnel security clearance level of users having access to the system changes."[8] DoD Directive 5200.28 (VI.A.2) states: "Environmental Control. The ADP System shall be externally protected to minimize the likelihood of unauthorized access to system entry points, access to classified information in the system, or damage to the system."[8] DoD Manual 5200.28-M (Section I 1-102b) states: "Component's Designated Approving Authorities, or their designees for this purpose . . . will assure: . . . . . . . . . . . . . . . . . (5) Supervision, monitoring, and testing, as appropriate, of changes in an approved ADP System which could affect the security features of the system, so that a secure system is maintained. . . . . . . . . . . . . . . . . . (7) Proper disposition and correction of security deficiencies in all approved ADP Systems, and the effective use and disposition of system housekeeping or audit records, records of security violations or security-related system malfunctions, and records of tests of the security features of an ADP System. (8) Conduct of competent system ST&E, timely review of system ST&E reports, and correction of deficiencies needed to support conditional or final approval or disapproval of an ADP System for the processing of classified information. (9) Establishment, where appropriate, of a central ST&E coordination point for the maintenance of records of selected techniques, procedures, standards, and tests used in the testing and evaluation of security features of ADP Systems which may be suitable for validation and use by other Department of Defense Components."[9] DoD Manual 5220.22-M (Section XIII 103a) requires: "the initial approval, in writing, of the cognizant security office prior to processing any classified information in an ADP system. This section requires reapproval by the cognizant security office for major system modifications made subsequent to initial approval. Reapprovals will be required because of (i) major changes in personnel access requirements, (ii) relocation or structural modification of the central computer facility, (iii) additions, deletions or changes to main frame, storage or input/output devices, (iv) system software changes impacting security protection features, (v) any change in clearance, declassification, audit trail or hardware/software maintenance procedures, and (vi) other system changes as determined by the cognizant security office."[11] A major component of assurance, life-cycle assurance, is concerned with testing ADP systems both in the development phase as well as during operation. DoD Directive 5215.1 (Section F.2.C.(2)) requires "evaluations of selected industry and government-developed trusted computer systems against these criteria."[10] 8.0 A GUIDELINE ON COVERT CHANNELS A covert channel is any communication channel that can be exploited by a process to transfer information in a manner that violates the system's security policy. There are two types of covert channels: storage channels and timing channels. Covert storage channels include all vehicles that would allow the direct or indirect writing of a storage location by one process and the direct or indirect reading of it by another. Covert timing channels include all vehicles that would allow one process to signal information to another process by modulating its own use of system resources in such a way that the change in response time observed by the second process would provide information. >From a security perspective, covert channels with low bandwidths represent a lower threat than those with high bandwidths. However, for many types of covert channels, techniques used to reduce the bandwidth below a certain rate (which depends on the specific channel mechanism and the system architecture) also have the effect of degrading the performance provided to legitimate system users. Hence, a trade-off between system performance and covert channel bandwidth must be made. Because of the threat of compromise that would be present in any multilevel computer system containing classified or sensitive information, such systems should not contain covert channels with high bandwidths. This guideline is intended to provide system developers with an idea of just how high a "high" covert channel bandwidth is. A covert channel bandwidth that exceeds a rate of one hundred (100) bits per second is considered "high" because 100 bits per second is the approximate rate at which many computer terminals are run. It does not seem appropriate to call a computer system "secure" if information can be compromised at a rate equal to the normal output rate of some commonly used device. In any multilevel computer system there are a number of relatively low-bandwidth covert channels whose existence is deeply ingrained in the system design. Faced with the large potential cost of reducing the bandwidths of such covert channels, it is felt that those with maximum bandwidths of less than one (1) bit per second are acceptable in most application environments. Though maintaining acceptable performance in some systems may make it impractical to eliminate all covert channels with bandwidths of 1 or more bits per second, it is possible to audit their use without adversely affecting system performance. This audit capability provides the system administration with a means of detecting -- and procedurally correcting -- significant compromise. Therefore, a Trusted Computing Base should provide, wherever possible, the capability to audit the use of covert channel mechanisms with bandwidths that may exceed a rate of one (1) bit in ten (10) seconds. The covert channel problem has been addressed by a number of authors. The interested reader is referred to references [5], [6], [19], [21], [22], [23], and [29]. 9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES The Mandatory Access Control requirement includes a capability to support an unspecified number of hierarchical classifications and an unspecified number of non-hierarchical categories at each hierarchical level. To encourage consistency and portability in the design and development of the National Security Establishment trusted computer systems, it is desirable for all such systems to be able to support a minimum number of levels and categories. The following suggestions are provided for this purpose: * The number of hierarchical classifications should be greater than or equal to eight (8). * The number of non-hierarchical categories should be greater than or equal to twenty-nine (29). 10.0 A GUIDELINE ON SECURITY TESTING These guidelines are provided to give an indication of the extent and sophistication of testing undertaken by the DoD Computer Security Center during the Formal Product Evaluation process. Organizations wishing to use "Department of Defense Trusted Computer System Evaluation Criteria" for performing their own evaluations may find this section useful for planning purposes. As in Part I, highlighting is used to indicate changes in the guidelines from the next lower division. 10.1 Testing for Division C 10.1.1 Personnel The security testing team shall consist of at least two individuals with bachelor degrees in Computer Science or the equivalent. Team members shall be able to follow test plans prepared by the system developer and suggest additions, shall be familiar with the "flaw hypothesis" or equivalent security testing methodology, and shall have assembly level programming experience. Before testing begins, the team members shall have functional knowledge of, and shall have completed the system developer's internals course for, the system being evaluated. 10.1.2 Testing The team shall have "hands-on" involvement in an independent run of the tests used by the system developer. The team shall independently design and implement at least five system-specific tests in an attempt to circumvent the security mechanisms of the system. The elapsed time devoted to testing shall be at least one month and need not exceed three months. There shall be no fewer than twenty hands-on hours spent carrying out system developer-defined tests and test team-defined tests. 10.2 Testing for Division B 10.2.1 Personnel The security testing team shall consist of at least two individuals with bachelor degrees in Computer Science or the equivalent and at least one individual with a master's degree in Computer Science or equivalent. Team members shall be able to follow test plans prepared by the system developer and suggest additions, shall be conversant with the "flaw hypothesis" or equivalent security testing methodology, shall be fluent in the TCB implementation language(s), and shall have assembly level programming experience. Before testing begins, the team members shall have functional knowledge of, and shall have completed the system developer's internals course for, the system being evaluated. At least one team member shall have previously completed a security test on another system. 10.2.2 Testing The team shall have "hands-on" involvement in an independent run of the test package used by the system developer to test security-relevant hardware and software. The team shall independently design and implement at least fifteen system- specific tests in an attempt to circumvent the security mechanisms of the system. The elapsed time devoted to testing shall be at least two months and need not exceed four months. There shall be no fewer than thirty hands-on hours per team member spent carrying out system developer-defined tests and test team-defined tests. 10.3 Testing for Division A 10.3.1 Personnel The security testing team shall consist of at least one individual with a bachelor's degree in Computer Science or the equivalent and at least two individuals with masters' degrees in Computer Science or equivalent. Team members shall be able to follow test plans prepared by the system developer and suggest additions, shall be conversant with the "flaw hypothesis" or equivalent security testing methodology, shall be fluent in the TCB implementation language(s), and shall have assembly level programming experience. Before testing begins, the team members shall have functional knowledge of, and shall have completed the system developer's internals course for, the system being evaluated. At least one team member shall be familiar enough with the system hardware to understand the maintenance diagnostic programs and supporting hardware documentation. At least two team members shall have previously completed a security test on another system. At least one team member shall have demonstrated system level programming competence on the system under test to a level of complexity equivalent to adding a device driver to the system. 10.3.2 Testing The team shall have "hands-on" involvement in an independent run of the test package used by the system developer to test security-relevant hardware and software. The team shall independently design and implement at least twenty-five system- specific tests in an attempt to circumvent the security mechanisms of the system. The elapsed time devoted to testing shall be at least three months and need not exceed six months. There shall be no fewer than fifty hands-on hours per team member spent carrying out system developer-defined tests and test team-defined tests. APPENDIX A Commercial Product Evaluation Process "Department of Defense Trusted Computer System Evaluation Criteria" forms the basis upon which the Computer Security Center will carry out the commercial computer security evaluation process. This process is focused on commercially produced and supported general-purpose operating system products that meet the needs of government departments and agencies. The formal evaluation is aimed at "off-the-shelf" commercially supported products and is completely divorced >from any consideration of overall system performance, potential applications, or particular processing environments. The evaluation provides a key input to a computer system security approval/accreditation. However, it does not constitute a complete computer system security evaluation. A complete study (e.g., as in reference [18]) must consider additional factors dealing with the system in its unique environment, such as it's proposed security mode of operation, specific users, applications, data sensitivity, physical and personnel security, administrative and procedural security, TEMPEST, and communications security. The product evaluation process carried out by the Computer Security Center has three distinct elements: * Preliminary Product Evaluation - An informal dialogue between a vendor and the Center in which technical information is exchanged to create a common understanding of the vendor's product, the criteria, and the rating that may be expected to result from a formal product evaluation. * Formal Product Evaluation - A formal evaluation, by the Center, of a product that is available to the DoD, and that results in that product and its assigned rating being placed on the Evaluated Products List. * Evaluated Products List - A list of products that have been subjected to formal product evaluation and their assigned ratings. PRELIMINARY PRODUCT EVALUATION Since it is generally very difficult to add effective security measures late in a product's life cycle, the Center is interested in working with system vendors in the early stages of product design. A preliminary product evaluation allows the Center to consult with computer vendors on computer security issues found in products that have not yet been formally announced. A preliminary evaluation is typically initiated by computer system vendors who are planning new computer products that feature security or major security-related upgrades to existing products. After an initial meeting between the vendor and the Center, appropriate non-disclosure agreements are executed that require the Center to maintain the confidentiality of any proprietary information disclosed to it. Technical exchange meetings follow in which the vendor provides details about the proposed product (particularly its internal designs and goals) and the Center provides expert feedback to the vendor on potential computer security strengths and weaknesses of the vendor's design choices, as well as relevant interpretation of the criteria. The preliminary evaluation is typically terminated when the product is completed and ready for field release by the vendor. Upon termination, the Center prepares a wrap-up report for the vendor and for internal distribution within the Center. Those reports containing proprietary information are not available to the public. During preliminary evaluation, the vendor is under no obligation to actually complete or market the potential product. The Center is, likewise, not committed to conduct a formal product evaluation. A preliminary evaluation may be terminated by either the Center or the vendor when one notifies the other, in writing, that it is no longer advantageous to continue the evaluation. FORMAL PRODUCT EVALUATION The formal product evaluation provides a key input to certification of a computer system for use in National Security Establishment applications and is the sole basis for a product being placed on the Evaluated Products List. A formal product evaluation begins with a request by a vendor for the Center to evaluate a product for which the product itself and accompanying documentation needed to meet the requirements defined by this publication are complete. Non-disclosure agreements are executed and a formal product evaluation team is formed by the Center. An initial meeting is then held with the vendor to work out the schedule for the formal evaluation. Since testing of the implemented product forms an important part of the evaluation process, access by the evaluation team to a working version of the system is negotiated with the vendor. Additional support required from the vendor includes complete design documentation, source code, and access to vendor personnel who can answer detailed questions about specific portions of the product. The evaluation team tests the product against each requirement, making any necessary interpretations of the criteria with respect to the product being evaluated. The evaluation team writes a two-part final report on their findings about the system. The first part is publicly available (containing no proprietary information) and contains the overall class rating assigned to the system and the details of the evaluation team's findings when comparing the product against the evaluation criteria. The second part of the evaluation report contains vulnerability analyses and other detailed information supporting the rating decision. Since this part may contain proprietary or other sensitive information it will be distributed only within the U.S. Government on a strict need-to-know and non- disclosure basis, and to the vendor. No portion of the evaluation results will be withheld from the vendor. APPENDIX B Summary of Evaluation Criteria Divisions The divisions of systems recognized under the trusted computer system evaluation criteria are as follows. Each division represents a major improvement in the overall confidence one can place in the system to protect classified and other sensitive information. Division (D): Minimal Protection This division contains only one class. It is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class. Division (C): Discretionary Protection Classes in this division provide for discretionary (need-to-know) protection and, through the inclusion of audit capabilities, for accountability of subjects and the actions they initiate. Division (B): Mandatory Protection The notion of a TCB that preserves the integrity of sensitivity labels and uses them to enforce a set of mandatory access control rules is a major requirement in this division. Systems in this division must carry the sensitivity labels with major data structures in the system. The system developer also provides the security policy model on which the TCB is based and furnishes a specification of the TCB. Evidence must be provided to demonstrate that the reference monitor concept has been implemented. Division (A): Verified Protection This division is characterized by the use of formal security verification methods to assure that the mandatory and discretionary security controls employed in the system can effectively protect classified or other sensitive information stored or processed by the system. Extensive documentation is required to demonstrate that the TCB meets the security requirements in all aspects of design, development and implementation. APPENDIX C Summary of Evaluation Criteria Classes The classes of systems recognized under the trusted computer system evaluation criteria are as follows. They are presented in the order of increasing desirablity from a computer security point of view. Class (D): Minimal Protection This class is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class. Class (C1): Discretionary Security Protection The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep other users from accidentally reading or destroying their data. The class (C1) environment is expected to be one of cooperating users processing data at the same level(s) of sensitivity. Class (C2): Controlled Access Protection Systems in this class enforce a more finely grained discretionary access control than (C1) systems, making users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation. Class (B1): Labeled Security Protection Class (B1) systems require all the features required for class (C2). In addition, an informal statement of the security policy model, data labeling, and mandatory access control over named subjects and objects must be present. The capability must exist for accurately labeling exported information. Any flaws identified by testing must be removed. Class (B2): Structured Protection In class (B2) systems, the TCB is based on a clearly defined and documented formal security policy model that requires the discretionary and mandatory access control enforcement found in class (B1) systems be extended to all subjects and objects in the ADP system. In addition, covert channels are addressed. The TCB must be carefully structured into protection-critical and non- protection-critical elements. The TCB interface is well-defined and the TCB design and implementation enable it to be subjected to more thorough testing and more complete review. Authentication mechanisms are strengthened, trusted facility management is provided in the form of support for system administrator and operator functions, and stringent configuration management controls are imposed. The system is relatively resistant to penetration. Class (B3): Security Domains The class (B3) TCB must satisfy the reference monitor requirements that it mediate all accesses of subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this end, the TCB is structured to exclude code not essential to security policy enforcement, with significant system engineering during TCB design and implementation directed toward minimizing its complexity. A security administrator is supported, audit mechanisms are expanded to signal security- relevant events, and system recovery procedures are required. The system is highly resistant to penetration. Class (A1): Verified Design Systems in class (A1) are functionally equivalent to those in class (B3) in that no additional architectural features or policy requirements are added. The distinguishing feature of systems in this class is the analysis derived >from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. In keeping with the extensive design and development analysis of the TCB required of systems in class (A1), more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported. APPENDIX D Requirement Directory This appendix lists requirements defined in "Department of Defense Trusted Computer System Evaluation Criteria" alphabetically rather than by class. It is provided to assist in following the evolution of a requirement through the classes. For each requirement, three types of criteria may be present. Each will be preceded by the word: NEW, CHANGE, or ADD to indicate the following: NEW: Any criteria appearing in a lower class are superseded by the criteria that follow. CHANGE: The criteria that follow have appeared in a lower class but are changed for this class. Highlighting is used to indicate the specific changes to previously stated criteria. ADD: The criteria that follow have not been required for any lower class, and are added in this class to the previously stated criteria for this requirement. Abbreviations are used as follows: NR: (No Requirement) This requirement is not included in this class. NAR: (No Additional Requirements) This requirement does not change from the previous class. The reader is referred to Part I of this document when placing new criteria for a requirement into the complete context for that class. Figure 1 provides a pictorial summary of the evolution of requirements through the classes. Audit C1: NR. C2: NEW: The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity. B1: CHANGE: For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object and the object's security level. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level. ADD: The TCB shall also be able to audit any override of human-readable output markings. B2: ADD: The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels. B3: ADD: The TCB shall contain a mechanism that is able to monitor the occurrence or accumulation of security auditable events that may indicate an imminent violation of security policy. This mechanism shall be able to immediately notify the security administrator when thresholds are exceeded. A1: NAR. Configuration Management C1: NR. C2: NR. B1: NR. B2: NEW: During development and maintenance of the TCB, a configuration management system shall be in place that maintains control of changes to the descriptive top-level specification, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. The configuration management system shall assure a consistent mapping among all documentation and code associated with the current version of the TCB. Tools shall be provided for generation of a new version of the TCB from source code. Also available shall be tools for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB. B3: NAR. A1: CHANGE: During the entire life-cycle, i.e., during the design, development, and maintenance of the TCB, a configuration management system shall be in place for all security-relevant hardware, firmware, and software that maintains control of changes to the formal model, the descriptive and formal top-level specifications, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. Also available shall be tools, maintained under strict configuration control, for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB. ADD: A combination of technical, physical, and procedural safeguards shall be used to protect from unauthorized modification or destruction the master copy or copies of all material used to generate the TCB. Covert Channel Analysis C1: NR. C2: NR. B1: NR. B2: NEW: The system developer shall conduct a thorough search for covert storage channels and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. (See the Covert Channels Guideline section.) B3: CHANGE: The system developer shall conduct a thorough search for covert channels and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. A1: ADD: Formal methods shall be used in the analysis. Design Documentation C1: NEW: Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described. C2: NAR. B1: ADD: An informal or formal description of the security policy model enforced by the TCB shall be available and an explanation provided to show that it is sufficient to enforce the security policy. The specific TCB protection mechanisms shall be identified and an explanation given to show that they satisfy the model. B2: CHANGE: The interfaces between the TCB modules shall be described. A formal description of the security policy model enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy. ADD: The descriptive top-level specification (DTLS) shall be shown to be an accurate description of the TCB interface. Documentation shall describe how the TCB implements the reference monitor concept and give an explanation why it is tamperproof, cannot be bypassed, and is correctly implemented. Documentation shall describe how the TCB is structured to facilitate testing and to enforce least privilege. This documentation shall also present the results of the covert channel analysis and the tradeoffs involved in restricting the channels. All auditable events that may be used in the exploitation of known covert storage channels shall be identified. The bandwidths of known covert storage channels, the use of which is not detectable by the auditing mechanisms, shall be provided. (See the Covert Channel Guideline section.) B3: ADD: The TCB implementation (i.e., in hardware, firmware, and software) shall be informally shown to be consistent with the DTLS. The elements of the DTLS shall be shown, using informal techniques, to correspond to the elements of the TCB. A1: CHANGE: The TCB implementation (i.e., in hardware, firmware, and software) shall be informally shown to be consistent with the formal top-level specification (FTLS). The elements of the FTLS shall be shown, using informal techniques, to correspond to the elements of the TCB. ADD: Hardware, firmware, and software mechanisms not dealt with in the FTLS but strictly internal to the TCB (e.g., mapping registers, direct memory access I/O) shall be clearly described.