World Library  
Flag as Inappropriate
Email this Article

Trusted Computer System Evaluation Criteria

Article Id: WHEBN0023571638
Reproduction Date:

Title: Trusted Computer System Evaluation Criteria  
Author: World Heritage Encyclopedia
Language: English
Subject: Trusted computing base, Multiple single-level, National Security Agency, Discretionary access control, Multiple Independent Levels of Security
Collection: Computer Security Standards, National Security Agency, Trusted Computing
Publisher: World Heritage Encyclopedia

Trusted Computer System Evaluation Criteria

The Orange Book

Trusted Computer System Evaluation Criteria (TCSEC) is a United States Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system. The TCSEC was used to evaluate, classify and select computer systems being considered for the processing, storage and retrieval of sensitive or classified information.

The TCSEC, frequently referred to as the Orange Book, is the centerpiece of the DoD Rainbow Series publications. Initially issued in 1983 by the National Computer Security Center (NCSC), an arm of the National Security Agency, and then updated in 1985. TCSEC was replaced by the Common Criteria international standard originally published in 2005.


  • Fundamental objectives and requirements 1
    • Policy 1.1
    • Accountability 1.2
    • Assurance 1.3
    • Documentation 1.4
  • Divisions and classes 2
    • D — Minimal protection 2.1
    • C — Discretionary protection 2.2
    • B — Mandatory protection 2.3
    • A — Verified protection 2.4
  • Matching classes to environmental requirements 3
  • See also 4
  • References 5
  • External links 6

Fundamental objectives and requirements

The Orange Book or DoDD 5200.28-STD was canceled by DoDD 8500.1 on October 24, 2002. DoDD 8500.1 reissued as DoDI 8500.02 on March 14, 2014. [1]


The security policy must be explicit, well-defined and enforced by the computer system. There are three basic security policies:

  • Mandatory Security Policy - Enforces access control rules based directly on an individual's clearance, authorization for the information and the confidentiality level of the information being sought. Other indirect factors are physical and environmental. This policy must also accurately reflect the laws, general policies and other relevant guidance from which the rules are derived.
  • Marking - Systems designed to enforce a mandatory security policy must store and preserve the integrity of access control labels and retain the labels if the object is exported.
  • Discretionary Security Policy - Enforces a consistent set of rules for controlling and limiting access based on identified individuals who have been determined to have a need-to-know for the information.


Individual accountability regardless of policy must be enforced. A secure means must exist to ensure the access of an authorized and competent agent which can then evaluate the accountability information within a reasonable amount of time and without undue difficulty. There are three requirements under the accountability objective:

  • Identification - The process used to recognize an individual user.
  • Authentication - The verification of an individual user's authorization to specific categories of information.
  • Auditing - Audit information must be selectively kept and protected so that actions affecting security can be traced to the authenticated individual.


The computer system must contain hardware/software mechanisms that can be independently evaluated to provide sufficient assurance that the system enforces the above requirements. By extension, assurance must include a guarantee that the trusted portion of the system works only as intended. To accomplish these objectives, two types of assurance are needed with their respective elements:

  • Assurance Mechanisms
  • Operational Assurance: System Architecture, System Integrity, Covert Channel Analysis, Trusted Facility Management and Trusted Recovery
  • Life-cycle Assurance : Security Testing, Design Specification and Verification, Configuration Management and Trusted System Distribution
  • Continuous Protection Assurance - The trusted mechanisms that enforce these basic requirements must be continuously protected against tampering and/or unauthorized changes.


Within each class there is additional documentation set which addresses the development, deployment and management of the system rather than its capabilities. This documentation includes:

  • Security Features User's Guide, Trusted Facility Manual, Test Documentation and Design Documentation

Divisions and classes

The TCSEC defines four divisions: D, C, B and A where division A has the highest security. Each division represents a significant difference in the trust an individual or organization can place on the evaluated system. Additionally divisions C, B and A are broken into a series of hierarchical subdivisions called classes: C1, C2, B1, B2, B3 and A1.

Each division and class expands or modifies as indicated the requirements of the immediately prior division or class.

D — Minimal protection

  • Reserved for those systems that have been evaluated but that fail to meet the requirements for a higher division

C — Discretionary protection

  • C1 — Discretionary Security Protection
    • Identification and authentication
    • Separation of users and data
    • Discretionary Access Control (DAC) capable of enforcing access limitations on an individual basis
    • Required System Documentation and user manuals
  • C2 — Controlled Access Protection
    • More finely grained DAC
    • Individual accountability through login procedures
    • Audit trails
    • Object reuse
    • Resource isolation

B — Mandatory protection

  • B1 — Labeled Security Protection
    • Informal statement of the security policy model
    • Data sensitivity labels
    • Mandatory Access Control (MAC) over selected subjects and objects
    • Label exportation capabilities
    • All discovered flaws must be removed or otherwise mitigated
    • Design specifications and verification
  • B2 — Structured Protection
    • Security policy model clearly defined and formally documented
    • DAC and MAC enforcement extended to all subjects and objects
    • Covert storage channels are analyzed for occurrence and bandwidth
    • Carefully structured into protection-critical and non-protection-critical elements
    • Design and implementation enable more comprehensive testing and review
    • Authentication mechanisms are strengthened
    • Trusted facility management is provided with administrator and operator segregation
    • Strict configuration management controls are imposed
    • Operator and Administrator roles are separated.
  • B3 — Security Domains
    • Satisfies reference monitor requirements
    • Structured to exclude code not essential to security policy enforcement
    • Significant system engineering directed toward minimizing complexity
    • Security administrator role defined
    • Audit security-relevant events
    • Automated imminent intrusion detection, notification, and response
    • Trusted system recovery procedures
    • Covert timing channels are analyzed for occurrence and bandwidth
    • An example of such a system is the XTS-300, a precursor to the XTS-400

A — Verified protection

  • A1 — Verified Design
    • Functionally identical to B3
    • Formal design and verification techniques including a formal top-level specification
    • Formal management and distribution procedures
    • Examples of A1-class systems are Honeywell's SCOMP, Aesec's GEMSOS, and Boeing's SNS Server. Two that were unevaluated were the production LOCK platform and the cancelled DEC VAX Security Kernel.
  • Beyond A1
    • System Architecture demonstrates that the requirements of self-protection and completeness for reference monitors have been implemented in the Trusted Computing Base (TCB).
    • Security Testing automatically generates test-case from the formal top-level specification or formal lower-level specifications.
    • Formal Specification and Verification is where the TCB is verified down to the source code level, using formal verification methods where feasible.
    • Trusted Design Environment is where the TCB is designed in a trusted facility with only trusted (cleared) personnel.

Matching classes to environmental requirements

Army Regulation 380-19 is an example of a guide to determining which system class should be used in a given situation.

See also


  1. ^

External links

  • Trusted Computer System Evaluation CriteriaNational Security Institute - 5200.28-STD
  • FAS IRP DOD Trusted Computer System Evaluation Criteria DOD 5200.28
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.