The Orange Book, why has it been ignored?

The Orange Book, why have software developers ignored it? We had the knowledge to avoid the cyber insecurity of today but commercial software developers have ignored it?

In the early days of mass computer interconnectedness the US space department of defense developed the trusted computer system evaluation criteria (TCSEC). The purpose behind the creation of TCSEC was to make it the primary method used to evaluate operating systems, applications, and different products. The evaluation criteria was published in a book with an orange cover, which lead to it being known as the Orange Book. 

The methodology included a rating system and criteria that would be used to evaluate commercial software and hardware products. The TCSEC provided specifications for manufacturers when developing secure products. The TCSEC was intended to become a one-stop evaluation process so individual components within a specific solution would not need to be evaluated in isolation.

The Orange book was used to evaluate product based on a specific set of security properties which the vendor claimed to have implemented. The evaluation would determine if the product was appropriate for its intended use much like the PCI DSS Qualified Vendor process does today. 

The TCSEC provided a classification system that is divided into levels of security that built off each other. Each step up in the classification increased the level of security and assurance that could be relied upon:

• Verify protection
• Mandatory protection
• Discretionary protection
• Minimal security

The TCSEC classification schema ranged from "A" to "D" was established where A was the highest level of assurance and D the lowest level of assurance.

Each classification tiers included one or more numbered classes supported by a set of requirements and tests that would need to be completed before a product would be certified. As the numbers increased so did the degree of trust and assurance. For example products classified as "B2" had achieved a higher level of assurance than "B1" or "A" achieved a higher level of assurance than "B".

The following terminology was used to describe the basic assessment elements of each class within the schema:

• Security policy - The policy must be explicit and well defined and enforced by the mechanics within the system.
• Identification - Individual subjects must be uniquely identified.
• Labels - Control labels must be associated properly with objects.
• Documentation - Documentation must be provided, including test, design, and specification documents, user guides, manuals.
• Accountability - Audit data must be captured and protected to enforce accountability.
• Lifecycle assurance- Software, hardware, and firmware must be able to be tested individually to ensure that each enforces the security policy in an effective manner throughout their lifetimes.
• Continuous protection - The security mechanisms and the system as a whole must perform predictably and acceptably in different situations continuously.

These elements acted like quality control checkpoints used to evaluate each product independently. The final assurance rating represents the rolled up total.

The level of assurance increased as each classification tier built upon the previous tier. This meant that when a vendor submitted a product for evaluation it included an independent assessment based on this criteria. The organization who oversaw the certification process was known as the trusted products evaluation program (T PEP). Vendors and suppliers that successfully passed the evaluation were placed on a controlled list of product suppliers along with their achieved classification. This provided a convent list of pre-screened suppliers so whenever a manager was interested in a specific line of products, they could check the list. This is exactly how PCI DSS has established the Qualified Vendors and Suppliers List. 

Division D: minimal protection

There is only one class in division D. Is reserved for systems that have been evaluated but failed to meet the criteria requirements of the higher divisions.

Division C: discretionary protection

The C rating category has two individual assurance ratings within it, which are described next. The higher the number of out of the assurance rating, the greater the protection.

C1: discretionary security protection discretionary access control is based on individuals and/or groups. It requires a separation of users and information, and identification and authentication of individual entities. Some type of axis control is necessary so users can ensure their data will not be accessed and corrupted by others. The system architecture must supplier part tech did execution domain so privilege system processes are not adversely affected by lower privilege processes. The must be specific ways of validating the systems operational integrity. The documentation requirements include design documentation, which shows that the system was built to include protection mechanisms, test documentation (test plan and results), a facility manual (so companies know how to install and configure the system correctly), and user manuals.

The type of environment that would require this rating is one in which users are processing information at the same sensitivity level; thus, strict access control and auditing measures are not required. It would be a trusted environment with low security concerns.

