1 November 1998
Source: Paul Merrill

This document available Zip-compressed: http://jya.com/ntob.zip (92K)

NOT the Orange Book

By Paul H. Merrill

A Guide to the Definition, Specification, Tasking, and Documentation for the Development of Secure Computer Systems -- Including Condensations of the Members of the Rainbow Series and Related Documents, Paul H. Merrill, Merlyn Press, Wright-Patterson Air Force Base, 1992.

Works by the Author from Merlyn Press

Graphics User's Manual for the NCR Worksaver System

Appendix I: TRIGS COMPUSEC Requirements

TRIGS Computer Lifecycle Management Plan

TRIGS Software Risk Management Plan

Test Report: Sigma II Silver Harvester

SoftWare Evaluation Team Report

Software Quality Assurance

PHIP Segment Specification

Rainbow Readers' Digest

NOT The Orange Book

Dedication and Acknowledgement

To Hugh Lynn, without whom this never would have gotten started. To Terry Tucker, without whose inspiration this would not be what it is. To Larry Miner, without whose indulgence this would never have been finished. To Jim Plaisted, Laura Picon, Mel Hoeferlin, Dave Hensley, and Dan O'Connor, without whose kind words this would not have been as well-aimed. To Larry Yelowitz and DoctorDave Gobuty, without whose pressure the diamond might not be so pure. To Steve Job, for making Apple what it was. And, of course, to Mom and PoP.

Foreword

This book was started to serve as a text from which to teach an introductory course in Computer Security. As the writing progressed, it became apparent that more depth was needed than a simple introductory course would entailÄandÄthat the work would need to serve those people not taking the course. I sincerely hope that this helps you as much as it was intended to.

Introduction

This book was written to help reduce the onslaught of information available in the field of operational computer security to manageable proportions and to help make sense of the process needed to correctly determine the level of computer security needed for a specific program. There are four major groups of intended readers who can gain from the use of this text.

Active COMPUSEC Professionals: Those who regularly work with COMPUSEC issues will find that this book works quite nicely to bring together, in a manageable size, the gems from a shelf full of reference publications. After all, who can remember it all, all of the time; paper was invented so people could forget. Also, this book should help to locate that fine nuance which is "in one of those books over there" but eludes capture on the tip of the tongue at the moment.

Novice COMPUSEC Professionals: Those who have only recently begun to work the COMPUSEC issues will find that this book helps to point out what they don't know and then take a good stab at filling the void, to working levels at least.

COMPUSEC-Associated Professionals: For the mass of people who work in association with COMPUSEC professionals, especially on a program which has COMPUSEC as a significant portion of the effort, this book serves to enlighten without wasting an inordinate amount of time.

COMPUSEC Unknowns: For those who aren't sure whether their program requires active computer security measures, this book serves to point out what there is to be gained by COMPUSEC in an integrated security engineering effort.

NOT The Orange Book is not intended to replace the Rainbow Series or the associated publications produced by other governmental bodies. Rather it seeks to point the way in a shorter and simpler format. But, just as Cliff Notes are not the same as the classics covered by them, there is still a need, at times, to read the full text of the standard documents. Neither is this book intended to replace the engineering process (or the thought process) in determining the computer security requirements. The use of this book has been envisioned in the following ways.

Table of Contents: The table of contents is written in the Old Style, with major topics within the section included in the table itself. If a particular topic is in question, between the titles and the topics, the appropriate section should be able to be found with little difficulty. If it is certain that the full text is going to be needed for close scrutiny, the entry includes the title, number, and color (if a Rainbow Member) of the unDigested document.

Defining the System: A guided tour of the thought processes and basic algorithms involved seeks to help the Reader to determine the level of computer security needed for the particular system and its environment. As a part of this process the tradeoffs which need to be considered between computer security and the other securities are discussed.

Spare Parts Bin: In the various portions of this section are the spare parts needed to specify the requirements and task the work effort and documentation for the various levels of computer security.

Digests: Each of the digests uses the information in the Table of Contents, with amplification, as a header and follows with the highlights from the particular book. If the digest leaves questions unanswered, going to the full text is probably in order.

Case Studies: Through the use of several case studies (at high levels of abstraction) the Reader may be able to focus the other information and tools discussed and provided by this book.

Glossary: There are two "Glossaries" in this book. The first is the digest of TG-004, the second is a glossary of the terms which need definition in this book. While it would have been nice to have only one glossary, that would have required deletion of TG-004 (not good for completeness) or the inclusion of terms in the TG-004 digest which are not in TG-004 (not good for purity.)

Dedication and Acknowledgement

Foreword

Introduction

Table of Contents

Section I: Building A Secure System

System Security Engineering Management
Systems Security Engineering as a Part of Systems Engineering
CompuSec Engineering as a Part of Systems Security Engineering
The "Securities"
System Accreditation
Security After Deployment
The Fundamental Laws of Computer Security

Determining the System's Security Needs
Threats and Vulnerabilities => Risks
Sharing the Security NeedsÄorÄ"CompuSec and the Securities"
Yellow Books (I & II)
Lowering the CompuSec Needs

Statement of Work Issues 18
Format Considerations
Separate WBS Item / Scattered Throughout
Cost
Quality
Oversight
Perceived Importance

System Security Engineering Management Program
The Securities
Oversight of Program
Industrial Security and the Rest

Documentation
For Itself
For Oversight Effort
Pertinent Documents

Section II: Spare Parts

C1 Class
Discretionary Access Control (DAC)
Identification And Authentication
SOW Tasking

C2 Class
Discretionary Access Control (DAC)
Identification And Authentication
Audit
System Security Architecture
SOW Tasking

B1 Class
Discretionary Access Control (DAC)
Identification And Authentication
Audit
System Security Architecture
Labels
Mandatory Access Control (MAC)
SOW Tasking

B2 Class
Discretionary Access Control (DAC)
Identification And Authentication
Audit
System Security Architecture
Labels & Mandatory Access Control (MAC)
SOW Tasking

B3 Class
Discretionary Access Control (DAC)
Identification And Authentication
Audit
System Security Architecture
Labels & Mandatory Access Control (MAC)
SOW Tasking

A1 Class
Discretionary Access Control (DAC)
Identification And Authentication
Audit
System Security Architecture
Labels & Mandatory Access Control (MAC)
SOW Tasking

CDRL Inputs
Data Item Descriptions (DIDs)
Subsystem Design Analysis Report
System Security Management Plan
Security Vulnerability Analysis
System/Subsystem Specification Document for AISs
Adversary Mission Analysis
Logistical Support Analysis

Section III: Rainbow Readers' Digest

DOD 5200.28-STD Orange (Formerly: CSC-STD-001-83)
DoD Trusted Computer System Evaluation Criteria
Fundamental Computer Security Requirements
Divisions and Classes of Systems
Testing Guidelines
Commercial Product Evaluation
Requirements

CSC-STD-002-85 Green
DoD Password Management Guideline
Individual Password
Password Change
Password Protection
Password Length

CSC-STD-003-85 Yellow I
Computer Security Requirements
Minimum User Clearance (R_Min)
Maximum Data Sensitivity (R_Max)
Risk Index
Computer Security Requirements

CSC-STD-004-85 Yellow II
Rationale Behind Computer Security Requirements
Risk Index
Security Risk Index Matrix
Security Index Matrix For Open Security Environments
Security Index Matrix For Closed Security Environments

CSC-STD-005-85 Dark Blue
DoD Magnetic Remanence Security Guideline
Declassification and Clearing
Declassification Permission
Properly Functioning Media
Non-functional Media
Destruction

NCSC-TG-001 Tan
A Guide to Understanding Audit
Audit Requirements Overview
Audited Events
Selective Audit

NCSC-TG-002 Blue
Trusted Product Evaluations A Guide for Vendors
Phases of the Trusted Product Evaluation Program
Technical Description of the Product
Legal Agreement

NCSC-TG-003 Tangerine I
A Guide to Understanding Discretionary Access Control
Implementation Methodologies
Control Permission and Access Modes
Requirements

NCSC-TG-004 Aqua
Glossary of Computer Security Terms
NCSC-TG-005 Red I
Trusted Network Interpretation
Security Policy
New Evaluation Areas
Network Components
Cascading

NCSC-TG-006 Tangerine II
A Guide to Understanding Configuration Management
Configuration Management (CM) Use
CM Requirements
CM Tasks

NCSC-TG-007 Burgandy
A Guide to Understanding Design Documentation
C2 Design Documentation Requirements
B1 Design Documentation Requirements
B2 Design Documentation Requirements
B3 Design Documentation Requirements
A1 Design Documentation Requirements

NCSC-TG-008 Lavender
A Guide to Understanding Trusted Distribution
Trusted Distribution (TD) Assurances
Post-Production Protection
Transit Protection

NCSC-TG-009 Venice Blue
Computer Security Subsystem Interpretation
Required Features
Assurance Requirements
Documentation Requirements

NCSC-TG-011 Red II
Trusted Network Interpretation Environments Guideline
Network Security Architecture and Design
Risk Assessment
Network Security Services

NCSC-TG-013 Hot Pink
Rating Maintenance Phase Program Document
Preevaluation Phase
Vendor Assistance Phase/Design Analysis Phase
Evaluation Phase
Rating Maintenance Phase

NCSC-TG-014 Purple
Guidelines for Formal Verification Systems
Endorsement And ETL Listing
Technical factors
Features
Assurance
Required Documentation

NCSC-TG-015 Brown
A Guide to Understanding Trusted Facility Management
Security Administrator
Secure Operator
Account Administrator
Auditor

