The provisions of this document apply to the Office of the Secretary of Defense (ASD), the Military Departments, the Organization of the Joint Chiefs of Staff, the Unified and Specified Commands, the Defense Agencies and activities administratively supported by OSD (hereafter called "DoD Components").
This publication is effective immediately and is mandatory for use by all DoD Components in carrying out ADP system technical security evaluation activities applicable to the processing and storage of classified and other sensitive DoD information and applications as set forth herein.
Recommendations for revisions to this publication are encouraged and will be reviewed biannually by the National Computer Security Center through a formal review process. Address all proposals for revision through appropriate channels to: National Computer Security Center, Attention: Chief, Computer Security Standards.
DoD Components may obtain copies of this publication through their own publications channels. Other federal agencies and the public may obtain copies from: Office of Standards and Products, National Computer Security Center, Fort Meade, MD 20755-6000, Attention: Chief, Computer Security Standards.
_________________________________
Donald C. Latham Assistant Secretary of Defense (Command, Control, Communications, and Intelligence)
Acknowledgment is also given for the contributions of: Grace Hammonds and Peter S. Tasker, the MITRE Corp., Daniel J. Edwards, NCSC, Roger R. Schell, former Deputy Director of NCSC, Marvin Schaefer, NCSC, and Theodore M. P. Lee, Sperry Corp., who as original architects formulated and articulated the technical issues and solutions presented in this document; Jeff Makey, formerly NCSC, Warren F. Shadle, NCSC, and Carole S. Jordan, NCSC, who assisted in the preparation of this document; James P. Anderson, James P. Anderson & Co., Steven B. Lipner, Digital Equipment Corp., Clark Weissman, System Development Corp., LTC Lawrence A. Noble, formerly U.S. Air Force, Stephen T. Walker, formerly DoD, Eugene V. Epperly, DoD, and James E. Studer, formerly Dept. of the Army, who gave generously of their time and expertise in the review and critique of this document; and finally, thanks are given to the computer industry and others interested in trusted computing for their enthusiastic advice and assistance throughout this effort.
The trusted computer system evaluation criteria defined in this document classify systems into four broad hierarchical divisions of enhanced security protection. They provide a basis for the evaluation of effectiveness of security controls built into automatic data processing system products. The criteria were developed with three objectives in mind: (a) to provide users with a yardstick with which to assess the degree of trust that can be placed in computer systems for the secure processing of classified or other sensitive information; (b) to provide guidance to manufacturers as to what to build into their new, widely-available trusted commercial products in order to satisfy trust requirements for sensitive applications; and (c) to provide a basis for specifying security requirements in acquisition specifications. Two types of requirements are delineated for secure processing: (a) specific security feature requirements and (b) assurance requirements. Some of the latter requirements enable evaluation personnel to determine if the required features are present and functioning as intended. The scope of these criteria is to be applied to the set of components comprising a trusted system, and is not necessarily to be applied to each system component individually. Hence, some components of a system may be completely untrusted, while others may be individually evaluated to a lower or higher evaluation class than the trusted product considered as a whole system. In trusted products at the high end of the range, the strength of the reference monitor is such that most of the components can be completely untrusted. Though the criteria are intended to be application-independent, the specific security feature requirements may have to be interpreted when applying the criteria to specific systems with their own functional requirements, applications or special environments (e.g., communications processors, process control computers, and embedded systems in general). The underlying assurance requirements can be applied across the entire spectrum of ADP system or application processing environments without special interpretation.
INTRODUCTION
Historical Perspective
In October 1967, a task force was assembled under the auspices of the Defense Science Board to address computer security safeguards that would protect classified information in remote-access, resource-sharing computer systems. The Task Force report, "Security Controls for Computer Systems," published in February 1970, made a number of policy and technical recommendations on actions to be taken to reduce the threat of compromise of classified information processed on remote-access computer systems.[34] Department of Defense Directive 5200.28 and its accompanying manual DoD 5200.28-M, published in 1972 and 1973 respectively, responded to one of these recommendations by establishing uniform DoD policy, security requirements, administrative controls, and technical measures to protect classified information processed by DoD computer systems.[8;9] Research and development work undertaken by the Air Force, Advanced Research Projects Agency, and other defense agencies in the early and mid 70's developed and demonstrated solution approaches for the technical problems associated with controlling the flow of information in resource and information sharing computer systems.[1] The DoD Computer Security Initiative was started in 1977 under the auspices of the Under Secretary of Defense for Research and Engineering to focus DoD efforts addressing computer security issues.[33]
Concurrent with DoD efforts to address computer security issues, work was begun under the leadership of the National Bureau of Standards (NBS) to define problems and solutions for building, evaluating, and auditing secure computer systems.[17] As part of this work NBS held two invitational workshops on the subject of audit and evaluation of computer security.[20;28] The first was held in March 1977, and the second in November of 1978. One of the products of the second workshop was a definitive paper on the problems related to providing criteria for the evaluation of technical computer security effectiveness.[20] As an outgrowth of recommendations from this report, and in support of the DoD Computer Security Initiative, the MITRE Corporation began work on a set of computer security evaluation criteria that could be used to assess the degree of trust one could place in a computer system to protect classified data.[24;25;31] The preliminary concepts for computer security evaluation were defined and expanded upon at invitational workshops and symposia whose participants represented computer security expertise drawn from industry and academia in addition to the government. Their work has since been subjected to much peer review and constructive technical criticism from the DoD, industrial research and development organizations, universities, and computer manufacturers.
The DoD Computer Security Center (the Center) was formed in January 1981 to staff and expand on the work started by the DoD Computer Security Initiative.[15] A major goal of the Center as given in its DoD Charter is to encourage the widespread availability of trusted computer systems for use by those who process classified or other sensitive information.[10] The criteria presented in this document have evolved from the earlier NBS and MITRE evaluation material.
Scope
The trusted computer system evaluation criteria defined in this document apply primarily to trusted commercially available automatic data processing (ADP) systems. They are also applicable, as amplified below, the the evaluation of existing systems and to the specification of security requirements for ADP systems acquisition. Included are two distinct sets of requirements: 1) specific security feature requirements; and 2) assurance requirements. The specific feature requirements encompass the capabilities typically found in information processing systems employing general-purpose operating systems that are distinct from the applications programs being supported. However, specific security feature requirements may also apply to specific systems with their own functional requirements, applications or special environments (e.g., communications processors, process control computers, and embedded systems in general). The assurance requirements, on the other hand, apply to systems that cover the full range of computing environments from dedicated controllers to full range multilevel secure resource sharing systems.
Purpose
As outlined in the Preface, the criteria have been developedto serve a number of intended purposes:
The latter type of evaluation, i.e., those done for the purpose of assessing a system's security attributes with respect to a specific operational mission, is known as a certification evaluation. It must be understood that the completion of a formal product evaluation does not constitute certification or accreditation for the system to be used in any specific application environment. On the contrary, the evaluation report only provides a trusted computer system's evaluation rating along with supporting data describing the product system's strengths and weaknesses from a computer security point of view. 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 classified information.[8;9] Designated Approving Authorities (DAAs) remain ultimately responsible for specifying security of systems they accredit.
The trusted computer system evaluation criteria will be used directly and indirectly in the certification process. Along with applicable policy, it 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 Commercial Product Evaluation, reports from that process will be used as input to the certification evaluation. Technical data will be furnished to designers, evaluators and the Designated Approving Authorities to support their needs for making decisions.
Fundamental Computer Security Requirements
Any discussion of computer security necessarily starts from a statement of requirements, i.e., what it really means to call a computer system "secure." In general, secure systems will control, through use of specific security features, access to information such that only properly authorized individuals, or processes operating on their behalf, will have access to read, write, create, or delete information. Six fundamental requirements are derived from this basic statement of objective: four deal with what needs to be provided to control access to information; and two deal with how one can obtain credible assurances that this is accomplished in a trusted computer system.
Policy
Requirement 1 - SECURITY POLICY - There must be an explicit and well-defined security policy enforced by the system. Given identified subjects and objects, there must be a set of rules that are used by the system to determine whether a given subject can be permitted to gain access to a specific object. Computer systems of interest must enforce a mandatory security policy that can effectively implement access rules for handling sensitive (e.g., classified) information.[7] These rules include requirements such as: No person lacking proper personnel security clearance shall obtain access to classified information. In addition, discretionary security controls are required to ensure that only selected users or groups of users may obtain access to data (e.g., based on a need-to-know).
Requirement 2 - MARKING - Access control labels must be associated with objects. In order to control access to information stored in a computer, according to the rules of a mandatory security policy, it must be possible to mark every object with a label that reliably identifies the object's sensitivity level (e.g., classification), and/or the modes of access accorded those subjects who may potentially access the object.
Accountability
Requirement 3 - IDENTIFICATION - Individual subjects must be identified. Each access to information must be mediated based on who is accessing the information and what classes of information they are authorized to deal with. This identification and authorization information must be securely maintained by the computer system and be associated with every active element that performs some security-relevant action in the system.
Requirement 4 - ACCOUNTABILITY - Audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party. A trusted system must be able to record the occurrences of security-relevant events in an audit log. The capability to select the audit events to be recorded is necessary to minimize the expense of auditing and to allow efficient analysis. Audit data must be protected from modification and unauthorized destruction to permit detection and after-the-fact investigations of security violations.
Assurance
Requirement 5 - ASSURANCE - The computer system must contain hardware/software mechanisms that can be independently evaluated to provide sufficient assurance that the system enforces requirements 1 through 4 above. In order to assure that the four requirements of Security Policy, Marking, Identification, and Accountability are enforced by a computer system, there must be some identified and unified collection of hardware and software controls that perform those functions. These mechanisms are typically embedded in the operating system and are designed to carry out the assigned tasks in a secure manner. The basis for trusting such system mechanisms in their operational setting must be clearly documented such that it is possible to independently examine the evidence to evaluate their sufficiency.
Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that enforce these basic requirements must be continuously protected against tampering and/or unauthorized changes. No computer system can be considered truly secure if the basic hardware and software mechanisms that enforce the security policy are themselves subject to unauthorized modification or subversion. The continuous protection requirement has direct implications throughout the computer system's life-cycle.
These fundamental requirements form the basis for the individual evaluation criteria applicable for each evaluation division and class. The interested reader is referred to Section 5 of this document, "Control Objectives for Trusted Computer Systems," for a more complete discussion and further amplification of these fundamental requirements as they apply to general-purpose information processing systems and to Section 7 for amplification of the relationship between Policy and these requirements.
Structure of the Document
The remainder of this document is divided into two parts, four appendices, and a glossary. Part I (Sections 1 through 4) presents the detailed criteria derived from the fundamental requirements described above and relevant to the rationale and policy excerpts contained in Part II.
Part II (Sections 5 through 10) provides a discussion of basic objectives, rationale, and national policy behind the development of the criteria, and guidelines for developers pertaining to: mandatory access control rules implementation, the covert channel problem, and security testing. It is divided into six sections. Section 5 discusses the use of control objectives in general and presents the three basic control objectives of the criteria. Section 6 provides the theoretical basis behind the criteria. Section 7 gives excerpts from pertinent regulations, directives, OMB Circulars, and Executive Orders which provide the basis for many trust requirements for processing nationally sensitive and classified information with computer systems. Section 8 provides guidance to system developers on expectations in dealing with the covert channel problem. Section 9 provides guidelines dealing with mandatory security. Section 10 provides guidelines for security testing. There are four appendices, including a description of the Trusted Computer System Commercial Products Evaluation Process (Appendix A), summaries of the evaluation divisions (Appendix B) and classes (Appendix C), and finally a directory of requirements ordered alphabetically. In addition, there is a glossary.
Structure of the Criteria
The criteria are divided into four divisions: D, C, B, and A ordered in a hierarchical manner with the highest division (A) being reserved for systems providing the most comprehensive security. Each division represents a major improvement in the overall confidence one can place in the system for the protection of sensitive information. Within divisions C and B there are a number of subdivisions known as classes. The classes are also ordered in a hierarchical manner with systems representative of division C and lower classes of division B being characterized by the set of computer security mechanisms that they possess. Assurance of correct and complete design and implementation for these systems is gained mostly through testing of the security- relevant portions of the system. The security-relevant portions of a system are referred to throughout this document as the Trusted Computing Base (TCB). Systems representative of higher classes in division B and division A derive their security attributes more from their design and implementation structure. Increased assurance that the required features are operative, correct, and tamperproof under all circumstances is gained through progressively more rigorous analysis during the design process.
Within each class, four major sets of criteria are addressed. The first three represent features necessary to satisfy the broad control objectives of Security Policy, Accountability, and Assurance that are discussed in Part II, Section 5. The fourth set, Documentation, describes the type of written evidence in the form of user guides, manuals, and the test and design documentation required for each class.
A reader using this publication for the first time may find it helpful to first read Part II, before continuing on with Part I.
1.0 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.
2.0 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.
2.1 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. The following are minimal requirements for systems assigned a class (C1) rating:
2.1.1 Security Policy
2.1.1.1 Discretionary Access Control
The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals or defined groups or both.
2.1.2 Accountability
2.1.2.1 Identification and Authentication
The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user.
2.1.3 Assurance
2.1.3.1 Operational Assurance
2.1.3.1.1 System Architecture
The TCB shall maintain a domain for its own execution protects it from external interference or tampering (e.g., by modification of its code or data strucutres). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system.
2.1.3.1.2 System Integrity
Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB.
2.1.3.2 Life-Cycle Assurance
2.1.3.2.1 Security Testing
The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. (See the Security Testing Guidelines.)
2.1.4 Documentation
2.1.4.1 Security Features User's Guide
A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another.
2.1.4.2 Trusted Facility Manual
A manual addressed to the ADP System Administrator shall present cautions about functions and privileges that should be controlled when running a secure facility.
2.1.4.3 Test Documentation
The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the the security mechanisms were tested, and results of the security mechanisms' functional testing.
2.1.4.4 Design Documentation
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.
2.2 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. The following are minimal requirements for systems assigned a class (C2) rating:
2.2.1 Security Policy
2.2.1.1 Discretionary Access Control
The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users.
2.2.1.2 Object Reuse
All authorizations to the information contained within a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system.
2.2.2 Accountability
2.2.2.1 Identification and Authentication
The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual.
2.2.2.2 Audit
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 or 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, and other security relevant events. 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.
2.2.3 Assurance
2.2.3.1 Operational Assurance
2.2.3.1.1 System Architecture
The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements.
2.2.3.1.2 System Integrity
Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB.
2.2.3.2 Life-Cycle Assurance
2.2.3.2.1 Security Testing
The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. Testing shall also include a search for obvious flaws that would allow violation of resource isolation, or that would permit unauthorized access to the audit or authentication data. (See the Security Testing guidelines.)
2.2.4 Documentation
2.2.4.1 Security Features User's Guide
A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another.
2.2.4.2 Trusted Facility Manual
A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given.
2.2.4.3 Test Documentation
The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the security mechanisms were tested, and results of the security mechanisms' functional testing.
2.2.4.4 Design Documentation
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.
3.0 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.
3.1 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. The following are minimal
requirements for systems assigned a class (B1) rating:
3.1.1 Security Policy
3.1.1.1 Discretionary Access Control
The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users.
3.1.1.2 Object Reuse
All authorizations to the information contained within a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system.
3.1.1.3 Labels
Sensitivity labels associated with each subject and storage object under its control (e.g., process, file, segment, device) shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non-labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB.
3.1.1.3.1 Label Integrity
Sensitivity labels shall accurately represent security levels of the specific subjects or objects with which they are associated. When exported by the TCB, sensitivity labels shall accurately and unambiguously represent the internal labels and shall be associated with the information being exported.
3.1.1.3.2 Exportation of Labeled Information
The TCB shall designate each communication channel and I/O device as either single-level or miltilevel. Any change in this designation shall be done manually and shall be auditable by the TCB. The TCB shall maintain and be able to audit any change in the security level or levels associated with a communication channel or I/O device.
3.1.1.3.2.1 Exportation to Multilevel Devices
When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that object shall also be exported and shall reside on the same physical medium as the exported information and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports or imports an object over a multilevel communication channel, the protocol used on that channel shall provide for the unambiguous pairing between the sensitivity labels and the associated information that is sent or received.
3.1.1.3.2.2 Exportation to Single-Level Devices
Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. However, the TCB shall include a mechanism by which the TCb and an authorized user reliably communicate to designate the single security level of information imported or exported via single-level communication channels or I/O devices.
3.1.1.3.2.3 Labeling Human-Readable Output
The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the sensitivity of the output. The TCB shall, be default, mark the top and bottom of each page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the overall sensitivity of the output or that properly* represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other forms of human- readable output (e.g., maps, graphics) with human- readable sensitivity labels that properly* represent the sensitivity of the touput. Any override of these marking defaults shall be auditable by the TCB.
* The hierarchical classification component in human-readable sensitivity labels shall be equal to the greatest hierarchical classification or any of the information in the output that the labels refer to; the non-hierarchical category component shall include all of the non-hierarchical categories of the information in the output the labels refer to, but no other non-hierarchical categories.
3.1.1.4 Mandatory Access Control
The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its control (e.g., processes, files, segments, devices). These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control Guidelines.) The following requirements shall hold for all accesses between subjects and objects controlled by the TCB: a subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non- hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level. Identification and authentication data shall be used by the TCB to authenti- cate the user's identity and to ensure that the security level and authorization 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.
3.1.2 Accountability
3.1.2.1 Identification and Authentication
The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations or individual users. This data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorizations 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. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual.
3.1.2.2 Audit
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 and other security relevant events. The TCB shall also be able to audit any override of human-readable output markings. 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 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.
3.1.3 Assurance
3.1.3.1 Operational Assurance
3.1.3.1.1 System Architecture
The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. The TCB shall maintain process isolation through the provision of distinct address spaces under its control. The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements.
3.1.3.1.2 System Integrity
Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB.
3.1.3.2 Life-Cycle Assurance
3.1.3.2.1 Security Testing
The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. A team of individuals who thoroughly understand the specific implementation of the TCB shall subject its design documentation, source code, and object code to thorough analysis and testing. Their objectives shall be: to uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users. All discovered flaws shall be removed or neutralized and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. (See the Security Testing Guidelines.)
3.1.3.2.2 Design Specification and Verification
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.
3.1.4 Documentation
3.1.4.1 Security Features User's Guide
A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another.
3.1.4.2 Trusted Facility Manual
A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given. The manual shall describe the operator and administrator functions related to security, to include changing the security characteristics of a user. It shall provide guidelines on the consistent and effective use of the protection features of the system, how they interact, how to securely generate a new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner.
3.1.4.3 Test Documentation
The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the security mechanisms were tested, and results of the security mechanisms' functional testing.
3.1.4.4 Design Documentation
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. 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.
3.2 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. The
following are minimal requirements for systems assigned a class (B2) rating:
3.2.1 Security Policy
3.2.1.1 Discretionary Access Control
The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both, and shall provide controls to limit propagation of access rights. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users.
3.2.1.2 Object Reuse
All authorizations to the information contained within a storage object shall be revoked prior to initial assignment, allocation or reallocation to a subject from the TCB's pool of unused storage objects. No information, including encrypted representations of information, produced by a prior subject's actions is to be available to any subject that obtains access to an object that has been released back to the system.
3.2.1.3 Labels
Sensitivity labels associated with each ADP system resource (e.g., subject, storage object, ROM) that is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non-labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB.
3.2.1.3.1 Label Integrity
Sensitivity labels shall accurately represent security levels of the specific subjects or objects with which they are associated. When exported by the TCB, sensitivity labels shall accurately and unambiguously represent the internal labels and shall be associated with the information being exported.
3.2.1.3.2 Exportation of Labeled Information
The TCB shall designate each communication channel and I/O device as either single-level or multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB. The TCB shall maintain and be able to audit any change in the security level or levels associated with a communication channel or I/O device.
3.2.1.3.2.1 Exportation to Multilevel Devices
When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that object shall also be exported and shall reside on the same physical medium as the exported information and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports or imports an object over a multilevel communication channel, the protocol used on that channel shall provide for the unambiguous pairing between the sensitivity labels and the associated information that is sent or received.
3.2.1.3.2.2 Exportation to Single-Level Devices
Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. However, the TCB shall include a mechanism by which the TCB and an authorized user reliably communicate to designate the single security level of information imported or exported via single-level communication channels or I/O devices.
3.2.1.3.2.3 Labeling Human-Readable Output
The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the overall sensitivity of the output or that properly* represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these marking defaults shall be auditable by the TCB.
3.2.1.3.3 Subject Sensitivity Labels
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 label.
3.2.1.3.4 Device Labels
The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the physical environments in which the devices are located.
3.2.1.4 Mandatory Access Control
The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage objects, and I/O devices that are directly or indirectly accessible by subjects external to the TCB. These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses between All subjects external to the TCB and all objects directly or indirectly accessible by these subjects: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non- hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level. Identification and authentication data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorization 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.
3.2.2 Accountability
3.2.2.1 Identification and Authentication
The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the user's identity and to ensure that the security level and authorizations 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. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual.
3.2.2.1.1 Trusted Path
The TCB shall support a trusted communication path between itself and user for initial login and authentication. Communications via this path shall be initiated exclusively by a user.
3.2.2.2 Audit
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, and other security relevant events. The TCB shall also be able to audit any override of human-readable output markings. 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 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. The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels.
3.2.3 Assurance
3.2.3.1 Operational Assurance
3.2.3.1.1 System Architecture
The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). The TCB shall maintain process isolation through the provision of distinct address spaces under its control. The TCB shall be internally structured into well-defined largely independent modules. It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not. The TCB modules shall be designed such that the principle of least privilege is enforced. Features in hardware, such as segmentation, shall be used to support logically distinct storage objects with separate attributes (namely: readable, writeable). The user interface to the TCB shall be completely defined and all elements of the TCB identified.
3.2.3.1.2 System Integrity
Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB.
3.2.3.1.3 Covert Channel Analysis
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.)
3.2.3.1.4 Trusted Facility Management
The TCB shall support separate operator and administrator functions.
3.2.3.2 Life-Cycle Assurance
3.2.3.2.1 Security Testing
The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. A team of individuals who thoroughly understand the specific implementation of the TCB shall subject its design documentation, source code, and object code to thorough analysis and testing. Their objectives shall be: to uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users. The TCB shall be found relatively resistant to penetration. All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB implementation is consistent with the descriptive top-level specification. (See the Security Testing Guidelines.)
3.2.3.2.2 Design Specification and Verification
A formal model of the security policy supported by the TCB shall be maintained over the life cycle of the ADP system that is proven consistent with its axioms. 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. It shall be shown to be an accurate description of the TCB interface.
3.2.3.2.3 Configuration Management
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 versionof 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.
3.2.4 Documentation
3.2.4.1 Security Features User's Guide
A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another.
3.2.4.2 Trusted Facility Manual
A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given. The manual shall describe the operator and administrator functions related to security, to include changing the security characteristics of a user. It shall provide guidelines on the consistent and effective use of the protection features of the system, how they interact, how to securely generate a new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner. The TCB modules that contain the reference validation mechanism shall be identified. The procedures for secure generation of a new TCB from source after modification of any modules in the TCB shall be described.
3.2.4.3 Test Documentation
The system developer shall provide to the evaluators a document that describes the test plan, test procedures that show how the security mechanisms were tested, and results of the security mechanisms' functional testing. It shall include results of testing the effectiveness of the methods used to reduce covert channel bandwidths.
3.2.4.4 Design Documentation
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. 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. The specific TCB protection
mechanisms shall be identified and an explanation given to show
that they satisfy the model. 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 tamper resistant, 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.)
3.1.1 Security Policy
3.3.1.1 Discretionary Access Control
The TCB shall define and control access between named users and
named objects (e.g., files and programs) in the ADP system.
The enforcement mechanism (e.g., access control lists) shall
allow users to specify and control sharing of those objects,
and shall provide controls to limit propagation of access
rights. The discretionary access control mechanism shall,
either by explicit user action or by default, provide that
objects are protected from unauthorized access. These access
controls shall be capable of specifying, for each named object,
a list of named individuals and a list of groups of named
individuals with their respective modes of access to that
object. Furthermore, for each such named object, it shall be
possible to specify a list of named individuals and a list of
groups of named individuals for which no access to the object is
to be given. Access permission to an object by users not
already possessing access permission shall only be assigned by
authorized users.
3.3.1.2 Object Reuse
All authorizations to the information contained within a
storage object shall be revoked prior to initial assignment,
allocation or reallocation to a subject from the TCB's pool
of unused storage objects. No information, including
encrypted representations of information, produced by a prior
subjects actions is to be available to any subject that obtains
access to an object that has been released back to the system.
3.3.1.3 Labels
Sensitivity labels associated with each ADP system resource
(e.g., subject, storage object, ROM) that is directly or
indirectly accessible by subjects external to the TCB shall be
maintained by the TCB. These labels shall be used as the basis
for mandatory access control decisions. In order to import
non-labeled data, the TCB shall request and receive from an
authorized user the security level of the data, and all such
actions shall be auditable by the TCB.
3.3.1.3.1 Label Integrity
Sensitivity labels shall accurately represent security
levels of the specific subjects or objects with which
they are associated. When exported by the TCB,
sensitivity labels shall accurately and unambiguously
represent the internal labels and shall be associated
with the information being exported.
3.3.1.3.2 Exportation of Labeled Information
The TCB shall designate each communication channel and
I/O device as either single-level or multilevel. Any
change in this designation shall be done manually and
shall be auditable by the TCB. The TCB shall maintain
and be able to audit any change in the security level
or levels associated with a communication channel or
I/O device.
3.3.1.3.2.1 Exportation to Multilevel Devices
When the TCB exports an object to a multilevel I/O
device, the sensitivity label associated with that
object shall also be exported and shall reside on
the same physical medium as the exported
information and shall be in the same form (i.e.,
machine-readable or human-readable form). When
the TCB exports or imports an object over a
multilevel communication channel, the protocol
used on that channel shall provide for the
unambiguous pairing between the sensitivity labels
and the associated information that is sent or
received.
3.3.1.3.2.2 Exportation to Single-Level Devices
Single-level I/O devices and single-level
communication channels are not required to
maintain the sensitivity labels of the information
they process. However, the TCB shall include a
mechanism by which the TCB and an authorized user
reliably communicate to designate the single
security level of information imported or exported
via single-level communication channels or I/O
devices.
3.3.1.3.2.3 Labeling Human-Readable Output
The ADP system administrator shall be able to
specify the printable label names associated with
exported sensitivity labels. The TCB shall mark
the beginning and end of all human-readable, paged,
hardcopy output (e.g., line printer output) with
human-readable sensitivity labels that properly*
represent the sensitivity of the output. The TCB
shall, by default, mark the top and bottom of each
page of human-readable, paged, hardcopy output
(e.g., line printer output) with human-readable
sensitivity labels that properly* represent the
overall sensitivity of the output or that
properly* represent the sensitivity of the
information on the page. The TCB shall, by
default and in an appropriate manner, mark other
forms of human-readable output (e.g., maps,
graphics) with human-readable sensitivity labels
that properly* represent the sensitivity of the
output. Any override of these marking defaults
shall be auditable by the TCB.
3.3.1.3.3 Subject Sensitivity Labels
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 label.
3.3.1.3.4 Device Labels
The TCB shall support the assignment of minimum and
maximum security levels to all attached physical devices.
These security levels shall be used by the TCB to enforce
constraints imposed by the physical environments in which
the devices are located.
______________________________
3.3.1.4 Mandatory Access Control
The TCB shall enforce a mandatory access control policy over
all resources (i.e., subjects, storage objects, and I/O
devices) that are directly or indirectly accessible by subjects
external to the TCB. These subjects and objects shall be
assigned sensitivity labels that are a combination of
hierarchical classification levels and non-hierarchical
categories, and the labels shall be used as the basis for
mandatory access control decisions. The TCB shall be able to
support two or more such security levels. (See the Mandatory
Access Control guidelines.) The following requirements shall
hold for all accesses between all subjects external to the TCB
and all objects directly or indirectly accessible by these
subjects: A subject can read an object only if the hierarchical
classification in the subject's security level is greater than
or equal to the hierarchical classification in the object's
security level and the non-hierarchical categories in the
subject's security level include all the non-hierarchical
categories in the object's security level. A subject can write
an object only if the hierarchical classification in the
subject's security level is less than or equal to the
hierarchical classification in the object's security level and
all the non-hierarchical categories in the subject's security
level are included in the non- hierarchical categories in the
object's security level. Identification and authentication
data shall be used by the TCB to authenticate the user's
identity and to ensure that the security level and authori-
zation 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.
3.3.2 Accountability
3.3.2.1 Identification and Authentication
The TCB shall require users to identify themselves to it before
beginning to perform any other actions that the TCB is expected
to mediate. Furthermore, the TCB shall maintain authentication
data that includes information for verifying the identity of
individual users (e.g., passwords) as well as information for
determining the clearance and authorizations of individual
users. This data shall be used by the TCB to authenticate the
user's identity and to ensure that the security level and
authorizations 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. The TCB shall
protect authentication data so that it cannot be accessed by any
unauthorized user. The TCB shall be able to enforce individual
accountability by providing the capability to uniquely identify
each individual ADP system user. The TCB shall also provide the
capability of associating this identity with all auditable
actions taken by that individual.
3.3.2.1.1 Trusted Path
The TCB shall support a trusted communication path
between itself and users for use when a positive TCB-to-
user connection is required (e.g., login, change subject
security level). Communications via this trusted path
shall be activated exclusively by a user of the TCB and
shall be logically isolated and unmistakably
distinguishable from other paths.
3.3.2.2 Audit
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 and other security relevant events. The TCB shall also
be able to audit any override of human-readable output markings.
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 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. The TCB shall
be able to audit the identified events that may be used in the
exploitation of covert storage channels. 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, and if the occurrence or accumulation
of these security relevant events continues, the system shall
take the least disruptive action to terminate the event.
3.3.3 Assurance
3.3.3.1 Operational Assurance
3.3.3.1.1 System Architecture
The TCB shall maintain a domain for its own execution
that protects it from external interference or tampering
(e.g., by modification of its code or data structures).
The TCB shall maintain process isolation through the
provision of distinct address spaces under its control.
The TCB shall be internally structured into well-defined
largely independent modules. It shall make effective use
of available hardware to separate those elements that are
protection-critical from those that are not. The TCB
modules shall be designed such that the principle of
least privilege is enforced. Features in hardware, such
as segmentation, shall be used to support logically
distinct storage objects with separate attributes (namely:
readable, writeable). The user interface to the TCB shall
be completely defined and all elements of the TCB
identified. The TCB shall be designed and structured to
use a complete, conceptually simple protection mechanism
with precisely defined semantics. This mechanism shall
play a central role in enforcing the internal structuring
of the TCB and the system. The TCB shall incorporate
significant use of layering, abstraction and data hiding.
Significant system engineering shall be directed toward
minimizing the complexity of the TCB and excluding from
the TCB modules that are not protection-critical.
3.3.3.1.2 System Integrity
Hardware and/or software features shall be provided that
can be used to periodically validate the correct
operation of the on-site hardware and firmware elements
of the TCB.
3.3.3.1.3 Covert Channel Analysis
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. (See the
Covert Channels Guideline section.)
3.3.3.1.4 Trusted Facility Management
The TCB shall support separate operator and administrator
functions. The functions performed in the role of a
security administrator shall be identified. The ADP
system administrative personnel shall only be able to
perform security administrator functions after taking a
distinct auditable action to assume the security
administrator role on the ADP system. Non-security
functions that can be performed in the security
administration role shall be limited strictly to those
essential to performing the security role effectively.
3.3.3.1.5 Trusted Recovery
Procedures and/or mechanisms shall be provided to assure
that, after an ADP system failure or other discontinuity,
recovery without a protection compromise is obtained.
3.3.3.2 Life-Cycle Assurance
3.3.3.2.1 Security Testing
The security mechanisms of the ADP system shall be tested
and found to work as claimed in the system documentation.
A team of individuals who thoroughly understand the
specific implementation of the TCB shall subject its
design documentation, source code, and object code to
thorough analysis and testing. Their objectives shall
be: to uncover all design and implementation flaws that
would permit a subject external to the TCB to read,
change, or delete data normally denied under the
mandatory or discretionary security policy enforced by
the TCB; as well as to assure that no subject (without
authorization to do so) is able to cause the TCB to enter
a state such that it is unable to respond to
communications initiated by other users. The TCB shall
be found resistant to penetration. All discovered flaws
shall be corrected and the TCB retested to demonstrate
that they have been eliminated and that new flaws have
not been introduced. Testing shall demonstrate that the
TCB implementation is consistent with the descriptive
top-level specification. (See the Security Testing
Guidelines.) No design flaws and no more than a few
correctable implementation flaws may be found during
testing and there shall be reasonable confidence that
few remain.
3.3.3.2.2 Design Specification and Verification
A formal model of the security policy supported by the
TCB shall be maintained over the life cycle of the ADP
system that is proven consistent with its axioms. 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. It shall be shown to be an accurate
description of the TCB interface. A convincing argument
shall be given that the DTLS is consistent with the model.
3.3.3.2.3 Configuration Management
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.
3.3.4 Documentation
3.3.4.1 Security Features User's Guide
A single summary, chapter, or manual in user documentation
shall describe the protection mechanisms provided by the TCB,
guidelines on their use, and how they interact with one another.
3.3.4.2 Trusted Facility Manual
A manual addressed to the ADP system administrator shall
present cautions about functions and privileges that should be
controlled when running a secure facility. The procedures for
examining and maintaining the audit files as well as the
detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and
administrator functions related to security, to include
changing the security characteristics of a user. It shall
provide guidelines on the consistent and effective use of the
protection features of the system, how they interact, how to
securely generate a new TCB, and facility procedures, warnings,
and privileges that need to be controlled in order to operate
the facility in a secure manner. The TCB modules that contain
the reference validation mechanism shall be identified. The
procedures for secure generation of a new TCB from source after
modification of any modules in the TCB shall be described. It
shall include the procedures to ensure that the system is
initially started in a secure manner. Procedures shall also be
included to resume secure system operation after any lapse in
system operation.
3.3.4.3 Test Documentation
The system developer shall provide to the evaluators a document
that describes the test plan, test procedures that show how the
security mechanisms were tested, and results of the security
mechanisms' functional testing. It shall include results of
testing the effectiveness of the methods used to reduce covert
channel bandwidths.
3.3.4.4 Design Documentation
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. 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. The specific TCB protection
mechanisms shall be identified and an explanation given to show
that they satisfy the model. 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 tamper resistant, cannot be bypassed,
and is correctly implemented. 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. 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.)
4.1 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.
Independent of the particular specification language or verification system
used, there are five important criteria for class (A1) design verification:
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.
The following are minimal requirements for systems assigned a class (A1)
rating:
4.1.1 Security Policy
4.1.1.1 Discretionary Access Control
The TCB shall define and control access between named users and
named objects (e.g., files and programs) in the ADP system.
The enforcement mechanism (e.g., access control lists) shall
allow users to specify and control sharing of those objects,
and shall provide controls to limit propagation of access
rights. The discretionary access control mechanism shall,
either by explicit user action or by default, provide that
objects are protected from unauthorized access. These access
controls shall be capable of specifying, for each named object,
a list of named individuals and a list of groups of named
individuals with their respective modes of access to that
object. Furthermore, for each such named object, it shall be
possible to specify a list of named individuals and a list of
groups of named individuals for which no access to the object is
to be given. Access permission to an object by users not
already possessing access permission shall only be assigned by
authorized users.
4.1.1.2 Object Reuse
All authorizations to the information contained within a
storage object shall be revoked prior to initial assignment,
allocation or reallocation to a subject from the TCB's pool
of unused storage objects. No information, including encrypted
representations of information, produced by a prior subject's
actions is to be available to any subject that obtains access
to an object that has been released back to the system.
4.1.1.3 Labels
Sensitivity labels associated with each ADP system resource
(e.g., subject, storage object, ROM) that is directly or
indirectly accessible by subjects external to the TCB shall be
maintained by the TCB. These labels shall be used as the basis
for mandatory access control decisions. In order to import
non-labeled data, the TCB shall request and receive from an
authorized user the security level of the data, and all such
actions shall be auditable by the TCB.
4.1.1.3.1 Label Integrity
Sensitivity labels shall accurately represent security
levels of the specific subjects or objects with which
they are associated. When exported by the TCB,
sensitivity labels shall accurately and unambiguously
represent the internal labels and shall be associated
with the information being exported.
4.1.1.3.2 Exportation of Labeled Information
The TCB shall designate each communication channel and
I/O device as either single-level or multilevel. Any
change in this designation shall be done manually and
shall be auditable by the TCB. The TCB shall maintain
and be able to audit any change in the security level
or levels associated with a communication channel or
I/O device.
4.1.1.3.2.1 Exportation to Multilevel Devices
When the TCB exports an object to a multilevel I/O
device, the sensitivity label associated with that
object shall also be exported and shall reside on
the same physical medium as the exported
information and shall be in the same form (i.e.,
machine-readable or human-readable form). When
the TCB exports or imports an object over a
multilevel communication channel, the protocol
used on that channel shall provide for the
unambiguous pairing between the sensitivity labels
and the associated information that is sent or
received.
4.1.1.3.2.2 Exportation to Single-Level Devices
Single-level I/O devices and single-level
communication channels are not required to
maintain the sensitivity labels of the information
they process. However, the TCB shall include a
mechanism by which the TCB and an authorized user
reliably communicate to designate the single
security level of information imported or exported
via single-level communication channels or I/O
devices.
4.1.1.3.2.3 Labeling Human-Readable Output
The ADP system administrator shall be able to
specify the printable label names associated with
exported sensitivity labels. The TCB shall mark
the beginning and end of all human-readable, paged,
hardcopy output (e.g., line printer output) with
human-readable sensitivity labels that properly*
represent the sensitivity of the output. The TCB
shall, by default, mark the top and bottom of each
page of human-readable, paged, hardcopy output
(e.g., line printer output) with human-readable
sensitivity labels that properly* represent the
overall sensitivity of the output or that
properly* represent the sensitivity of the
information on the page. The TCB shall, by
default and in an appropriate manner, mark other
forms of human-readable output (e.g., maps,
graphics) with human-readable sensitivity labels
that properly* represent the sensitivity of the
output. Any override of these marking defaults
shall be auditable by the TCB.
4.1.1.3.3 Subject Sensitivity Labels
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 label.
4.1.1.3.4 Device Labels
The TCB shall support the assignment of minimum and
maximum security levels to all attached physical devices.
These security levels shall be used by the TCB to enforce
constraints imposed by the physical environments in which
the devices are located.
______________________________
4.1.1.4 Mandatory Access Control
The TCB shall enforce a mandatory access control policy over
all resources (i.e., subjects, storage objects, and I/O
devices) that are directly or indirectly accessible by subjects
external to the TCB. These subjects and objects shall be
assigned sensitivity labels that are a combination of
hierarchical classification levels and non-hierarchical
categories, and the labels shall be used as the basis for
mandatory access control decisions. The TCB shall be able to
support two or more such security levels. (See the Mandatory
Access Control guidelines.) The following requirements shall
hold for all accesses between all subjects external to the TCB
and all objects directly or indirectly accessible by these
subjects: A subject can read an object only if the hierarchical
classification in the subject's security level is greater than
or equal to the hierarchical classification in the object's
security level and the non-hierarchical categories in the
subject's security level include all the non-hierarchical
categories in the object's security level. A subject can write
an object only if the hierarchical classification in the
subject's security level is less than or equal to the
hierarchical classification in the object's security level and
all the non-hierarchical categories in the subject's security
level are included in the non- hierarchical categories in the
object's security level. Identification and authentication
data shall be used by the TCB to authenticate the user's
identity and to ensure that the security level and authoriza-
tion 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.
4.1.2 Accountability
4.1.2.1 Identification and Authentication
The TCB shall require users to identify themselves to it before
beginning to perform any other actions that the TCB is expected
to mediate. Furthermore, the TCB shall maintain authentication
data that includes information for verifying the identity of
individual users (e.g., passwords) as well as information for
determining the clearance and authorizations of individual
users. This data shall be used by the TCB to authenticate the
user's identity and to ensure that the security level and
authorizations 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. The TCB shall
protect authentication data so that it cannot be accessed by any
unauthorized user. The TCB shall be able to enforce individual
accountability by providing the capability to uniquely identify
each individual ADP system user. The TCB shall also provide the
capability of associating this identity with all auditable
actions taken by that individual.
4.1.2.1.1 Trusted Path
The TCB shall support a trusted communication path
between itself and users for use when a positive TCB-to-
user connection is required (e.g., login, change subject
security level). Communications via this trusted path
shall be activated exclusively by a user or the TCB and
shall be logically isolated and unmistakably
distinguishable from other paths.
4.1.2.2 Audit
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, and other security relevant events. The TCB shall
also be able to audit any override of human-readable output
markings. 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 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. The TCB shall be able to audit the identified
events that may be used in the exploitation of covert storage
channels. 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, and, if
the occurrence or accumulation of these security relevant
events continues, the system shall take the least disruptive
action to terminate the event.
4.1.3 Assurance
4.1.3.1 Operational Assurance
4.1.3.1.1 System Architecture
The TCB shall maintain a domain for its own execution
that protects it from external interference or tampering
(e.g., by modification of its code or data structures).
The TCB shall maintain process isolation through the
provision of distinct address spaces under its control.
The TCB shall be internally structured into well-defined
largely independent modules. It shall make effective use
of available hardware to separate those elements that are
protection-critical from those that are not. The TCB
modules shall be designed such that the principle of
least privilege is enforced. Features in hardware, such
as segmentation, shall be used to support logically
distinct storage objects with separate attributes (namely:
readable, writeable). The user interface to the TCB
shall be completely defined and all elements of the TCB
identified. The TCB shall be designed and structured to
use a complete, conceptually simple protection mechanism
with precisely defined semantics. This mechanism shall
play a central role in enforcing the internal structuring
of the TCB and the system. The TCB shall incorporate
significant use of layering, abstraction and data hiding.
Significant system engineering shall be directed toward
minimizing the complexity of the TCB and excluding from
the TCB modules that are not protection-critical.
4.1.3.1.2 System Integrity
Hardware and/or software features shall be provided that
can be used to periodically validate the correct
operation of the on-site hardware and firmware elements
of the TCB.
4.1.3.1.3 Covert Channel Analysis
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. (See the
Covert Channels Guideline section.) Formal methods shall
be used in the analysis.
4.1.3.1.4 Trusted Facility Management
The TCB shall support separate operator and administrator
functions. The functions performed in the role of a
security administrator shall be identified. The ADP
system administrative personnel shall only be able to
perform security administrator functions after taking a
distinct auditable action to assume the security
administrator role on the ADP system. Non-security
functions that can be performed in the security
administration role shall be limited strictly to those
essential to performing the security role effectively.
4.1.3.1.5 Trusted Recovery
Procedures and/or mechanisms shall be provided to assure
that, after an ADP system failure or other discontinuity,
recovery without a protection compromise is obtained.
4.1.3.2 Life-Cycle Assurance
4.1.3.2.1 Security Testing
The security mechanisms of the ADP system shall be tested
and found to work as claimed in the system documentation.
A team of individuals who thoroughly understand the
specific implementation of the TCB shall subject its
design documentation, source code, and object code to
thorough analysis and testing. Their objectives shall
be: to uncover all design and implementation flaws that
would permit a subject external to the TCB to read,
change, or delete data normally denied under the
mandatory or discretionary security policy enforced by
the TCB; as well as to assure that no subject (without
authorization to do so) is able to cause the TCB to enter
a state such that it is unable to respond to
communications initiated by other users. The TCB shall
be found resistant to penetration. All discovered flaws
shall be corrected and the TCB retested to demonstrate
that they have been eliminated and that new flaws have
not been introduced. Testing shall demonstrate that the
TCB implementation is consistent with the formal top-
level specification. (See the Security Testing
Guidelines.) No design flaws and no more than a few
correctable implementation flaws may be found during
testing and there shall be reasonable confidence that few
remain. Manual or other mapping of the FTLS to the
source code may form a basis for penetration testing.
4.1.3.2.2 Design Specification and Verification
A formal model of the security policy supported by the
TCB shall be maintained over the life-cycle of the ADP
system that is proven consistent with its axioms. 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. 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.
The DTLS and FTLS shall include those components of the
TCB that are implemented as hardware and/or firmware if
their properties are visible at the TCB interface. The
FTLS shall be shown to be an accurate description of the
TCB interface. A convincing argument shall be given that
the DTLS is consistent with the model and a combination of
formal and informal techniques shall be used to show that
the FTLS is consistent with the model. This verification
evidence shall be consistent with that provided within the
state-of-the-art of the particular computer security
center-endorsed formal 3.3 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. The following are minimal requirements for systems assigned a
class (B3) rating:
* The hierarchical classification component in human-readable sensitivity
labels shall be equal to the greatest hierarchical classification of any of the
information in the output that the labels refer to; the non-hierarchical
category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical
categories.4.0 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.
* The hierarchical classification component in human-readable sensitivity
labels shall be equal to the greatest hierarchical classification of any of the
information in the output that the labels refer to; the non-hierarchical
category component shall include all of the non-hierarchical categories of the
information in the output the labels refer to, but no other non-hierarchical
categories.