Section C.3. Summary of Orange Book Classes

C.3. Summary of Orange Book Classes

The following sections summarize very briefly the high points of each of the Orange Book evaluation classes described in this appendix. (See Figure C-1.)

Figure C-1. Comparison of evaluation classes

C.3.1. D Systems: Minimal Security

According to the Orange Book, division D "is reserved for systems that have been evaluated but that fail to meet the requirements for a higher evaluation class." The Orange Book listed no requirements for division D. It's simply a catch-all category for systems that don't provide the security features offered by systems more highly rated.

In fact, there are no evaluated systems in this class; a vendor wouldn't go to the trouble of getting a system evaluated if it didn't offer a reasonable set of security features. It's likely that the most basic personal computer systems would fall into the division D category if they were evaluated.

C.3.2. C1 Systems: Discretionary Security Protection

C1 systems provide rather limited security features. The Orange Book described C1 systems as an environment of "cooperating users processing data at the same level(s) of security." At this level, security features are intended primarily to keep users from making honest mistakes that could damage the system (e.g., by writing over system memory or critical software) or could interfere with other users' work (by deleting or modifying their programs or data). The security features of a C1 system aren't sufficient to keep a determined intruder out.

The two main user-visible features required in the C1 class are:

Passwords (or some other mechanism)

These identify and authenticate a user before letting him use the system.

Discretionary protection of files and other objects

With systems of this kind, you can protect your own files by deciding who will be allowed to access them.

C1 systems must also provide a system architecture that can protect system code from tampering by user programs. The system must be tested to ensure that it works properly and that the security features can't be bypassed in any obvious way. There are also specific documentation requirements. Many people feel that if an ordinary Unix or Linux system (with no enhanced security features) were submitted for evaluation, it would be given a C1 rating. (Others claim that it would get a C2 rating.)

C.3.3. C2 Systems: Controlled Access Protection

C2 systems provide much more stringent security than C1 systems. In addition to providing all the features required at the C1 level, C2 systems offer the following additional user-visible features:

Accountability of individual users

Through individual password controls and auditing (maintaining a record of every security-related action every user performs), the system can keep track of who's doing what in the system.

More detailed discretionary controls

The Orange Book describes C2 requirements as follows: "These access controls shall be capable of including or excluding to the granularity of a single user." Through access control lists or some other mechanism, you must be able to specify, for example, that only Mary and Joe can read a file and that only Sam can change it.

Object reuse

This feature makes sure that any data left in memory, on disk, or anywhere else in the system doesn't accidentally become accessible to a user.

The C2 system architecture must allow system resources to be protected via access control features. C2 systems also require more rigorous testing and documentation.

C.3.4. B1 Systems: Labeled Security Protection

B1 (and higher) systems support mandatory access controls. In a MAC system, every file (and other major object) in the system must be labeled. The system uses these sensitivity labels, and the security levels of the system's users, to enforce the system's security policy. In MAC systems, protection of files is no longer discretionary. You can't give another user access to one of your files unless that user has the necessary clearance to the file. The Orange Book imposed many specific labeling requirements on B1 systems, including labeling of all information that's exported from the system.

B1 systems must have a system architecture that more rigorously separates the security-related portions of the system from those that are not security-related. B1 systems also require more stringent testing and documentation. In the B1 class, your documentation must include a model of the security policy supported by the system. This policy need not be a mathematical one (as is required in the higher classes), but it must be a clear statement of the rules enforced by the system's security features.

C.3.5. B2 Systems: Structured Protection

B2 and higher systems don't actually add many more specific user-visible security features to the set already required of B1 systems. Instead, they extend these features, and they require additional assurance that the features were designed and work properly.

In the B2 class, labeling features are extended to include all objects in the system, including devices. B2 systems also add a trusted path feature, allowing the user to communicate with the system in a direct and unmistakable wayfor example, by pressing a certain key or interacting with a certain menu. The system design must offer proof that an intruder can't interfere with, or "spoof," this direct channel.

B2 systems support least privilege, the concept that users and programs should possess the least number of privileges they need, and for the shortest time necessary, to perform system functions. This concept is implemented via a combination of design, implementation, and assurance requirements. One example is the requirement that there be a separate system administrator and operator.

From a system design point of view, B2 systems require substantially more modularity and use of hardware features to isolate security-related functions from those that are not security-related. B2 systems also require a formal, mathematical statement of the system's security policy, as well as more stringent testing and documentation. They also require that a configuration management system manage all changes to the system code and documentation and that system designers conduct a search for covert channelssecret ways that a developer could use the system to reveal information.

Few systems have been successfully evaluated at B2 and higher.

C.3.6. B3 Systems: Security Domains

There are no requirements for new user-visible features at the B3 level, but the system design and assurance features are substantially more rigorous. Trusted facility management (assignment of a specific individual as security administrator) is required, as is trusted recovery (procedures ensuring that security doesn't fail if the system does) and the ability to signal the administrator immediately if the system detects an "imminent violation of security policy."

The Orange Book indicated that B3 systems must be "highly resistant to penetration." The TCB is very tightly structured to exclude code not required for the enforcement of system security.

B3 systems aren't very common. It's difficult enough to obtain a B3 rating that vendors may choose to go all the way for an A1 rating.

C.3.7. A1 Systems: Verified Design

At present, A1 systems are at the top of the security heap, although the Orange Book does discuss the possibility of defining requirements for systems that exceed current A1 requirements in areas of system architecture, testing, and formal verification.

A1 systems are pretty much functionally equivalent to B3 systems. The only actual feature provided by A1 systems beyond B3 requirements is trusted distribution, which enforces security while a trusted system is being shipped to a customer. What makes a system an A1 system is the additional assurance that's offered by the formal analysis and mathematical proof that the system design matches the system's security policy and its design specifications.

Only two or three systems ever received an A1 rating.

C.3.8. Complaints About the Orange Book

Not everyone thought the Orange Book answered all needs, and it tended to be government-specific. Some respected security practitioners disagreed with the government's reliance on this book alone as a way of measuring trust. Here are some of the main claims about the inadequacies of the Orange Book.

• The Orange Book model worked only in a government-classified environment, and the higher levels of security weren't appropriate for the protection of commercial data, where data integrity rather than confidentially was the chief concern.

• The Orange Book emphasized protection from unauthorized access, while most security attacks actually involve insiders. (Orange Book defenders pointed out that the book's principle of least privilege addressed this issue to some degree.)

• The Orange Book did not address networking issues, although the Red Book did.

• The Orange Book contained a relatively small number of security ratings.

In addition, there was a need to harmonize the computer security requirements with those of nations with which there was a likelihood of joint military and commercial operations. The European Information Technology Security Evaluation Criteria (ITSEC) was similar to U.S. TCSEC, of which the Orange Book was central. A merger of the two was in order. It came to be known as the Common Criteria.