NCSC-TG-017 Light Blue
Identification and Authentication
Authentication by Knowledge
Authentication by Ownership
Authentication by Characteristic
Implementation
I&A Requirements by Class

NCSC-TG-019 Blue
Trusted Product Evaluation Questionnaire

NCSC-TG-020 Gray
Access Control List (ACL) Features for UNIX
NCSC-TG-021 Lilac
Trusted Database Management System Interpretation
Conditions for Evaluating by Parts
Local/Global Requirements
Interpretation of the Orange Book Requirements

NCSC-TG-025 Green
Data Remanence in Automated Information Systems
Standard Clearing / Purging Methods
Considerations
Approved Procedures for Various Media

NCSC-TG-026 Fluorescent Orange
Security Features User's Guide
Audience
Format
Presentation
Example SFUGs

C Technical Report 79-91 Yellow
Integrity in Automated Information Systems
Integrity Goals
Integrity Principles
Integrity Policies and Mechanisms
Integrity Separation Policies
General Integrity Policies

NTISSAM COMPUSEC/1-87
Advisory Memorandum on Office Automation Security
User Responsibilities
Security Officer Responsibilities

MIL-STD 1785
System Security Engineering Program Management Requirements
Concept Exploration Phase
Demonstration and Validation Phase
Full-Scale Development Phase
Production and Deployment Phase

DRS-2600-5502-86
Security Requirements for System High
and Compartmented Mode Workstations
System High Requirements
Compartmented Mode Requirements

Section IV: Case Studies

NDG: New Development Gonculator
Threats
Data / Classified material
Implementation

UG: Upgrade Gonculator
Threats
Data / Classified material
Implementation

CGG: Communications Group Gonculator
Threats
Data / Classified material
Implementation

GIGS: Ground Intelligence Gonculator System
Threats
Data / Classified material
Implementation

Yellow Books
NDG Assessment
UG Assessment
CGG Assessment
GIGS Assessment

Section V: Notes

Abbreviations and Acronyms
Glossary

Section I:

Building A Secure System

I. Building a Secure Computer System

As the Information Age progresses, the reliance on computers is increasing at a steady pace. Along with this reliance comes an ever increasing need to apply the standard management practices, which are a part of the rest of our lives, to computers. Security has long been a standard management practice which now needs to make its way into the management of computer systems too. People who would never leave their office unlocked will leave their computer modem activated without a second thought. People who would never hand over their checkbook will leave their financial data on a diskette unprotected. The same people who would never hand out the combination to their safe will resist the use of password protection on a computer with the same information stored. Security must be part and parcel of a computer system, and it must be built into the system with minimum negative impact and maximum return on the investment.

System Security Engineering Management

The security aspects of a program are maintained and nourished through Systems Security Engineering Management as set forth in MIL-STD-1785. Systems Security Engineering covers the entire spectrum of security activities with an integrated approach that allows for methodical and comprehensive coverage of the security effort.

Systems Security Engineering as a Part of Systems Engineering

Through the Systems Engineering discipline, Systems Security Engineering in general, and Computer Security (CompuSec) in particular, can be accomplished in an efficient and orderly manner. The iterative analytical techniques which are so much a part of the Systems Engineering process are totally applicable to the requirements definition for the Systems Security Engineering process as well. Top level functions still decompose into lower level functionality. The design tradeoffs and requirements analysis are still studied, interpreted, and selected in the same manner. MIL-STD-1785 gives the tasks to be performed and their sequencing; Systems Engineering gives the methodology to accomplish the tasking.

Computer Security Engineering as a Part of Systems Security Engineering

Though only lightly touched upon in MIL-STD-1785, computer security (CompuSec) is an integral part of system security engineering for programs which incorporate computers processing sensitive data. Due to the ever increasing storage capacity, processing power, and transmission rates, damages and losses from computers have become a very real concern across the whole of society. An entire briefcaseful of classified data will fit on a single diskette. The average computer heist is orders of magnitude greater than the average bank robbery. Because computers operate so much faster than humans, the computer must handle a significant portion of the security.

The "Securities"

Systems Security Engineering is concerned with a group of security disciplines which are interrelated and have significant overlap in the protection given against various vulnerabilities. Each must be considered, along with its strengths and weaknesses during system requirements definition and development.

Information Security (INFOSEC): Concerned with access to information without regard to the form of the information. (Closely related to CompuSec with a large area of overlap.)
Physical Security: Concerned with physical access to the protected resources. (Locks, doors, fences, and guards.)
Computer Security (CompuSec): Concerned with regulating and recording access to computer resources and the data residing in the computer.
Personnel Security: Concerned with the verified "Goodness" of the personnel involved with a system (Clearances).
Product Security: Concerned with the security of the "product" during the manufacturing process. (A CompuSec concern for Configuration Management and Trusted Distribution)
Industrial Security: Concerned with the developing contractors' security aspects and activities. (Higher Industrial Security is one way to lower CompuSec requirements.)
Operations Security (OPSEC): Concerned with operational information and the restricting of data to the appropriate personnel. (Loose Lips )
Communications Security (COMSEC): Concerned with the secure communications and cryptographical aspects. (Often lumped with CompuSec and called INFOSEC.)
Emanations Security (EMSEC, Tempest): Concerned with stray electronic impulses and the ability to use them to derive useful information.
Administrative Security (Procedural Security): Concerned with the procedures used to provide for security. (Hand-written audit trails, Administrative restriction to a given security level on a given machine, Two-Man rule, etc.)

System Accreditation

No matter what kind of computer system is being developed, there will be someone (or some agency), responsible for allowing the system to operate with the data needed. This someone, the accreditor {or Designated Approving Authority (DAA), or any number of other names depending on the system} looks at the entire system and all of the securities and evaluates the interactions to determine the overall security suitability of the total system. Early and active involvement of the DAA in the development of the requirements and the system design is necessary to the development of a secure system which will be allowed to operate, as planned, when finished.

Security After Deployment

