Section C.1. About the Orange Book

C.1. About the Orange Book

The Orange Book defined four broad hierarchical divisions of security protection. In increasing order of trust, they were:

D:

Minimal security

C:

Discretionary protection

B:

Mandatory protection

A:

Verified protection

Each division consisted of one or more numbered classes, with higher numbers indicating a greater degree of security. For example, division C contained two distinct classes (C2 offered more security than C1); division B contained three classes (B3 offers more security than B2, which offered more security than B1). Each class was defined by a specific set of criteria that a system must meet to be awarded a rating in that class.

Why Was There an Orange Book?

What was the purpose of the Orange Book? According to the book itself, the evaluation criteria were developed with three basic objectives:

Measurement

To provide users with a metric 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. For example, a user can rely on a B2 system to be "more secure" than a C2 system.

Guidance

To provide guidance to manufacturers as to what to build into their trusted commercial products to satisfy trust requirements for sensitive applications.

Acquisition

To provide a basis for specifying security requirements in acquisition specifications. Rather than specifying a hodge-podge of security requirements, and having vendors respond in piecemeal fashion, the Orange Book provides a clear way of specifying a coordinated set of security functions. A customer can be confident that the system she acquires has already been checked out for the needed degree of security.

As the Orange Book put it, the criteria "constitute a uniform set of basic requirements and evaluation classes for assessing the effectiveness of security controls built into . . . systems."

These philosophical underpinnings echo through the international replacement for the Orange Book, the Common Criteria.

C.1.1. Orange Book Security Concepts

The Orange Book criteria had four pillars:

• Security policy

• Accountability

• Assurance

• Documentation

C.1.1.1. Security policy

A security policy is the set of rules and practices that regulate how an organization manages, protects, and distributes sensitive information. It's the framework in which a system provides trust.

A security policy is typically stated in terms of subjects and objects. A subject is something active in the system; examples of subjects are users, processes, and programs. An object is something that a subject acts upon; examples of objects are files, directories, devices, sockets, and windows.

The Orange Book defined a security policy as follows:

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.

At the lower levels of security, a security policy could be informal, and the Orange Book did not even require that it be written. For B1 systems and above, the Orange Book required a written security policy. At the higher levels, the security policy became increasingly formal and had to be expressed in mathematically precise notation.

A security model is usually required to give life to the security policy. The Orange Book criteria were based on the state-machine model developed by David Bell and Leonard LaPadula in 1973 under the sponsorship of the U.S. Air Force Electronic Systems Division (ESD). The Bell and LaPadula model was also the first mathematical model of a multilevel secure computer system. This involved the concept of a security lattice, which is now seen in most other security models. The difference between various models today often boils down to what subjects can access which objects from what level of the lattice.

C.1.1.2. Accountability

Accountability requirements defined in the Orange Book centered on the idea that a system must identify all users and use that information to decide whether the user could legitimately access information. The system was also required to keep track of any security-related actions taken in the system. There was also a requirement that the system produce audit reports, if required, so that system access and usage could be examined.

Generally, the requirements increased in rigor as the trust classification increased. For instance, for C1, the system distinguished only between authorized users and unauthorized users; for C2 and above, each user had an individual ID. Once logged in, the system used the user ID, and the security profile associated with it, to make access decisions. The system also used the ID to audit user actions. The Orange Book required user auditing beginning at the C2 level.

C.1.1.3. Assurance

Assurance is a guarantee (or at least a reasonable confidence) that the security policy of a trusted system has been implemented correctly and that the system's security features accurately carry out that security policy. The Orange Book identified two types of assurance: operational assurance and life-cycle assurance. Operational assurance focused on the basic architecture and features of the system; life-cycle assurance focused on controls and standards for building and maintaining the system.

Moving up the ladder from less trusted to more trusted, systems encountered more and more assurance requirements only to a point. At the highest levels (B3 and A1), there were very few additional security features beyond those required for lower-level systems. What was added was a greater demand that a far greater assurance, or trust, could be placed in the security features.

A very important element of system security is the assurance that the system will function as expected and will remain available for operation over the course of its lifetime. Many vendors met the system integrity requirement by providing a set of integrity tests. These tests occurred regularly, often each time the system was powered up, reminiscent of the power on self test (POST) performed by most computers and network appliances. More substantial security diagnostics were usually performed at scheduled preventive maintenance periods.