C2: controlled access protection users need to be identified individually to provide more precise axis control and auditing functionality. Logical access control mechanisms are used to enforce authentication and the uniqueness of each individual's identification. Security-relevant events are audited, these records must be protected from unauthorized modification. The architecture must provide resource, or object, isolation so proper protection can be applied to the resorts and any actions taken upon it can be properly audited. The object reuse concept must also be invoked, meaning that any medium holding data must not contain any remnants of information after it is released for another subject to use. If the subject uses a segment of memory, that memory space must not hold any information after the subject is done using it. The same is true for storage media, objects being populated, and temporary files being created-all data must be efficiently erased once the subject is done with that medium.

This class requires a more granular method of providing access control. The system must enforce strict logon procedures and provide decision-making capabilities when subjects request access to objects. A C-2 system cannot guarantee it will not be compromised, but it supplies a level of protection they would make attempts to compromise it harder to accomplish.

The type of environment that would require systems with a C-2 rating is one in which users are trusted by a certain level of accountability is required. C-2, overall is seen as the most reasonable class for commercial applications, the level of protection is still relatively weak.

Division B: mandatory protection

Mandatory access control is enforced by the use of security labels. The security architecture is based on the Bell-Padula security model, and evidence of reference monitor enforcement must be available.

B1: labeled security each data object must contain a classification label and each subject must have a clearance label. When the subject tends to access an object, the system must compare the subjects and the object security labels to ensure that requested actions are except the bolt. Data leaving the system must also contain an accurate security label. The security policy is based on an informal statement, and the design specifications are reviewed and verified.

This security rating is intended for environments that require systems to handle classified data.

B2: structure protection the security policy is clearly defined and documented, and the system design in a plantation or subjected to more thorough review and testing procedures. This class requires more stringent authentication mechanisms and well-defined interfaces among layers. Subjects and devices require labels, and the system must not allow covert channels. A trusted path for logon and authentication processes must be in place, which means the subject communicates rectally with the application or operating system, and no trapdoors exists. There is no way to circumvent or compromise this communication channel. Operator and administration functions are separated within the system to provide more trusted and protected operational functionality. Distinct address spaces must be provided to isolate processes, and a covert channel analysis is conducted. This class adds assurance by adding requirements to the design of the system.

The type of environment that were require a B2 systems is one that processes sensitive data that require a higher degree of security. This type of environment would require systems that are relatively resistant to penetration and compromise.

B3: security domains in this class, more granularity is provided in each protection mechanism, and the programming code that is not necessary to port the security policy is excluded. The design enablement case and should not provide too much complexity, because as the complexity of the system increases, so must the skill level of the individuals who need to test, maintain, and configure it; thus, the overall security can be threatened. The reference monitor components must be small enough to test properly and be tamperproof. The security administrator role is clearly defined, and the system must be able to recover from failures without it security level in compromise. When the system starts up and loads its operating system and components, it must be done in an initial secure state to ensure that any weaknesses of the system cannot be taken advantage of in this slice of time.

The type of environment that requires B3 systems is a highly secured environment that processes very sensitive information. You require systems that are highly resistant to penetration.

Division A: verify protection

Formal methods are used to ensure that all subjects and objects are controlled with the necessary discretionary and mandatory access controls. The design, development, limitation, and documentation are looked at in a formal and detailed way. The security mechanisms between B3 and A1 are not very different, but the way the system was designed and developed is evaluated in a much more structured and stringent procedure.

A1: verify design the architecture protection features are not much different from systems that achieve a B3 rating, but the insurance of an A1 system is higher than it B3 system because of the formality and the way the A1 system was designed, the way the specifications were developed, and the level of detail in the verification techniques. Formal techniques are used to prove the equivalence between the TCB specifications and the security policy model. A more stringent change configuration is put in place with the development of a capital A1 system, and the overall design can be verified. In many cases, even the way in which the system is delivered to the customer is under scrutiny to ensure that there is no way of compromising the system before it reaches its destination.

Type of environment that would require the capital A1 system is the most secure of security environments. This type of environment deals with top-secret information cannot adequately trust anyone using this system without strict authentication, restrictions, and auditing.


This was a workable system that never made it past the military. However, very similar systems have been implemented in the commercial sector such as the PCI DSS. Commercial off the shelf software (COTS) sold today will never achieve the level of security that is needed in our every expanding - connected world.