Whatever security is designed and built into the system during development must take into account the security measures which will be implemented after system deployment. Computer security measures require action from a security person at least on a part-time basis and, for larger systems, teams of security personnel are needed full time. In addition, the various implementation levels for physical security and personnel security can either raise or lower the necessary security measures which need to be incorporated into the computer system itself. (Obviously the security measures for an Automatic Teller Machine (ATM) are radically different than the measures for the bank's mainframe computer.) Security measures considered during design and development must, therefore, take into account usability and personnel availability as well as other security measures which may modify the security needs of the computer system itself.

The Fundamental Laws of Computer Security

The First Law of Computer Security

P(Bany) = 1.0
The probability of a Bust on any secure system is 1.0
If someone really wants in.

The Second Law of Computer Security

The best security system ever built will not function
If not used.

The Third Law of Computer Security

To err is Human
To really screw things up, use a Computer.

The Fourth Law of Computer Security

The audit trail is there to tell you who to shoot.

Determining the System's Security Needs

In order to levy appropriate CompuSec requirements and task the developing contractor properly, it is first necessary to determine the types of security needed and the levels of security for each type needed. This book does not seek to fully define the levels of security for all of the "Securities" - just identify the tradeoffs which can be made between the "Securities" and then fully define the level of CompuSec needed for a given set of assumptions about the system, its environment, and its capabilities.

Threats and Vulnerabilities => Risks

The purpose of the CompuSec requirements and tasking levied on a system is to lower the risks of the system. Risks occur when a threat finds a vulnerability to attack. By reducing either the threat or the system's vulnerability to the threat, the risk is reduced.

Vulnerabilities: Vulnerabilities can be grouped into two main categories for CompuSec purposes; the system itself and the data which is stored, processed, and/or transmitted by the system.

The computer portion of the system itself is relatively fragile by nature and is susceptible to system shutdown or slowdown without very much effort on the part of the threat. Even a relatively small degradation in performance is sufficient to cause the system to become effectively worthless. In addition, the typical non-embedded system is a high dollar value piece of equipment which is always a favorite target.

The data used within the system is obviously a target for the threats to the system. After all, the manipulation of the data is why the computer system is being developed. Whether classified or not, the data is needed by the user of the system or it should not be on the system. Any data that is needed by the user is also needed by those Not So Friendly people in the world and/or the Not So Friendlies would like to see the data not be available to the user.

Threats: Threats to a system come in a wide variety of shapes and sizes. An airborne system has the threat that it might fall to Earth. A ground based system has the threat of power surges during a thunder storm. Either of these threats can effectively deny the user the use of the system and its data without any malicious intent on the threats part. In addition, there are indeed Not So Friendly people out there who will want a system and its data, either for their own or to deny the use of the system to the user. Each threat must be considered for each system, though the nature of the system will limit the viable threats somewhat. (Computer Centers rarely suffer from bird strikes and crash from the sky.)

Risks: When the Vulnerable assets of a system are subject to targeting by the Threats to the system, Risk of Bad Things happening is present. The point behind the CompuSec engineering effort is to reduce the risks to an acceptable level so that the Bad Things won't happen beyond the system's level to cope with them. (Because the Bad Things for one system are different than the Bad Things for another system, the Approach to determining the needs for a system is the purpose of this section.)

Sharing the Security Needs or"CompuSec and the Securities"

Theoretically the computer system could be built which would allow anyone, even Not So Friendly folk, to sit down at the terminal and have an acceptable level of risk. In fact, this is essentially the case for the network of ATMs raising its head all over the place. This is not, however, the optimum situation for most systems. Through a well-reasoned engineering trade-off process, a suitable mix of the securities can be found which will minimize performance degradation and cost while remaining in the realm of well understood techniques and well within the state-of-the-art (and probably within the state-of-the-technology.)

Performance Considerations: Whatever security measures are levied on the system will have some effect on the performance of the system. In the case of the ATMs, ease of use is reduced by the need to have the Card and the limited functionality of the available options. If human intervention is required for each access to data, the queue will build to intolerable levels for an active system. Requiring the system to maintain security labels on each subject and object within the system will add unnecessary throughput to a system which operates at a single security level. A facility entry system which backs-up the personnel around the block at shift change is most probably counter-productive. Some of the basic trade-offs between CompuSec and the other Securities are:

Layered Physical Security will allow for more ready access to the terminals for a limited set of users, provided that the Physical Security measures are sized properly for the actual traffic flow. The Physical Security tends to be manpower intensive and or to use emerging technology which will add another set of CompuSec concerns regarding the computer that runs the physical security. In most instances, some level of Physical Security will be required.

When control over the users is possible, Personnel Security can reduce the level of CompuSec required. Unfortunately, operational considerations do not always allow for sufficient controls to be placed on the personnel. The ultimate case in point is the ATM Network, but, in this day and age of multinational cooperation, the limiting of personnel to US nationals goes out the window when the system is sold through Foreign Military Sales (FMS). The limiting of personnel to relatively high clearance levels will add to the lifecyle cost of the system unless the users are, by the nature of their duties, already cleared to the required level.

While labor-intensive, Procedural Security can solve many "unsolvable" situations. The system operators must have the ability to circumvent the normal operations of the system in order to perform some of their tasks - Procedural Security is the answer. Overuse of this technique will limit the ability of the "watchers" to watch effectively, and the higher the use the higher the problem of watching the watchers grows.

Intelligent use of these securities will allow for a greater degree of trust to be granted the system's software through development by cleared personnel and configuration management throughout the life of the system, including upgrades. All of those little devils like Trojan Horses, Viruses, Logic Bombs, Worms, etc. will be greatly reduced, and possibly stopped, through careful application of Administrative, Product, and Industrial Securities.

Costs: Additional requirements, of any kind, add to the development cost of a system. In some cases, though, the lifecycle cost will be lower because of the increased requirements. The following are some of the aspects of the cost of the requirements that need to be considered.

Because the majority of the CompuSec requirements are realized in software, the development cost of CompuSec requirements are substantial. To some degree these costs can be lowered through the purchase of COTS systems from the National Computer Security Center's (NCSC) Evaluated Product List (EPL) for the appropriate level of security. The other securities are typically realized as hardware subsystems and as operational procedure manuals. Depending on the level of security required, these can be COTS turnkey systems and procedures which are simple and straight forward. In the extreme case, the requirements can represent a major development effort in their own right.

The payoff for the expense in development is that if the computer performs a function, a person does not need to. CompuSec requirements which are executed properly reduce the manpower needed for the life of the system. The personnel needs linked to Physical Security are high and the Administrative Security methodologies also are labor intensive. Personnel Security can become prohibitively expensive in more resources than mere money if the required clearance levels grow too far beyond the minimum necessary in an effort to simplify the security requirements in other security disciplines.

Level of Understanding: Of all of the security disciplines which are managed by System Security Engineering Management, CompuSec is probably the least well understood. While there is nothing especially difficult about CompuSec, its relative newness leads to misunderstandings concerning its requirements which would not happen in another discipline. Because of this low misunderstanding threshold, any requirements which are leveled in the CompuSec arena must be stated in the clearest form possible and monitored closely to ensure proper execution.

Do-Ability: In conjunction with the generally low level of understanding of the CompuSec discipline, the do-ability of CompuSec functionality bottoms out in much shallower water than with functionality that is better understood. The state-of-the-art for CompuSec is not on a par with the state-of-the-technology for other aspects of systems development. Each time a CompuSec requirement is levied it must be carefully examined to ensure the do-ability.

Yellow Books (I & II)

The Yellow Books are members of the Rainbow Series put out by the NCSC. (Actually they are CSC-STD-003-85 and CSC-STD-004-85. Digests of these two standards can be found in Section III: Rainbow Readers' Digest.) The sole purpose of these two documents is to give a standard method for determining the needed Orange Book Class for a given system with its given set of circumstances. The approach taken by the Yellow Books is conceptually simple: take the level of data on the system and compare it to the clearances of the people with access to the system. The greater the difference between the lowest cleared person and the highest level of data, the higher the risk. The following steps are taken to quantify this risk.

Minimum User Clearance Rating (RMin): Through the use of the table in the Yellow Books, a numeric rating is given to the clearance of the lowest cleared personnel who will have access to the system. This number will be between 0 (Uncleared, without access to Sensitive Unclassified Information) and 7 (TS/SBI with access to Multiple Categories of TS Data).

Maximum Data Sensitivity Rating (RMax): Through the use of the appropriate table in the Yellow Books, a numeric rating is given to the sensitivity of the most sensitive data operated on by the system. The number will be between 0 (Unclassified) and 7 (TS with two or more categories of Secret or TS data).

Risk Index: The Risk Index is computed by subtracting the RMin from the RMax. When a non-positive (zero or negative) value is the result {all users cleared to equal to or higher than all of the data}, the Risk Index is 1 if there are any categories to which any user does not have access and 0 otherwise. When a positive value is the result, the Risk Index is that result.

(Risk Index = RMax - RMin)

Modes of Operation: The CompuSec requirements for a system vary with the mode of operation and the controls that are necessary to allow for operation in that mode. There are four recognized modes of operation for secure computer systems. Each of these modes has its own environment in which to operate and conditions that indicate its use.

The Dedicated Mode of operation is indicated for a system when each user has clearance for all of the data on the system, formal access to all of the data, and a valid need-to-know for all of the data.

The system high mode of operation is indicated for a system when each user has clearance for all of the data on the system and formal access to all of the data on the system, but not all of the users have a valid need-to-know for all of the data on the system.

The compartmented mode of operation is indicated for a system when each user has clearance for all of the data on the system but not all users have formal access or a valid need-to-know for all of the data on the system.

The multilevel mode of operation is indicated for systems where not every user has clearance for all of the data on the system, formal access to all of the data on the system, or a valid need-to-know for all of the data on the system.

Development Environment: Malicious logic planted by the developers during development is almost impossible to find until it is too late. When a system is developed by personnel who are verified to not be Not So Friendly People the system can be trusted to act in the manner in which it was designed (at least more so than a system which may have been developed by malicious programmers.) Because of this, the Yellow Books allow for less stringent CompuSec requirements when the system is developed in a closed environment than if it is developed in an open environment.

There are two required conditions for a Closed Development Environment, both of which must be met, to qualify a development environment as Closed.

Developers: The developers must have clearances and authorizations equal to the data which will be processed by the system, or at least Secret clearance for systems that will process data at or above Secret. (This is to reduce the risk of malicious logic being inserted by the developers.)

Configuration Control: Configuration control must be sufficient to ensure no malicious logic is inserted after development.

If either of the above conditions are not met, the development environment is Open. It should be noted that most COTS systems are developed in an Open Environment. (In fact, most commercial vendors fail both conditions).

Orange Book Class: Now that the Risk Index, Mode of Operation, and Development Environment type have been selected/defined for the system, the Orange Book Criteria Class needed for the system can be determined. The actual CompuSec requirements and tasking are based upon the Orange Book Class indicated.

C1: Provides for nominal Discretionary Access Control (DAC).
C2: Provides for more finely grained DAC, auditing, and accountability through individual login procedures.
B1: Additionally provides for Mandatory Access control (MAC), an informal policy model, and export labeling.
B2: Additionally provides for a formal model, covert channel analysis, a structured Trusted Computing Base (TCB), and stringent Configuration Management.
B3: Additionally provides for a small TCB which contains only security policy enforcement functions, a separate security administrator function, and all accesses to objects are to be mediated.
A1: Functional requirements are the same as B3. Additionally provides for formal design specification and verification techniques and more stringent documentation and Configuration Management requirements.

Lowering the CompuSec Needs

Now that the various trade-off options have been discussed and an initial Orange Book class has been identified with the Yellow Books, the iterative process of tuning the system operational concept to lower the CompuSec needs begins. The following areas are the primary areas where progress can be made in this effort.

Classified Needs: The assumed classified needs of the system should be reviewed to ensure the validity of each level of classified or sensitive data. In some instances, the data requirements of the system could be satisfied with a lower level of data which can materially lower the level of CompuSec requirements. Nice-To-Haves aren't so nice when they get to be expensive.

Operational Personnel: If the system concept calls for most of the operational personnel to be cleared to Level X and a few to be cleared only to the lower Level Y, it should be investigated whether the few can be reasonably cleared to Level X as well. If, on the other hand, only a few of the personnel are cleared (conceptually) to Level X, it should be investigated whether the Level X personnel (and the Level X data) could be segregated into a subsystem of the total system which is not accessible to the Level Y personnel.

Environmental Considerations: The net effects of the other securities should be reviewed to tune the trade-offs on iteration of the security requirements definition. In some instances, slightly raising the other Securities' requirements will greatly lower the CompuSec requirements. In other cases, it may become clear that relieving the other Securities of some of their requirements will have no negative impact on the system because CompuSec is going to need to cover that aspect of security anyway.

Statement of Work (SOW) Issues

As the Class of requirements increases, the documentation requirements and other tasks also increase. By the time that the jump from B3 to A1 comes along, the only changes are to the tasking and documentation; the functional requirements are identical. This part of the book will supply the Spare Parts and "installation instructions" for the SOW.

There are some decisions to be made for the specific program in question; these decisions will be discussed in the Format Considerations portion. The impacts of the decisions are subtle, but, like much subtlety, the effects can be truly insidious.

System Security Engineering Management (SSEM), as set forth in MIL-STD-1785, covers a broad range of security disciplines which includes computer security. The SSEM Program portion shows the paths which will help the program arrive at the appropriate destination for the system. It is especially important that the other securities neither wash out the computer security nor allow the computer security to wash them out.

The Documentation portion gives a guided tour of the various documents which are peculiar to, or measurably altered by, computer security.

The Tasks portion breaks the tasks into digestible chunks and presents them by Orange Book Class. The final arrangement in the SOW will be based on the decisions which need to be made with the help of the Format Considerations portion presented earlier in the SOW part and as modified by the SSEM program portion.

Format Considerations

The formatting of the tasking within the SOW can have impacts beyond the surface impression. The continuity of the security effort and the cost of that effort are both affected by the layout of the tasking as well as the reporting of the effort and its costs. The decision must be made early in order to have the security built into the program instead of a Johnny-Come-Lately effort tacked on to the main effort after it is too late to achieve much more than expensive Lip Service.

Separate WBS Item / Scattered Throughout

At the lower extreme, the C1 Class systems require very little in the way of special requirements or extra documentation. For such systems there is no need to have a special niche set in the Work Breakdown Structure (WBS) for the CompuSec effort.

On the other hand, the A1 Class systems have such intensive requirement sets, software proofs, and documentation that the set of activities represents a significant portion of the overall effort for the system. For such systems there is a definite need to elevate security in general, or CompuSec in particular, a relatively high niche in the WBS for reporting purposes and to give a unified front for the related, and interdependent, activities involved in the design and development of an A1 Class system.

Now that the decisions for the extremes are taken care of, consideration must be given to the middle ground. The relative scale and scope of the CompuSec effort as a portion of the total effort will be the primary determining factor for a given system. Secondary considerations are the relative awareness of the CompuSec arena by the contractor personnel involved and the relative newness of the techniques which are planned to be used. A relatively high level WBS element dedicated to the CompuSec effort will generally lead to a CompuSec "office" within the contractor with the charge of monitoring the implementation of the requirements and handling the documentation requirements.

Cost Quality Oversight Perceived Importance

The higher the level of the WBS element for CompuSec is defined, the finer the detail cost accounting for the CompuSec effort will be. This is, of course, the way the WBS works. In conjunction with the finer detail of the cost accounting, the actual cost will also tend to rise with the level of the WBS. More management emphasis and a higher level manager to manage the effort equate to more effort expended and more effort expended equates to higher cost for the CompuSec effort.

With the higher level of management attention, the quality of the work performed tends to improve somewhat. If the tasking is scattered about the system effort the tendency exists for the CompuSec portion of the effort to get slighted in favor of the "Real Effort". As the effort is drawn together, the "Real Effort" becomes the CompuSec effort. This results in a more concerted effort and trade-offs being made which favor the being viewpoint (at least part of the time.)

Along with the cost visibility comes overall program oversight of the effort both on the part of the contractor and the government. This improved oversight of the effort can result in great savings because the CompuSec arena is not well understood for the most part. As time marches on and more contractors (and government personnel) become experienced with CompuSec the great need for special oversight will wane, but, for now, the greater the oversight the better. In addition to the direct government oversight, if the contractor has a cadre of experienced personnel, the CompuSec "office" at the contractor can serve as an Internal Independent Verification and Validation (IIV&V) team. Of course, the usual problems related to IIV&V will still exist; the reporting chain will not reach high enough, the IIV&V personnel will be pulled to perform Software Engineering at the drop of a schedule, etc. For a time, the visibility and oversight will be improved greatly.

The single greatest reason for elevating the level of the WBS element for the CompuSec effort is the perceived importance of the effort by the contractor. The contractor is resource limited. The areas which are perceived as being important to the government will receive the higher priorities in the allocation of resources. If the CompuSec effort is perceived as being of low importance, the resources allocated will be low priority resources.

System Security Engineering Management Program

The System Security Engineering Management (SSEM) Program is called for by MIL-STD-1785. While the CompuSec portion of the SSEM Program is the primary emphasis of this book, the Program as a whole needs to be examined to determine the appropriate way to task the portions.

The Securities

Each of the Securities mentioned earlier in this Section are covered by SSEM. For any given program, some, all, or none of the securities will have minimal impact or import. Each must be examined and the appropriate measures, studies, etc. must be taken to counter the threats. For the most part, the measures to be taken will take the form of support subsystems and/or procedural and administrative measures. By the start of Engineering and Manufacturing Development (EMD), and the writing of the EMD SOW, the appropriate tasking should be clear for each of the securities. The SSEM Program should cover the group as a whole with separate sections as needed for the actual design and implementation.

Oversight of Program

In order to maintain an appropriate level of oversight by the government, it is a good idea to levy the SSEM Program Management tasks as one of the direct tasks under System Engineering. This allows the tasks to receive the proper attention by the proper personnel. Within the SSEM PM section, the various securities can be broken out as needed.

Industrial Security and the Rest

One care that should be taken is to ensure that none of the securities ride rough-shod over the others. (Yes, that includes CompuSec) Another security which tends to grow a life of its own is Industrial Security. While definitely needed, Industrial Security should be kept well separated from the rest of the securities (except perhaps Product Security). A good model for a program which includes a fairly stiff CompuSec effort would be; System Engineering => SSEM => Industrial Security, CompuSec, The Other Securities.

Documentation

Along with the functional requirements for each of the Classes of secure computer systems come documentation requirements. In some cases, the documentation needs closely parallel the standard documentation (users guides, etc.) and these needs can be filled by replacement or modifications to the standard documents. In other cases, the CompuSec documents have no equivalent document (Formal Top Level Specification, Computer Security Policy Model, etc.).

For Itself

Some of the CompuSec documentation is needed because the document produced is needed by the operators of the system. For instance, the user's manuals, especially the Security Features Users Guide, are needed to allow the full and efficient use of the secure system as designed and built. On the other hand, the security test documentation and the covert channel analysis are needed by the security personnel to help circumvent penetration attempts during the operational phase of the system lifecycle. While these documents are not part of the standard documentation package for most systems, they are essential to the ultimate security of the system.

For Oversight Effort

Other documents in the package are for program oversight purposes. For instance, the Computer Security Policy Model is used as an intermediate document to ensure the correct interpretation and implementation of the Computer Security Policy. While these documents serve no innate long term purpose, the long term effects of not having the documents are massive. Because the CompuSec arena is not well understood and the vocabulary is basically unstable, there is an increased need for the contracting agency to maintain good oversight of the contractor's effort (and for the contractor to do the same).

Pertinent Documents

Because the documents are not those typically used for most programs, here is a list of the basic documents and their descriptions in order to help familiarize the reader with the terrain when the SOW tasking, CDRL, and tailored DIDs portions are reached.

System Security Engineering Management Plan: This is the cornerstone document for the security engineering effort. In it the contractor lays out the plan for managing the entire security engineering effort. Along with the other securities comes CompuSec and the plans to interpret, allocate, and implement CompuSec requirements and taskings. The document usually works best when detailed plans are given for the next phase of the program and broad plans are given for the remainder of the program. Updates at the beginning of each phase will then allow for the each layer of detailed planning to be based on a firm understanding of the approaches being taken. This is the document which will allow the government to gain confidence in the contractor's understanding of the tasking and requirements in a timely manner.

Computer Security Management Plan: This Plan is a CompuSec specific offshoot of the SSEM Plan. Here the detailed plans for CompuSec are laid out in excruciating detail. This allows the contractor and the government to ensure the understanding of the effort by the team which will actually be performing the tasking. On a large program with an intensive security engineering effort both documents are needed to allow for the varying levels of abstraction involved. On a smaller program, or a program with less intensive security needs, one or the other of the documents should be sufficient by itself.

Security Vulnerability Analysis (SVA): The SVA is generated during Concept Exploration and updated during Dem Val. By the time that FSD rolls around the SVA is complete and is used by the designers to determine the appropriate implementations to counter the vulnerabilities.

Computer Security Policy: The Policy contains the stated rules and assumptions under which the system will be built and function. Some of the topics covered would be the assumed level of personnel that will operate the system, the mode of operation for the system, whether Mandatory Access Control will be used, and the assumed operational environment for the system. The Policy really should be written by the government but typically it is left to the contractor to determine the Policy for the system, which works well if the government takes an active role in the approval process.

Computer Security Policy Model: This is the bridging document between the Policy and the requirements. Depending on the Class of the system the model is either a formal mathematical model or an informal English language descriptive model. While the Model tends to be a good-sized document it should be given close attention to ensure complete understanding of the Policy by the contractor.

Security Concept of Operations: This is the "Artists Rendition" of the CompuSec arena. This is where the conceptual implementation of the Policy is laid out and the interplay of the various Securities is discussed. This document should be written for the ease of understanding by the non-Security professional. This is the probable source (along with the Policy) for the inputs to the Yellow Books in the determination of the needed Class of security requirements and tasking for the system.

Security Architecture Study: This study covers the finer details of the security architecture after the initial determination of the needed Class has been made. The results can result in changes in the needed Class through reallocation to the Other Securities.

NOTE: The Policy, SVA, Model, Security Con Ops, and Security Architecture Study are developed and finalized around the same time period and are iteratively developed as the interdependencies and repercussions of the decision process are felt.

Covert Channel Analysis Report: This report is mandated for systems at or above Class B2. The methods of passing data outside normal, controlled channels are analyzed and any which are of sufficient bandwidth are studied for elimination/minimization purposes.

Computer Security Audit Analysis: This analysis is performed on a recurring basis to trace the implementation of the audit trail requirements. Understanding of the contractor approach and realization of the requirements can be gained as well as the impacts of the audit process in processor throughput, network bandwidth availability, and storage space required. The periodic release is needed because the actual system performance costs continue to become more finely defined as the implementation approaches completion.

Security Features Users Guide (SFUG): This is the guide to understanding the functionality of the security features, their interactions, and guidelines for their use. For the lower Classes of systems, the SFUG can be a section of the users' manual but as the classes grow, so does the SFUG. Whenever possible, the SFUG should be a free-standing document for ease of use (and finding it).

Trusted Facility Manual: This manual covers the duties and roles of the security related positions on the system. The manual is sometimes realized as Positional Handbooks for each of the positions with the pertinent details needed for each position in its own Handbook. If realized as a single volume, the details for each position related to the security implementation needs to be present.

Descriptive Top Level Specification (DTLS): Starting at the B2 Class, the DTLS describes the Trusted Computing Base (TCB) in intimate detail, especially the TCB interface.

Formal Top Level Specification (FTLS): This is an A1 Class required document that is the formal (mathematical) brother of the DTLS. The FTLS must be produced with a endorsed formal specification system and must be mapped to the code of the TCB.

Security Test Documentation: Security test documentation serves two purposes: during development and test the documentation is used for the separate testing of the security features to ensure the security of the system. The documentation is then maintained to allow for retesting after modifications and updates to the system and for the use of the security personnel in the evaluation of the risks related to proposed changes to the systems and its environment.

Security Test Plan: The test plan, like most test plans, covers the Big Picture without going into great detail. It is the best view of the testing effort, though, and can be quite useful for gaining insight into the security implementation.

Security Test Procedures: The procedures, like most procedures, are excruciatingly detailed directions for the test itself. Where these test procedures differ is the pointing away from simple requirement satisfaction and more toward security satisfaction.

Security Test Report: The test report is the results of the testing and should be maintained through the life of the system to ensure continued protection and to document flaws which may exist.

Section II:

Spare Parts

II. Spare parts

In Section I: Building a Secure System the determination of the appropriate Class of secure system was made. In addition, the pros and cons of SOW and WBS options were discussed and decisions were to be made based on the particular system being developed. Also, a list of pertinent documents were discussed for the CompuSec arena.

In Section II: Spare Parts the pieces are listed which can be put together to form the CompuSec portions of the specification, SOW, and CDRL for the system in question. The section is broken into parts based on the Class of system determined in Section I. For each of the Classes from C1 through A1, the requirements, SOW tasking, and CDRL inputs are listed.

Requirements: The requirements are laid out as a separate appendix to the specification. While this is not intensely needed for the lower Classes, by the time that the B-level Classes are reached, the requirements are involved enough to necessitate the creation of a separate appendix.

SOW Tasking: The SOW portion is composed of paragraphs which will need to be arranged in the SOW in accordance with the decisions, made in Section I, concerning SOW formatting.

CDRL Inputs: The CDRL input section gives essentially all of the document-specific except for the distribution section which will need to be determined for each system individually.

NOTE -- The Tasking and CDRL inputs are not separated by phase. If the program has clear phases, some of the tasks and documentation will need to be tailored accordingly.

Following the portions concerned with the various Classes of systems, there is a portion containing the major Data Item Descriptions (DID). In some cases there will be a need to tailor the DIDs. Such tailoring should be performed only with the greatest of care.

Two things to remember when using these Spare Parts are:

These are the basic minimums for a generic system. For your specific system there may be portions which just do not apply and there may be portions which need to be added.

Nothing replaces careful thought and consideration.

C1 Class

The C1 class secure computer system is the lowest level of CompuSec requirements defined by the Orange Book. C1 class systems are appropriate for operation in the dedicated mode of operation only. The protections are not sufficient to protect against an internal attack.

There are a limited number of high level subjects and objects which are protected at all and the limits on the sharing of objects are not restrictive.

The users are required to login but the system does not need to be able to identify individual users uniquely. This implies that group logins (or project logins) are allowed.

The Trusted Computing Base (TCB) is required to protect itself (software) for outside interference and tampering and to be able to validate the operations of the TCB hardware and firmware.

C1 Class Requirements

10.1 Discretionary Access Control (DAC)
10.1.1 The TCB shall control access between named users and named objects.
10.1.2 The TCB shall allow users to specify and control sharing of objects by named individuals or groups or both.

10.2 Identification and Authentication
10.2.1 The TCB shall require users to identify themselves before performing any other actions on behalf of that user.
10.2.2 The TCB shall authenticate the user's identity before performing any other actions on behalf of that user.
10.2.3 The TCB shall protect authentication data from unauthorized access.

10.3 The TCB shall protect itself from external interference and tampering.
10.4 The TCB shall have the capability to validate the correct operations of the TCB's hardware and firmware.

C1 Class SOW Tasking

A. Data Accession List. The contractor shall maintain a complete list of all data generated as a result of this contract. The contractor shall list the data by title, date, and subject. The list shall include all memos, letters, meeting minutes, phone logs, etc. All data not required by the CDRL shall be considered contractor format. The document shall be titled Gonculator Data Accession List. (DI-A-3027A/T)

B. System Description. The contractor shall prepare separately published common appendices which describes the system for use with the system documentation. These appendices shall be prepared in an Unclassified version, if possible, and such classified versions that are required for a full description of the Gonculator System. The contractor shall use the common appendices in place of the system description within the bodies of the documentation. The descriptions shall be titled Gonculator System Description Appendix, (Appropriate Classification) Version. (DI-GDRQ-80567/T)

C. System Security Management Program. The contractor shall conduct a System Security Management Program in accordance with the approved System Security Management Plan.

D. System Security Management Plan. The contractor shall develop a system security management plan describing the contractor's security engineering and management approach. The plan should include all aspects of system security, including computer security. The document shall be titled Gonculator System Security Management Plan. (DI-MISC-80839/T)

E. Security Vulnerability Analysis. The contractor shall conduct a security vulnerability analysis and document the results. The study shall include identification of logical security vulnerabilities of the system, defining functional requirements which may secure the system from exploitation, and choosing safeguards to reduce identified vulnerabilities. The document shall be titled Gonculator Security Vulnerability Analysis. (DI-MISC-80841/T)

F. Computer Security Policy. The contractor shall prepare a document that defines the security policy enforced by the computer system. The document shall be titled Gonculator Computer Security Policy. (DI-GDRQ-80567/T)

G. Security Features Users Guide. The contractor shall generate a Users' Guide that documents the protection mechanisms provided by the system, guidelines for their use, and how the protection mechanisms interact with each other. The users guide may be published as either a common appendix to the positional handbooks or a stand-alone document titled Gonculator Security Features Users' Guide. (DI-MCCR-80019A/T)

H. Trusted Facility Manual. The contractor shall generate a manual that documents cautions about functions and privileges that should be controlled when running the secure facility in accordance with DOD-5200.28-STD. The document shall be titled Gonculator Trusted Facility Manual. (DI-MCCR-80019A/T)

C2 Class

The C2 class secure computer system enforces a more finely grained DAC than C1 class systems do. C2 class systems are appropriate for operation in the dedicated or system high modes of operation only. The protections include individual accountability.

There are a limited number of high level subjects and objects which are protected. Propagation of access rights is controlled. Access is controlled at the granularity of named individual and/or group of named individuals.

The users are required to login and the system needs to be able to identify individual users uniquely. While individuals are individuals, group access rights are still allowed.

Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed after the object is cleared to disallow any access to the old data.

Audit is required to make users responsible for their actions. Half of the theory behind audits is to allow for the security personnel to find wrongful acts and identify the perpetrator; the other half of the theory is that an advertised audit process will keep Honest people Honest.

The Trusted Computing Base (TCB) is required to protect itself (software) for outside interference and tampering and to be able to validate the operations of the TCB hardware and firmware.

C2 Class Requirements

10.1 Discretionary Access Control (DAC)
10.1.1 The TCB shall control access between named users and named objects.
10.1.2 The TCB shall protect all named objects from unauthorized access.
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named objects at the level of the single user.
10.1.4 The TCB shall allow authorized users to specify and control sharing of objects by named individuals or groups of individuals or both.
10.1.5 The TCB shall provide controls to limit propagation of access rights.

10.2 The TCB shall clear all memory objects before reallocation.
10.3 Identification and Authentication
10.3.1 The TCB shall require users to uniquely identify themselves before performing any other actions on behalf of that user.
10.3.2 The TCB shall authenticate the user's unique identity before performing any other actions on behalf of that user.
10.3.3 The TCB shall protect authentication data from unauthorized access.
10.3.4 The TCB shall associate the user's unique identity for all auditable actions taken by the user.

10.4 Audit
10.4.1 The TCB shall be able to create an audit trail.
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty days.
10.4.3 The TCB shall protect the audit trail from modification or unauthorized access.
10.4.4 The TCB shall audit the following event types:
a. Login.
b. Logout.
c. Access to objects.
d. Deletion of objects.
e. Actions taken by system operators, administrators, and security officers.

10.4.5 The TCB shall include the following information in each audit trail record:
a. Date and time of event.
b. User identity.
c. Event type.
d. Success or failure of action.
e. Name of object, if any.

10.4.6 The TCB shall selectively audit the actions of one or more users based on individual identity.

10.5 System Security Architecture
10.5.1 The TCB shall protect itself from external interference and tampering.
10.5.2 The TCB shall isolate the resources to be protected by access controls and auditing.

10.6 The TCB shall have the capability to validate the correct operations of the TCB's hardware and firmware.

C2 Class SOW Tasking

C. System Security Management Program. The contractor shall conduct a System Security Management Program in accordance with the approved System Security Management Plan.

G. Computer Security Audit Analysis. The contractor shall analyze the audit schema for the system including events to be audited, audit record structures, throughput requirements, storage needs, and archival storage techniques. The document shall be titled Gonculator Computer Security Audit Analysis. (DI-GDRQ-80567/T)

H. Security Features Users Guide. The contractor shall generate a Users' Guide that documents the protection mechanisms provided by the system, guidelines for their use, and how the protection mechanisms interact with each other. The users guide may be published as either a common appendix to the positional handbooks or a stand-alone document titled Gonculator Security Features Users' Guide. (DI-MCCR-80019A/T)

I. Trusted Facility Manual. The contractor shall generate a manual that documents cautions about functions and privileges that should be controlled when running the secure facility in accordance with DOD-5200.28-STD. The document shall be titled Gonculator Trusted Facility Manual. (DI-MCCR-80019A/T)

B1 Class

The B1 class secure computer system enforces a Mandatory Access Control (MAC) policy and the associated labeling. B1 class systems are appropriate for operation in the compartmented and multilevel modes of operation. Multilevel mode operations should be carefully considered before use because there is no protection from covert channel attacks.

There are a limited number of high level subjects and objects which are protected by DAC. Propagation of access rights is controlled. Access is controlled at the granularity of named individual and/or group of named individuals.

The users are required to login and the system needs to be able to identify individual users uniquely. While individuals are individuals, group access rights are still allowed.

Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed after the object is cleared to disallow any access to the old data.

Labels are required for all subjects and storage objects controlled by the TCB. These labels are used for MAC decisions which are also mandated for all subjects and storage objects under TCB control. The basic requirements are a simple translation of the standard "Paper-style" requirements onto the computer so the computer will mark and allow access properly.

The Trusted Computing Base (TCB) is required to protect itself (software) for outside interference and tampering and to be able to validate the operations of the TCB hardware and firmware.

B1 Class Requirements

10.1 Discretionary Access Control (DAC)
10.1.1 The TCB shall control access between named users and named objects.
10.1.2 The TCB shall protect all named objects from unauthorized access.
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named objects at the level of the single user.
10.1.4 The TCB shall allow authorized users to specify and control sharing of objects by named individuals or groups of individuals or both.
10.1.5 The TCB shall provide controls to limit propagation of access rights.

10.2 The TCB shall clear all memory objects before allocation to a new subject.
10.3 Identification and Authentication
10.3.1 The TCB shall require users to uniquely identify themselves before performing any other actions on behalf of that user.
10.3.2 The TCB shall authenticate the user's unique identity before performing any other actions on behalf of that user.
10.3.3 The TCB shall ensure that the user's login security level and authorizations are dominated by the user's clearance and authorizations.
10.3.4 The TCB shall ensure that the security level and authorizations of subjects external to the TCB which are created on behalf of the user are dominated by the user's clearance and authorizations.
10.3.5 The TCB shall protect authentication data from unauthorized access.
10.3.6 The TCB shall associate the user's unique identity for all auditable actions taken by the user.

10.4 Audit
10.4.1 The TCB shall be able to create an audit trail.
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty days.
10.4.3 The TCB shall protect the audit trail from modification or unauthorized access.
10.4.4 The TCB shall audit the following event types:
a. Login.
b. Logout.
c. Access to objects.
d. Deletion of objects.
e. Override of human-readable output markings.
f. Labeling of imported unlabeled data.
g. Any change in the designation of single level and multilevel devices.
h. Any change in security level or levels associated with a subject or object.
i. Actions taken by system operators, administrators, and security officers.

10.4.5 The TCB shall include the following information in each audit trail record:
a. Date and time of event.
b. User identity.
c. Event type.
d. Success or failure of action.
e. Security level of object, if any.
f. Name of object, if any.

10.4.6 The TCB shall selectively audit the actions of one or more users based on individual identity and/or object security level.

10.5 System Security Architecture
10.5.1 The TCB shall protect itself from external interference and tampering.
10.5.2 The TCB shall isolate the resources to be protected by access controls and auditing.
10.5.3 The TCB shall maintain distinct address spaces for process isolation.

10.6 The TCB shall have the capability to validate the correct operations of the TCB's hardware and firmware.
10.7 Labels
10.7.1 The TCB shall maintain the sensitivity label associated with each subject and object under TCB control.
10.7.2 The sensitivity label associated with a subject or an object shall correctly represent the security level of the subject or object.
10.7.3 The TCB shall use the sensitivity labels as the basis for mandatory access control decisions.
10.7.4 The TCB shall request a label from an authorized user before importing unlabeled data.
10.7.5 The TCB shall associate an accurate and unambiguous sensitivity label exported information.
10.7.6 The TCB shall designate each I/O device and communications channel as a single level or multilevel device.
10.7.7 Any change in the designation of single level or multilevel shall be performed manually.
10.7.8 The TCB shall associate with each object exported over a multilevel device the sensitivity level in the same form as the data and physically residing with the data.
10.7.9 The communications protocol used for each multilevel communications port shall provide for the unambiguous pairing of the data and its associated sensitivity label.
10.7.10 The TCB shall allow an authorized user to designate the single security level of information imported or exported via a single level communications port or I/O device.
10.7.11 The TCB shall allow the System Administrator to specify the printable label names associated with exported sensitivity labels.
10.7.12 The TCB shall mark the top and bottom of all human readable output with human readable sensitivity labels that properly represent the sensitivity of the output.

10.8 Mandatory Access Control (MAC)
10.8.1 The TCB shall enforce mandatory access control for all subjects and storage objects under its control.
10.8.2 A subject shall be allowed read access only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all of the non-hierarchical categories in the object's security level.
10.8.3 A subject shall be allowed write access only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all of the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level.

B1 Class SOW Tasking

A. Gonculator Accreditation Working Group. The contractor shall support the Gonculator Accreditation Working Group (GAWG) through attendance at meetings as needed, presenting current program data as requested, acting upon assigned and accepted Action Items, and preparing minutes of the GAWG meetings. At a minimum, the GAWG will meet twice a year. At a minimum, support at the meetings shall include representatives from program management, configuration management, system engineering, and security engineering. (DI-A-7089/T)

B. Data Accession List. The contractor shall maintain a complete list of all data generated as a result of this contract. The contractor shall list the data by title, date, and subject. The list shall include all memos, letters, meeting minutes, phone logs, etc. All data not required by the CDRL shall be considered contractor format. The document shall be titled Gonculator Data Accession List. (DI-A-3027A/T)

C. System Description. The contractor shall prepare separately published common appendices which describes the system for use with the system documentation. These appendices shall be prepared in an Unclassified version, if possible, and such classified versions that are required for a full description of the Gonculator System. The contractor shall use the common appendices in place of the system description within the bodies of the documentation. The descriptions shall be titled Gonculator System Description Appendix, (Appropriate Classification) Version. (DI-GDRQ-80567/T)

D. System Security Management Program. The contractor shall conduct a System Security Management Program in accordance with the approved System Security Management Plan.

E. System Security Management Plan. The contractor shall develop a system security management plan describing the contractor's security engineering and management approach. The plan should include all aspects of system security, including computer security. The document shall be titled Gonculator System Security Management Plan. (DI-MISC-80839/T)

F. Computer Security Management Program. The contractor shall conduct a Computer Security Management Program in accordance with the approved Computer Security Management Plan.

G. Computer Security Management Plan. The contractor shall generate a computer security management plan. The Plan shall include the methods used to manage the computer security engineering program, program schedule, and the steps to be taken to ensure the proper incorporation of the computer security requirements into the system. The document shall be titled Gonculator Computer Security Management Plan. (DI-MISC-80839/T)

H. Security Vulnerability Analysis. The contractor shall conduct a security vulnerability analysis and document the results. The study shall include identification of logical security vulnerabilities of the system, defining functional requirements which may secure the system from exploitation, and choosing safeguards to reduce identified vulnerabilities. The document shall be titled Gonculator Security Vulnerability Analysis. (DI-MISC-80841/T)

I. Computer Security Policy. The contractor shall prepare a document that defines the security policy enforced by the computer system. The document shall be titled Gonculator Computer Security Policy. (DI-GDRQ-80567/T)

J. Computer Security Policy Model. The contractor shall develop and document a model of the security policy enforced by the system. The model description shall include the specific protection mechanisms and an explanation showing that they satisfy the model and will enforce the security policy. The document shall be titled Gonculator Computer Security Policy Model. (DI-GDRQ-80567/T)

K. Security Architecture Study. The contractor shall conduct a study of the security architecture of the system and document the results of the study. The study shall include partitioning of the system, cost/benefit analysis for the architectural alternatives, and the required Class of system for each alternative and for each partitioned subsystem. The report shall detail the recommended architecture for the system. The document shall be titled Gonculator Security Architecture Study. (DI-GDRQ-80567/T)

L. System Security Concept of Operations. The contractor shall generate a system security concept of operations that documents the security concept for the system including the incorporation of the protection philosophy into the system. The document shall be titled Gonculator System Security Concept Of Operations. (DI-MISC-80840/T)

M. Computer Security Audit Analysis. The contractor shall analyze the audit schema for the system including events to be audited, audit record structures, throughput requirements, storage needs, and archival storage techniques. The document shall be titled Gonculator Computer Security Audit Analysis. (DI-GDRQ-80567/T)

N. Security Features Users Guide. The contractor shall generate a Users' Guide that documents the protection mechanisms provided by the system, guidelines for their use, and how the protection mechanisms interact with each other. The users guide may be published as either a common appendix to the positional handbooks or a stand-alone document titled Gonculator Security Features Users' Guide. (DI-MCCR-80019A/T)

O. Trusted Facility Manual. The contractor shall generate a manual that documents cautions about functions and privileges that should be controlled when running the secure facility in accordance with DOD-5200.28-STD. The document shall be titled Gonculator Trusted Facility Manual. (DI-MCCR-80019A/T)

P. Security Test. The contractor shall conduct a separate security test in conjunction with the system acceptance test. The security test shall show that all security mechanisms function as defined in the system documentation and that the system is resistant to penetration. The security test shall include an ad hoc, loosely structured test by the government test team. The contractor shall train the government test team in the operation of the system before the start of the test. The government test team will consist of six people drawn from the developing, supporting, using, and accrediting communities.

Q. Security Test Plan. The contractor shall develop a test plan for the security testing to be performed. The document shall be titled Gonculator Security Test Plan. (DI-MCCR-80014A/T)

R. Security Test Description. The contractor shall develop test procedures to implement the approved Gonculator Security Test Plan. The document shall be titled Gonculator Security Test Description. (DI-MCCR-80015A/T)

S. Security Test Report. The contractor shall document the results of the security test. The document shall be titled Gonculator Security Test Report. (DI-MCCR-80017A/T)

B2 Class

The B2 class secure computer system is based on clearly defined security policy and model of the policy. B2 class systems are appropriate for operation in the compartmented and multilevel modes of operation. Multilevel mode operations should be carefully considered before use because there is limited protection from covert channel attacks.

The users are required to login and the system needs to be able to identify individual users uniquely. While individuals are individuals, group access rights are still allowed.

Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed after the object is cleared to disallow any access to the old data.

Labels are required for all system resources. These labels are used for MAC decisions which are also mandated for all subjects and storage objects under TCB control. The basic requirements are a simple translation of the standard "Paper-style" requirements onto the computer so the computer will mark and allow access properly.

The Trusted Computing Base (TCB) is required to protect itself (software) from outside interference and tampering and to be able to validate the operations of the TCB hardware and firmware.

B2 Class Requirements

10.1 Discretionary Access Control (DAC)
10.1.1 The TCB shall control access between named users and named objects.
10.1.2 The TCB shall protect all named objects from unauthorized access.
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named objects at the level of the single user.
10.1.4 The TCB shall allow authorized users to specify and control sharing of objects by named individuals or groups of individuals or both.
10.1.5 The TCB shall provide controls to limit propagation of access rights.

10.2 The TCB shall clear all memory objects before allocation to a new subject.
10.3 Identification and Authentication
10.3.1 The TCB shall require users to uniquely identify themselves before performing any other actions on behalf of that user.
10.3.2 The TCB shall authenticate the user's unique identity before performing any other actions on behalf of that user.
10.3.3 The TCB shall ensure that the user's login security level and authorizations are dominated by the user's clearance and authorizations.
10.3.4 The TCB shall ensure that the security level and authorizations of subjects external to the TCB which are created on behalf of the user are dominated by the user's clearance and authorizations.
10.3.5 The TCB shall protect authentication data from unauthorized access.
10.3.6 The TCB shall associate the user's unique identity for all auditable actions taken by the user.
10.3.7 The TCB shall support a trusted communication path between the TCB and a user, initiated exclusively by the user, for initial login and authentication.

10.4 Audit
10.4.1 The TCB shall be able to create an audit trail.
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty days.
10.4.3 The TCB shall protect the audit trail from modification or unauthorized access.
10.4.4 The TCB shall audit the following event types:
a. Login.
b. Logout.
c. Access to objects.
d. Deletion of objects.
e. Override of human-readable output markings.
f. Labeling of imported unlabeled data.
g. Any change in the designation of single level and multilevel devices.
h. Any change in security level or levels associated with a subject or object.
i. Identified covert storage channel exploitation events.
j. Actions taken by system operators, administrators, and security officers.

10.4.5 The TCB shall include the following information in each audit trail record:
a. Date and time of event.
b. User identity.
c. Event type.
d. Success or failure of action.
e. Security level of object, if any.
f. Name of object, if any.

10.4.6 The TCB shall selectively audit the actions of one or more users based on individual identity and/or object security level.

10.5 System Security Architecture
10.5.1 The TCB shall maintain a domain of its own execution that protects it from external interference and tampering.
10.5.2 The TCB shall isolate the resources to be protected by access controls and auditing.
10.5.3 The TCB shall maintain distinct address spaces for process isolation.
10.5.4 The TCB shall be structured modularly.
10.5.5 The user interface to the TCB and all TCB elements shall be completely defined.

10.6 The TCB shall have the capability to validate the correct operations of the TCB's hardware and firmware.
10.7 Labels
10.7.1 The TCB shall maintain the sensitivity label associated with each system resources accessible by subjects external to the TCB.
10.7.2 The sensitivity label associated with a subject or an object shall correctly represent the security level of the subject or object.
10.7.3 The TCB shall notify a terminal user of each change in the user's security level during a session.
10.7.4 The TCB shall support the assignment of minimum and maximum security levels for all attached devices.
10.7.5 The TCB shall use the sensitivity labels as the basis for mandatory access control decisions.
10.7.6 The TCB shall request a label from an authorized user before importing unlabeled data.
10.7.7 The TCB shall associate an accurate and unambiguous sensitivity label with all exported information.
10.7.8 The TCB shall designate each I/O device and communications channel as a single level or multilevel device.
10.7.9 Any change in the designation of single level or multilevel shall be performed manually.
10.7.10 The TCB shall associate with each object exported over a multilevel device the sensitivity level in the same form as the data and physically residing with the data.
10.7.11 The communications protocol used for each multilevel communications port shall provide for the unambiguous pairing of the data and its associated sensitivity label.
10.7.12 The TCB shall allow an authorized user to designate the single security level of information imported or exported via a single level communications port or I/O device.
10.7.13 The TCB shall allow the System Administrator to specify the printable label names associated with exported sensitivity labels.
10.7.14 The TCB shall mark the top and bottom of all human readable output with human readable sensitivity labels that properly represent the sensitivity of the output.

10.8 Mandatory Access Control (MAC)
10.8.1 The TCB shall enforce mandatory access control over all subjects and objects accessible to subjects external to the TCB.
10.8.2 A subject shall be allowed read access only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all of the non-hierarchical categories in the object's security level.
10.8.3 A subject shall be allowed write access only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all of the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level.

B2 Class SOW Tasking

D. System Security Management Program. The contractor shall conduct a System Security Management Program in accordance with the approved System Security Management Plan.

F. Computer Security Management Program. The contractor shall conduct a Computer Security Management Program in accordance with the approved Computer Security Management Plan.

I. Security Architecture Study. The contractor shall conduct a study of the security architecture of the system and document the results of the study. The study shall include partitioning of the system, cost/benefit analysis for the architectural alternatives, and the required Class of system for each alternative and for each partitioned subsystem. The report shall detail the recommended architecture for the system. The document shall be titled Gonculator Security Architecture Study. (DI-GDRQ-80567/T)

J. System Security Concept of Operations. The contractor shall generate a system security concept of operations that documents the security concept for the system including the incorporation of the protection philosophy into the system. The document shall be titled Gonculator System Security Concept Of Operations. (DI-MISC-80840/T)

K. Computer Security Policy. The contractor shall prepare a document that defines the security policy enforced by the computer system. The document shall be titled Gonculator Computer Security Policy. (DI-GDRQ-80567/T)

L. Computer Security Policy Model. The contractor shall develop and document a formal model of the security policy enforced by the system. The model description shall include the specific protection mechanisms and an explanation showing that they satisfy the model and will enforce the security policy. The document shall be titled Gonculator Computer Security Policy Model. (DI-GDRQ-80567/T)

N. Covert Channel Analysis. The contractor shall conduct a thorough search for covert storage channels and make a determination of the maximum bandwidth of each identified channel. The contractor shall generate a covert channel analysis report that documents the results of the covert channel analysis. The document shall be titled Gonculator Covert Storage Channel Analysis Report. (DI-GDRQ-80567/T)

O. Descriptive Top Level Specification. The contractor shall generate a descriptive top level specification that completely and accurately describes the TCB in terms of exceptions, error messages, effects, and interfaces. The document shall be titled Gonculator Trusted Computing Base Descriptive Top Level Specification. (DI-GDRQ-80567/T)

P. Security Features Users Guide. The contractor shall generate a Users' Guide that documents the protection mechanisms provided by the system, guidelines for their use, and how the protection mechanisms interact with each other. The users guide may be published as either a common appendix to the positional handbooks or a stand-alone document titled Gonculator Security Features Users' Guide. (DI-MCCR-80019A/T)

Q. Trusted Facility Manual. The contractor shall generate a manual that documents cautions about functions and privileges that should be controlled when running the secure facility in accordance with DOD-5200.28-STD. The document shall be titled Gonculator Trusted Facility Manual. (DI-MCCR-80019A/T)

R. Security Test. The contractor shall conduct a separate security test in conjunction with the system acceptance test. The security test shall show that all security mechanisms function as defined in the system documentation and that the system is resistant to penetration. The security test shall include an ad hoc, loosely structured test by the government test team. The contractor shall train the government test team in the operation of the system before the start of the test. The government test team will consist of six people drawn from the developing, supporting, using, and accrediting communities.

S. Security Test Plan. The contractor shall develop a test plan for the security testing to be performed. The document shall be titled Gonculator Security Test Plan. (DI-MCCR-80014A/T)

T. Security TEST DESCRIPTION. The contractor shall develop test procedures to implement the approved Gonculator Security Test Plan. The document shall be titled Gonculator Security Test Description. (DI-MCCR-80015A/T)

U. Security Test Report. The contractor shall document the results of the security test. The document shall be titled Gonculator Security Test Report. (DI-MCCR-80017A/T)

B3 Class

The B3 class secure computer system is based on clearly defined security policy and model of the policy. B3 class systems are appropriate for operation in the compartmented and multilevel modes of operation.

Subjects and objects which are protected by DAC. Propagation of access rights is controlled. Access is controlled at the granularity of named individual and/or group of named individuals. The TCB is able to list the groups and individuals with access to given objects including modes of access allowed and those individuals and groups with no access allowed to an object. (This implies, but does not explicitly require, Access Control Lists (ACL).)

The users are required to login and the system needs to be able to identify individual users uniquely. While individuals are individuals, group access rights are still allowed.

Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed after the object is cleared to disallow any access to the old data.

The Trusted Computing Base (TCB) is required to protect itself (software) for outside interference and tampering and to be able to validate the operations of the TCB hardware and firmware. In addition, the TCB monitors the audit events to determine if the activity indicates imminent security violations and alerts the security officer upon occurrence.

B3 Class Requirements

10.1 Discretionary Access Control (DAC)
10.1.1 The TCB shall control access between named users and named objects.
10.1.2 The TCB shall protect all named objects from unauthorized access.
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named objects at the level of the single user.
10.1.4 The TCB shall allow authorized users to specify and control sharing of objects by named individuals or groups of individuals or both.
10.1.5 The TCB shall provide controls to limit propagation of access rights.
10.1.6 The TCB shall shall be capable of specifying a list of individuals and groups with access to the object including allowed access modes.

10.2 The TCB shall clear all memory objects before allocation to a new subject.
10.3 Identification and Authentication
10.3.1 The TCB shall require users to uniquely identify themselves before performing any other actions on behalf of that user.
10.3.2 The TCB shall authenticate the user's unique identity before performing any other actions on behalf of that user.
10.3.3 The TCB shall ensure that the user's login security level and authorizations are dominated by the user's clearance and authorizations.
10.3.4 The TCB shall ensure that the security level and authorizations of subjects external to the TCB which are created on behalf of the user are dominated by the user's clearance and authorizations.
10.3.5 The TCB shall protect authentication data from unauthorized access.
10.3.6 The TCB shall associate the user's unique identity for all auditable actions taken by the user.
10.3.7 The TCB shall support a trusted communication path between the TCB and a user, initiated exclusively by the user or the TCB, for use when positive TCB-to-user connection is needed.

10.4 Audit
10.4.1 The TCB shall be able to create an audit trail.
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty days.
10.4.3 The TCB shall protect the audit trail from modification or unauthorized access.
10.4.4 The TCB shall audit the following event types:
a. Login.
b. Logout.
c. Access to objects.
d. Deletion of objects.
e. Override of human-readable output markings.
f. Labeling of imported unlabeled data.
g. Any change in the designation of single level and multilevel devices.
h. Any change in security level or levels associated with a subject or object.
i. Identified covert channel exploitation events.
j. Actions taken by system operators, administrators, and security officers.

10.4.5 The TCB shall include the following information in each audit trail record:
a. Date and time of event.
b. User identity.
c. Event type.
d. Success or failure of action.
e. Security level of object, if any.
f. Name of object, if any.

10.4.6 The TCB shall selectively audit the actions of one or more users based on individual identity and/or object security level.
10.4.7 The TCB shall monitor the occurrence and accumulation of security audit events and identify imminent security violations.
10.4.8 The TCB shall alert the security officer of identified imminent security violations and take action to terminate continuing violations.

10.5 System Security Architecture
10.5.1 The TCB shall maintain a domain of its own execution that protects it from external interference and tampering.
10.5.2 The TCB shall isolate the resources to be protected by access controls and auditing.
10.5.3 The TCB shall maintain distinct address spaces for process isolation.
10.5.4 The TCB shall be structured modularly.
10.5.5 The user interface to the TCB and all TCB elements shall be completely defined.

10.6 The TCB shall have the capability to validate the correct operations of the TCB's hardware and firmware.
10.7 Labels
10.7.1 The TCB shall maintain the sensitivity label associated with each system resources accessible by subjects external to the TCB.
10.7.2 The sensitivity label associated with a subject or an object shall correctly represent the security level of the subject or object.
10.7.3 The TCB shall notify a terminal user of each change in the user's security level during a session.
10.7.4 The TCB shall support the assignment of minimum and maximum security levels for all attached devices.
10.7.5 The TCB shall use the sensitivity labels as the basis for mandatory access control decisions.
10.7.6 The TCB shall request a label from an authorized user before importing unlabeled data.
10.7.7 The TCB shall associate an accurate and unambiguous sensitivity label with all exported information.
10.7.8 The TCB shall designate each I/O device and communications channel as a single level or multilevel device.
10.7.9 Any change in the designation of single level or multilevel shall be performed manually.
10.7.10 The TCB shall associate with each object exported over a multilevel device the sensitivity level in the same form as the data and physically residing with the data.
10.7.11 The communications protocol used for each multilevel communications port shall provide for the unambiguous pairing of the data and its associated sensitivity label.
10.7.12 The TCB shall allow an authorized user to designate the single security level of information imported or exported via a single level communications port or I/O device.
10.7.13 The TCB shall allow the System Administrator to specify the printable label names associated with exported sensitivity labels.
10.7.14 The TCB shall mark the top and bottom of all human readable output with human readable sensitivity labels that properly represent the sensitivity of the output.

10.8 Mandatory Access Control (MAC)
10.8.1 The TCB shall enforce mandatory access control over all subjects and objects accessible to subjects external to the TCB.
10.8.2 A subject shall be allowed read access only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all of the non-hierarchical categories in the object's security level.
10.8.3 A subject shall be allowed write access only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all of the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level.

B3 Class SOW Tasking

D. System Security Management Program. The contractor shall conduct a System Security Management Program in accordance with the approved System Security Management Plan.

F. Computer Security Management Program. The contractor shall conduct a Computer Security Management Program in accordance with the approved Computer Security Management Plan.

N. Covert Channel Analysis. The contractor shall conduct a thorough search for covert channels and make a determination of the maximum bandwidth of each identified channel. The contractor shall generate a covert channel analysis report that documents the results of the covert channel analysis. The document shall be titled Gonculator Covert Storage Channel Analysis Report. (DI-GDRQ-80567/T)

S. Security Test Plan. The contractor shall develop a test plan for the security testing to be performed. The document shall be titled Gonculator Security Test Plan. (DI-MCCR-80014A/T)

U. Security Test Report. The contractor shall document the results of the security test. The document shall be titled Gonculator Security Test Report. (DI-MCCR-80017A/T)

A1 Class

The A1 class secure computer system is based on clearly defined security policy and model of the policy. A1 class systems are appropriate for operation in the multilevel mode of operation. The functional requirements for A1 are identical to the requirements for the B3 class system. The increased protection offered by A1 systems is through increased assurance measures.

The users are required to login and the system needs to be able to identify individual users uniquely. While individuals are individuals, group access rights are still allowed.

Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed after the object is cleared to disallow any access to the old data.

A1 Class Requirements

10.1 Discretionary Access Control (DAC)
10.1.1 The TCB shall control access between named users and named objects.
10.1.2 The TCB shall protect all named objects from unauthorized access.
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named objects at the level of the single user.
10.1.4 The TCB shall allow authorized users to specify and control sharing of objects by named individuals or groups of individuals or both.
10.1.5 The TCB shall provide controls to limit propagation of access rights.
10.1.6 The TCB shall shall be capable of specifying a list of individuals and groups with access to the object including allowed access modes.

10.2 The TCB shall clear all memory objects before allocation to a new subject.
10.3 Identification and Authentication
10.3.1 The TCB shall require users to uniquely identify themselves before performing any other actions on behalf of that user.
10.3.2 The TCB shall authenticate the user's unique identity before performing any other actions on behalf of that user.
10.3.3 The TCB shall ensure that the user's login security level and authorizations are dominated by the user's clearance and authorizations.
10.3.4 The TCB shall ensure that the security level and authorizations of subjects external to the TCB which are created on behalf of the user are dominated by the user's clearance and authorizations.
10.3.5 The TCB shall protect authentication data from unauthorized access.
10.3.6 The TCB shall associate the user's unique identity for all auditable actions taken by the user.
10.3.7 The TCB shall support a trusted communication path between the TCB and a user, initiated exclusively by the user or the TCB, for use when positive TCB-to-user connection is needed.

10.4 Audit
10.4.1 The TCB shall be able to create an audit trail.
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty days.
10.4.3 The TCB shall protect the audit trail from modification or unauthorized access.
10.4.4 The TCB shall audit the following event types:
a. Login.
b. Logout.
c. Access to objects.
d. Deletion of objects.
e. Override of human-readable output markings.
f. Labeling of imported unlabeled data.
g. Any change in the designation of single level and multilevel devices.
h. Any change in security level or levels associated with a subject or object.
i. Identified covert channel exploitation events.
j. Actions taken by system operators, administrators, and security officers.

10.4.5 T