In theory, every operation performed by every piece of information in a network can provide information that is useful to an attacker. A covert channel is an information path that's not ordinarily used for communication in a system and therefore isn't protected by the system's normal security mechanisms. Covert channels have a nice subversive sound to them. They're a secret way to convey information to another person or programthe computer equivalent of a spy carrying a newspaper as a signal: for example, the New York Times means the blueprints have been smuggled out of the plant, and the Washington Post means there's been a problem.

The reason covert channels aren't more of a problem is that getting meaningful information in this way is quite cumbersome. The Orange Book wisely reserved covert channel analysis and protection mechanisms for the highest levels of security (B2 systems and above), where the information gained by exploiting covert channels is more likely to be worth the quest.

Trusted facility management, another Orange Book criterion, is the assignment of a specific individual to administer the security-related functions of a system. Trusted facility management is closely related to the concept of least privilege, which means that the users in a system should have the least number of privilegesand for the shortest amount of timeneeded to do their work. It's also related to the administrative concept of separation of duties, the idea that it's better to assign pieces of security-related tasks to several specific individuals; if no one user has total control of the system's security mechanisms, no one user can completely compromise the system.

The Orange Book concept of trusted recovery ensures that security is not breached when a system crash or some other system failure occurs. Trusted recovery actually involves two activities: preparing for a system failure and recovering the system. A system failure represents a possibly serious security risk because it is a time when the system is not functioning in the ordinary way. For example, if the system crashes while sensitive data is being written to disk (where it is protected by the system's access control mechanisms), the possibility exists that the data will be left unprotected in memory. Alternatively, a data label representing a lower level of security may have been assigned to a file that was in the process of having secret materials removed from it, but the operation had not been completed when the failure occurred.

Life-cycle assurance.

Life-cycle assurance ensures that once assurance activities are begun, they will continue for the rest of the time the computer or network remains in service. It is a metric of diligence to protect hardware and software from tampering or inadvertent modification at any stage in the system's life cycleduring design, development, testing, updating, or distribution. An example of a key life-cycle assurance is configuration management, which carefully monitors and protects all changes to the system's hardware, software, firmware, test suites, and documentation.

These and other Orange Book assurances are subject to verification by testing. The Orange Book even carries a requirement for the highest levels of security that all material and parts into and out of the computer or network be protected by trusted distribution, which means that materials must be protected while they are at vendors' facilities and while they are transported to and from. This may require secure storage, protective, tamper-proof packaging, and the use of couriers.

C.1.1.4. Documentation

The final set of requirements defined in the Orange Book was the set of documentation requirements. Developers of trusted systems sometimes complained that the documentation required for the evaluation of a trusted system was formidable. The Orange Book mandated four specific documents, although this varied by trust classification. As you'd expect, the amount and depth of the documentation increased as you moved up the trusted system ladder.

The documentation requirements were:

• Security Features User's Guide (SFUG)

• Trusted Facility Manual (TFM)

• Test documentation

• Design documentation

The Security Features User's Guide (SFUG) was aimed at ordinary, unprivileged system users. It told them what they needed to know about system security features and how to enforce them, including: logging in, protecting and moving files, and warnings about why certain file moves, adds, and changes were disallowed by the system.

The Trusted Facility Manual (TFM) was aimed at system administrators and/or security administrators. It told them everything they needed to know about setting up the system so it would be secure, and how to enforce system security. The Orange Book required that the TFM contain warnings about the functions and privileges that must be controlled in a trusted system. The TFM was a requirement at all levels of security. As security requirements became more complex at the higher levels, the TFM addressed increasingly complex topics as well.

The test documentation requirement was also an important piece of security testing. Good test documentation is usually simple but voluminous. It was not uncommon that the test documentation for even a C1 or C2 system to consist of many volumes of test descriptions and results. For all Orange Book levels, the test documentation had to "show how the security mechanisms were tested, and results of the security mechanisms' functional testing."

The design documentation was a formidable requirement for most system developers. The focus of the design documentation was to document the internals of the system's (or at least the Trusted Computing Base's [TCB]) hardware, software, and firmware. A key task was to define the boundaries of the system and to clearly distinguish between those portions of the system that are security-relevant and those that are not.

There were two major goals of design documentation: to prove to the evaluation team that the system fulfills the evaluation criteria, and to aid the design and development team by helping them define the system's security policy and how well that policy was implemented.

Because there were so many questions about the scope, organization, and quantity of design documentation during system development and evaluation, the government published A Guide to Understanding Design Documentation in Trusted Systems (another in the Rainbow Series: the Burgundy Book). This document summarizes all the specific design documentation requirements (36 in all!).