DoD STANDARD 5200.28: SUMMARY OF THE DIFFERENCES BETWEEN IT AND CSC-STD-001-83 Note: Text which has been added or changed is indented and preceded by > sign. Text which has been deleted is enclosed in slashes (/). "Computer Security Center" was changed to "National Computer Security Center" throughout the document. The FOREWORD Section was rewritten and signed by Mr. Don Latham on 26 Dec 85. The ACKNOWLEDGEMENTS Section was updated. The PREFACE was changed as follows: PREFACE The trusted computer system evaluation criteria defined in this document classify systems into four broad hierarchical divisions of enhanced security protection. The criteria 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 system >components can be completely untrusted. Though the criteria are >intended to be application-independent, /it is recognized that/ 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. The SCOPE Section was changed as follows: Scope The trusted computer system evaluation criteria defined in this document apply >primarily to /both/ trusted, commercially available automatic data processing (ADP) systems. >They are also applicable, as amplified below, to the >evaluation of existing systems and to the specification of >security requirements for ADP systems acquisition. Included are two distinct sets of requirements: l) 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. Changed the Purpose Section as follows: Purpose As outlined in the Preface, the criteria have been developed to serve a number of intended purposes: To provide >a standard to manufacturers as to what security features to build into their new and planned, ... trust requirements >(with particular emphasis on preventing the >disclosure of data) for sensitive applications. To provide >DoD components with a metric with which to evaluate the degree of trust that can be placed in ... To provide a basis for specifying security requirements in acquisition specifications. With respect to the >second purpose for development of the criteria, i.e., providing >DoD components with a security evaluation metric, evaluations can be delineated into two types: (a) an evaluation can be performed on a computer product from a perspective that excludes the application environment; or, (b) it can be done to assess whether appropriate security measures ... 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. 2.1.4.3 Test Documentation The system developer will 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. Changed Section 2.2.1.1 as follows: 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. Completely Reworded Section 2.2.1.2 as follows: 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. Reworded Section 2.2.2.2 as follows: 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 of objects into a user's address space (e.g., file open, program initiation), deletion of objects, 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. Changed Section 2.2.4.3 as follows: 2.2.4.3 Test Documentation The system developer will 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. Changed Section 3.1.1.1 as follows: 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. Completely reworded Section 3.1.1.2 as follows: 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. Changed Section 3.1.1.3.2 as follows: 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 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 /current/ security level or levels associated with a /single-level/ communication channel or I/O device. Appended a sentence to Section 3.1.1.4 as follows: 3.1.1.4 Mandatory Access Control ... 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. Changed one sentence in Section 3.1.2.1 as follows: 3.1.2.1. Identification and Authentication ... This data shall be used by the TCB to authenticate the user's identity and /to determine/ >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. Reworded Section 3.1.2.2 as follows: 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, 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. 'Unbolded' the first sentence of Section 3.1.3.2.1. Reworded Section 3.1.3.2.2 as follows: 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. Changed sentence as follows: 3.1.4.3 Test Documentation The system developer will 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. Changed Section 3.2.1.1 as follows: 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. Completely reworded Section 3.2.1.2 as follows: 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. Changed Section 3.2.1.3 as follows: 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. Changed Section 3.2.1.3.2 as follows: 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 /current/ security level or levels associated with a /single-level/ communication channel or I/O device. Appended Sectence to Section 3.2.1.4 as follows: 3.2.1.4 Mandatory Access Control ... 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. Changed Section 3.2.2.1 as follows: 3.2.2.1 Identification and Authentication ... This data shall be used by the TCB to authenticate the user's identity and /to determine/ >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. Reworded section 3.2.2.2 as follows: 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, 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. Changed Section 3.2.3.2.2 as follows: 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. Changed Section 3.2.4.3 as follows: 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. Replaced "tamperproof" with "tamper resistant": 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.) Changed Section 3.3.1.1 as follows: 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. Completely reworded Section 3.3.1.2 as follows: 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 subject's actions is to be available to any subject that obtains access to an object that has been released back to the system. Changed Section 3.3.1.3 as follows: 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. Changed Section 3.3.1.3.2 as follows: 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 /current/ security level or levels associated with a /single-level/ communication channel or I/O device. Appended Sentence to Section 3.3.1.4 as follows: 3.3.1.4 Mandatory Access Control ... 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. Changed Section 3.3.2.1 as follows: 3.3.2.1 Identification and Authentication ... This data shall be used by the TCB to authenticate the user's identity and /to determine/ >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. Changed Section 3.3.2.2 as follows: 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, 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. Changed the first sentence of Section 3.3.3.2.2 as follows: 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. ... Changed Section 3.3.4.3 as follows: 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. Replaced "tamperproof" with "tamper resistant" in Section 3.3.4.4. Changed Section 4.1.1.1 as follows: 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. Completely reworded Section 4.1.1.2 as follows: 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. Changed Section 4.1.1.3 as follows: 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. Changed Section 4.1.1.3.2 as follows: 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 /current/ security level >or levels associated with a /single-level/ communication channel or I/O device. Appended Sentence to Section 4.1.1.4 as follows: 4.1.1.4 Mandatory Access Control ... 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. Changed Section 4.1.2.1 as follows: 4.1.2.1 Identification and Authentication ... This data shall be used by the TCB to authenticate the user's identity and /to determine/ >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. Changed Section 4.1.2.2 as follows: 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, 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. 'Unbolded' the words "covert channels" in Section 4.1.3.1.3. Changed the first sentence of Section 4.1.3.2.2 as follows: 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. ... Changed Section 4.1.4.3 as follows: 4.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. It shall include results of testing the effectiveness of the methods used to reduce covert channel bandwidths. The results of the mapping between the formal top-level specification and the TCB source code shall be given. Replaced "tamperproof" with "tamper resistant" in Section 4.1.4.4. Changed the last paragraph of Section 5.1 as follows: 5.1 A Need for Consensus A major goal of ... As described ... >The Purpose of this section is to describe in detail the >fundamental control objectives. These objectives lay the >foundation for the requirements outlined in the criteria. The goal is to explain the foundations so that those outside the National Security Establishment can assess their universality and, by extension, the universal applicability of the criteria requirements to processing all types of sensitive applications whether they be for National Security or the private sector. Changed the second paragraph of Section 6.2 as follows: 6.2 A Formal Policy Model Following the publication of ... >A subject can act on behalf of a user or another >subject. The subject is created as a surrogate >for the cleared user and is assigned a formal >security level based on their classification. >The state transitions and invariants of the formal >policy model define the invariant relationships >that must hold between the clearance of the user, >the formal security level of any process that can >act on the user's behalf, and the formal security >level of the devices and other objects to which any >process can obtain specific modes of access. The Bell and LaPadula model, >for example, defines a relationship between >formal security levels of subjects and objects, now referenced as the "dominance relation." From this definition ... ... Both the Simple Security Condition and the *-Property include mandatory security provisions based on the dominance relation between the >formal security levels of subjects and objects. The Discretionary Security Property ... Added a sentence to the end of Section 7.0: 7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA Section 1 presents fundamental computer security requirements and Section 5 presents the control objectives for Trusted Computer Systems. They are general requirements, useful and necessary, for the development of all secure systems. However, when designing systems that will be used to process classified or other sensitive information, functional requirements for meeting the Control Objectives become more specific. There is a large body of policy laid down in the form of Regulations, Directives, Presidential Executive Orders, and OMB Circulars that form the basis of the procedures for the handling and processing of Federal information in general and classified information specifically. This section presents pertinent excerpts from these policy statements and discusses their relationship to the Control Objectives. >These excerpts are examples to illustrate the relationship >of the policies to criteria and may not be complete. Inserted the following >as the next to last paragraph of Section 7.2: >DoD Directive 5200.28 provides the security requirements for >ADP systems. For some types of information, such as >Sensitive Compartmented Information (SCI), DoD Directive >5200.28 states that other minimum security requirements also >apply. These minima are found in DCID 1/16 (new reference >number 5) which is implemented in DIAM 50-4 (new reference >number 6) for DoD and DoD contractor ADP systems. From requirements imposed by ... Changed Footnote #1 referenced by Section 7.2 as follows: Replaced "Health and Human Services Department" with "U.S. Information Agency." Changed (updated) the quote from DoD 5220.22-M, Section 7.3.1, as follows: 7.3 Criteria Control Objective for Security Policy 7.3.1 Marking The control objective for marking ... DoD 5220.22-M, "Industrial Security ... >"a. General. Classification designation by physical >marking, notation or other means serves to warn and to >inform the holder what degree of protection against >unauthorized disclosure is required for that >information or material." (14) Changed the >last paragraph of Section 7.5 as follows: A major component of assurance, life-cycle assurance, >as described in DoD Directive 7920.1, is concerned with testing ADP systems both in the development phase as well as during operation. >(17) DoD Directive 5215.1 ... Changed Section 9.0 as follows: 9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES The Mandatory Access Control requirement ... * The number of hierarchical classifications should be greater than or equal to >sixteen (16). * The number of non-hierarchical categories should be greater than or equal to >sixty-four (64).. Completely reworded the third paragraph of Formal Product Evaluation, in Appendix A, as follows: Formal Product Evaluation The formal product evaluation provides ... A formal product evaluation begins with ... >The evaluation team writes a final report on their findings about >the system. The report is publicly available (containing no >proprietary or sensitive information) and contains the overall >class rating assigned to the system and the details of the >evaluation team's findings when comparing the product against the >evaluation criteria. Detailed information concerning >vulnerabilities found by the evaluation team is furnished to the >system developers and designers as each is found so that the >vendor has a chance to eliminate as many of them as possible >prior to the completion of the Formal Product Evaluation. >Vulnerability analyses and other proprietary or sensitive >information are controlled within the Center through the >Vulnerability Reporting Program and are distributed only within >the U.S. Government on a strict need-to-know and non-disclosure >basis, and to the vendor. Changed two paragraphs in Audit (Appendix D) as follows: C2: NEW: The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, actions taken by computer operators and system administrators and/or system security officers, >and other security relevant events. or 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. B3: ADD: ...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. Changed one paragraph in Design Documentation (Appendix D): B2: ADD: Change "tamperproof" to "tamper resistant." Changed two paragraphs in Design Specification and Verification: B1: NEW: 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. B2: CHANGE: 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. Changed two paragraphs in Discretionary Access Control as follows: C2: CHANGE: 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. B3: CHANGE: 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. 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. Changed 1 paragraph in Exportation of Labeled Information: B1: NEW: 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 /current/ security level >or levels associated with a /single-level/ communication channel or I/O device. Changed 1 paragraph in Identification and Authorization: B1: CHANGE: ... 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. Changed 1 paragraph in Labels: B2: CHANGE: ... (e.g., subject, storage object, ROM) ... Changed 1 paragraph in Mandatory Access Control: B1: NEW: ... 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 authoriza- >tion of that user. Rewrote 1 paragraph in Object Reuse: C2: NEW: >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. Changed l paragraph in Test Documentation: C1: NEW: 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. GLOSSARY Changed Discretionary Access Control: Discretionary Access Control - A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control). Added: Front-End Security Filter - A process that is invoked to process data according to a specified security policy prior to releasing the data outside the processing environment or upon receiving data from an external source. Granularity - The relative fineness or coarseness by which a mechanism can be adjusted. The phrase "the granularity of a single user" means the access control mechanism can be adjusted to include or exclude any single user. Read-Only Memory (ROM) - A storage area in which the contents can be read but not altered during normal computer processing. Security Relevant Event - Any event that attempts to change the security state of the system, (e.g., change discretionary access controls, change the security level of the subject, change user password, etc.). Also, any event that attempts to violate the security policy of the system, (e.g., too many attempts to login, attempts to violate the mandatory access control limits of a device, attempts to downgrade a file, etc.). Changed the name of the term: Simple Security /Property/ >Condition - A Bell-LaPadula security model rule allowing a subject read access to an object only if the security level of the subject dominates the security level of the object. Changed definition: Trusted Computing Base (TCB) - The totality of protection mechanisms within a computer system --including hardware, firmware, and software -- the combination of which is responsible for enforcing a security policy. >A TCB consists of one or more components that together enforce >a unified security policy over a product or system. The ability of a TCB to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user's clearance) related to the security policy. REFERENCES Added: (References were renumbered as necessary) 5. DCID 1/16, Security of Foreign Intelligence in Automated Data Processing Systems and Networks (U), 4 January 1983. 6. DIAM 50-4, Security of Compartmented Computer Operations (U), 24 June 1980. 9. DoD Directive 5000.29, Management of Computer Resources in Major Defense Systems, 26 April 1976. 17. DoD Directive 7920.1, Life Cycle Management of Automated Information Systems (AIS), 17 October 1978. Corrected dates on the following References: 14. DoD 5220.22-M, Industrial Security Manual for Safeguarding Classified Information, March 1984. 15. DoD 5220.22-R, Industrial Security Regulation, February 1984.