There has been a fair amount of confusion about what is meant by "C2
compatibility". Windows NT has, for example, been tested and rated C2 compliant, but only under a very specific set of circumstances. However, simply because a system or system component is "C2 compliant" doesn't mean that it may be
considered completely secure under all conditions. Unfortunately, the "C2" label has come to be a catch-all designation appearing to encompass many security features which, in fact, it does not.
Using the above example as a starting point, Windows NT workstations are only C2 compliant when they are not connected to a multi-user system (network) of any kind and when they have their A: drives disconnected at the hardware level. There are a few other restrictions that, if violated, negate the C2 compliance.
The below discussion describes what is meant by C2 compliance. This is paraphrased from the Department of Defense "Orange Book", which is the authoritative document, and the National Computer Security Center's "Red Book"
which is the official network interpretation of the Orange book. Systems in this class make 'users individually accountable for their actions through login procedures, auditing of security-relevant events and resource isolation.' There are only four top level criteria for C2 systems:
1. Security Policy 2. Accountability
3. Assurance (operational and life cycle) 4. Documentation
2.15.0 C2 Criteria Simplified
Security Policy: Discretionary Access Control - The system defines and controls access between named users and named objects. The enforcement mechanism (self/group/public controls, access control lists, etc.) allows users to specify and control sharing of these objects by named individuals, groups or both and provides controls to limit propagation of access rights. Objects must be protected from unauthorized access either by explicit user action or default. The controls are capable of including or excluding access to the granularity of a single user.
Security Policy: Object Reuse - All authorizations to a storage object must be revoked prior to initial assignment, allocation or reallocation. No information including encrypted representations of information is available to any user that obtains access to an object that has been released back to the system.
Accountability: Identification and Authentication - All users must identify themselves before performing any other actions that the system is expected to mediate. Some protected mechanism such as passwords must be used to
authenticate the user's identity. The system must protect authentication data so that it cannot be accessed by any unauthorized user. The system must be able to enforce individual accountability by uniquely identifying each user and providing the capability of associating the identity with all auditable actions taken by the individual.
Accountability: Audit - The system must be able to create, maintain and protect from modification or unauthorized access or destruction an audit trail of access to the objects it protects. It must record the following types of events: use of
identification and authentication mechanism, introduction of objects into a user's address space, deletions of objects, actions taken by system administrators and security officers, and other security-relevant events. For each recorded event the system must record the date and time, user, type of event and success or failure of the event. If the event is the introduction of an object into the user's address space (such as file open or program execution) the name of the object must be included.
Operational Assurance: System Architecture - The system must maintain a domain for its own execution that protects it from external interference or tampering such as modification of its code or data structures. The system resources to be protected must be isolated and subject to access control and auditing requirements.
Operational Assurance: System Integrity - Hardware and/or software features must be provided to validate the correct operation of the system resources.
Life Cycle Assurance: Security Testing - The security mechanisms of the system must be tested and found to work as presented in system documentation. Testing must insure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the system. This must include a search for obvious flaws that would allow a violation of resource isolation or that would permit unauthorized access to the audit or authentication data.
Documentation: Security Features User's Guide - The protection mechanisms provided by the system, their use and how they interact with each other must be provided.
Documentation: Trusted Facility Manual - A manual addressed to the system administrator must present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining audit files as well as the detailed audit record structure for each type of audit event must be given.
Documentation: Test Documentation -The system developer must provide a document that describes the test plan and procedures that shows how the security mechanisms were tested and the results of the testing.
Documentation: Design Documentation - A document must be provided that describes the developer's philosophy of protection and how the philosophy was implemented in the system. If the system is modular, the interfaces between the modules must be described.
2.15.1 The Red Book
By extension, the Red Book applies the C2 standard criteria to the network
environment. The Red Book's purpose is to interpret the Orange Book's standalone
standards as the may be applied to a network. The Red Book places responsibility for the security of the network not on a manufacturer, but on the network's sponsor.
This differentiation acknowledges that a device, regardless of its Orange Book rating as delivered from the manufacturer, becomes a component of the multivendor network when it is interconnected. As such, it takes on some of the characteristics of the network, interacts with other components of the network and may have its own characteristics altered by these interactions. The manufacturer no longer
controls the security mechanisms of the device for these reasons. The Red Book places the system-wide responsibility with the network sponsor.
Policy - The Red Book defines two types of policy within the network environment:
Secrecy and Data Integrity. The document defines them as follows:
Secrecy Policy: The network sponsor shall define the form of the discretionary secrecy policy that is enforced in the network to prevent unauthorized users from reading the sensitive information entrusted to the network.
Data Integrity Policy: The network sponsor shall define the discretionary integrity policy to prevent unauthorized users from modifying, viz., writing, sensitive
information. The definition of data integrity presented by the network sponsor refers to the requirement that the information has not been subjected to unauthorized modification in the
network.
Accountability: Identification and Authentication - The requirement for
identification and authentication of users is the same for a network system as for an ADP system. The identification and authentication may be done by the component to which the user is directly connected or some other component, such as an identification and authentication server.
Accountability: Audit - This criterion applies as stated in the Orange Book.
Assurance: Architecture -The system architecture criterion must be met individually by all NTCB (Network Trusted Computing Base) partitions.
Implementation of the requirement that the NTCB maintain a domain for its own execution is achieved by having each NTCB partition maintain a domain for its own execution.
Assurance: Integrity - Implementation of the requirement is partly achieved by having hardware and/or software features that can be used to periodically validate the correct operation of the hardware and firmware elements of each component's NTCB partition. Features shall also be provided to validate the identity and correct operation of a component prior to its incorporation in the network system and throughout system operation.
Assurance: Security Testing - The testing of a security mechanism of the network system for meeting this criterion shall be an integrated testing procedure involving all components containing an NTCB partition that implement the given mechanism.
This integrated testing is additional to any individual component tests involved in the evaluation of the network system. The sponsor should identify the allowable set of configurations including the sizes of the networks.
Documentation - This user documentation describes user visible protection mechanisms at the global (network system) level and at the user interface of each component, and the interaction among these. The Trusted Facility Manual contains