1094 lines
51 KiB
Plaintext
1094 lines
51 KiB
Plaintext
|
||
|
||
NCSC -TG-002<DJ0>
|
||
Library No. S-228,538
|
||
Version 1
|
||
|
||
FOREWORD
|
||
|
||
The National Computer Security Center has established an aggressive program to
|
||
study and implement computer security technology, and to encourage the
|
||
widespread availability of trusted computer products for use by any
|
||
organization desiring better protection of their important data. The Trusted
|
||
Product Evaluation Program focuses on the security evaluation of commercially
|
||
produced and supported computer systems by evaluating the technical protection
|
||
capabilities against the established criteria presented in the Trusted
|
||
Computer System Evaluation Criteria. This program, and the open and
|
||
cooperative business relationship being forged with the computer and
|
||
telecommunications industries, will result in the fulfillment of our country's
|
||
computer security requirements. We are resolved to meet the challenge of
|
||
identifying trusted computer products suitable for use in processing sensitive
|
||
information. A key service of the National Computer Security Center to the
|
||
computer security community is to act as a clearinghouse for computer security
|
||
issues and to develop technical security guidelines for automatic data
|
||
processing systems and networks. This technical information exchange provides
|
||
guidance and interpretations for the security evaluation process and offers
|
||
the vendors a central point for technical exchange.
|
||
|
||
|
||
PATRICK R. GALLAGHER, JR. 1 March 1988
|
||
DIRECTOR
|
||
NATIONAL COMPUTER SECURITY CENTER
|
||
|
||
|
||
PREFACE
|
||
|
||
|
||
This publication describes procedures for interacting with the National
|
||
Security Agency's Information Security Organization as related to the Trusted
|
||
Product Evaluation Program within the National Computer Security Center. It
|
||
provides the information needed to submit a computer product for technical
|
||
security evaluation and outlines the National Security Agency's
|
||
responsibilities for positive, timely acknowledgements. This publication
|
||
specifically covers the National Computer Security Center's relationship with
|
||
vendors of proposed trusted computer products from the initial contact with
|
||
the vendor through the completion of the security evaluation process and
|
||
follow-on programs. Although more detailed instructions will be referenced in
|
||
this publication, sufficient guidelines are established for any first-time
|
||
user of the National Computer Security Center's services. The Office of
|
||
Industrial Relations invites your comments on this document and on the
|
||
National Computer Security Center's procedures for conducting security
|
||
evaluations of computer products. In cooperation with the computer industry,
|
||
we can improve our national security through the availability of trusted
|
||
computer products.
|
||
|
||
INTRODUCTION
|
||
|
||
In January 1981 the Director of the National Security Agency was assigned the
|
||
responsibility for computer security for the Department of Defense. This
|
||
action led to the formation of the Computer Security Center at the National
|
||
Security Agency. The Computer Security Center's Charter, promulgated in
|
||
Department of Defense Directive 5215.1 in October 1982, specifically tasks the
|
||
Computer Security Center to establish and maintain "... technical standards
|
||
and criteria for the security evaluation of trusted computer systems that can
|
||
be incorporated readily into the Department of Defense component life-cycle
|
||
management process..." The developmental experiments in the 1970's ranged from
|
||
attempts to add security front-ends to existing systems to designing secure
|
||
systems and hardware from scratch. Early research and development efforts
|
||
defined a graduated scale of security features and design principles. These
|
||
features and principles were incorporated in the Department of Defense Trusted
|
||
Computer System Evaluation Criteria (Orange Book). The Orange Book was issued
|
||
in August 1983. In December 1985, the Orange Book was reissued as a
|
||
Department of Defense Standard (DOD 5200.28-STD). The National Computer
|
||
Security Center (the Center) responds to a growing need for, and recognizes
|
||
technical challenges involved in, providing effective protection within
|
||
computer systems and networks of systems. The Center relies on an open and
|
||
cooperative relationship with government, industry representatives, and the
|
||
academic community to accomplish these important objectives. The government
|
||
encourages industry to provide the computer security capabilities government
|
||
needs. The Center sponsors critical research, and makes the results widely
|
||
available to encourage their incorporation into trusted computer products and
|
||
secure applications. The Center performs security evaluations of computer
|
||
software and hardware products on commercially or government-produced computer
|
||
systems. A trusted computer system is defined as a system that employs
|
||
sufficient hardware and software integrity measures to allow its use to
|
||
simultaneously process a range of sensitive unclassified or classified (e.
|
||
g., confidential through top secret) information for a diverse set of users
|
||
without violating access privileges. Levels of trust are based on the ability
|
||
of the computer system to enforce access privileges to authorized users and to
|
||
system protected files. The Center evaluates the security features of trusted
|
||
products against established technical standards and criteria, and maintains
|
||
the Evaluated Products List. The Evaluated Products List is a compilation of
|
||
all computer products which have undergone formal security evaluations, and
|
||
indicates the relative security merit of each computer product. The criteria
|
||
against which computer systems are evaluated is the Orange Book. This provides
|
||
a metric for distinguishing a range of features and assurances for security
|
||
controls built into automatic data processing system products. The Orange
|
||
Book establishes specific requirements that a computer system must meet in
|
||
order to achieve a specific level of trustworthiness. The levels are arranged
|
||
hierarchically into four major divisions of protection, each with certain
|
||
security-relevant characteristics. These divisions are subdivided into levels
|
||
of trust. In recognition of the complex and technical nature of the issues
|
||
addressed by the Orange Book, the Center has established a Technical
|
||
Guidelines Program. This program augments information provided in the Orange
|
||
Book by publishing additional guidance on issues and features addressed
|
||
therein.
|
||
|
||
TRUSTED PRODUCT SECURITY EVALUATION
|
||
|
||
This section provides the potential computer product vendor with an overview
|
||
of the Center's Trusted Product Evaluation Program. The process of a trusted
|
||
product evaluation is illustrated in Figure One. The Pre-Evaluation Review
|
||
includes the initial contact between the vendor and the National Security
|
||
Agency, the decision-making process to initiate, and the signing of a
|
||
Memorandum of Understanding. Note: subsystem products do not require a
|
||
Memorandum of Understanding but are initiated with a Memorandum of Agreement.
|
||
The Trusted Product Developmental Process provides the vendor the opportunity
|
||
to obtain assistance from the Center during the development of a system or
|
||
network product. The formal product evaluation consists of the actual
|
||
security evaluation of the vendor's computer system. Successful completion of
|
||
this process results in the vendor's computer product being placed on the
|
||
Evaluated Products List.
|
||
|
||
PRE-EVALUATION REVIEW
|
||
|
||
Five milestones in the application process must be reached before the security
|
||
evaluation of a proposed computer product can begin.
|
||
1. Initial Contact
|
||
2. Certificate Pertaining to Foreign Interests
|
||
3. Proposal Package
|
||
4. Program Decision
|
||
5. Memorandum of Understanding (Memorandum of
|
||
Agreement for Subsystems)
|
||
|
||
INITIAL CONTACT
|
||
|
||
The National Security Agency point of contact for the Trusted Product
|
||
Evaluation Program is the Office of Industrial Relations. Interested
|
||
companies are encouraged to call or write to:
|
||
|
||
Director, National Security Agency
|
||
Attention: Office of Industrial Relations
|
||
9800 Savage Road
|
||
Fort George G. Meade, Maryland 20755-6000
|
||
(301) 688-6581
|
||
|
||
CERTIFICATE PERTAINING TO FOREIGN INTERESTS
|
||
|
||
Before submitting an application for the Trusted Product Evaluation Program,
|
||
the Center requires that all companies submit a completed Certificate
|
||
Pertaining to Foreign Interests prior to undertaking the additional effort to
|
||
prepare a proposal package. For those companies that already have a facility
|
||
security clearance, a current DD Form 441s may be sent in lieu of the
|
||
Certificate Pertaining to Foreign Interests. Please submit the certificate or
|
||
DD Form 441s to the Office of Industrial Relations, as listed above.
|
||
|
||
|
||
PROPOSAL PACKAGE
|
||
|
||
After contact has been established, the vendor must prepare a proposal package
|
||
in accordance with the following guidance. Four copies of the proposal package
|
||
are required.
|
||
|
||
This point cannot be over emphasized; information marked Company Proprietary
|
||
is protected to the fullest extent permitted under the law, and must be marked
|
||
accordingly. The product proposal package should demonstrate corporate-level
|
||
support for the product evaluation effort and consist of a company profile,
|
||
market information and a written product proposal.
|
||
|
||
COMPANY PROFILE
|
||
|
||
Potential computer security product vendors, whether requesting a
|
||
system, a network, or a subsystem evaluation, must establish a
|
||
formal working relationship with the Center. Vendors are encouraged
|
||
to submit as much detailed documentation as necessary to establish
|
||
their capability and suitability for the Trusted Product Evaluation
|
||
Program. The company profile portion of the submission shall include
|
||
at least the following information:
|
||
|
||
Company name and address.
|
||
|
||
State of incorporation and composition of ownership.
|
||
|
||
Principal point of contact, a technical point of contact, and a
|
||
public point of contact. For each, include name and title, business
|
||
address, and business telephone. Public point of contact names will
|
||
be placed on a list that can be provided to any requestor desiring
|
||
to establish a business connection with your company.
|
||
|
||
Product or services offered. This could be supplemented with a
|
||
company capabilities brochure.
|
||
|
||
A recent annual or certified financial report.
|
||
|
||
Number of people employed by the company, and in the case of a
|
||
system or network product, the projected size of the team which will
|
||
be developing, enhancing and/or maintaining the proposed product.
|
||
|
||
|
||
MARKET INFORMATION
|
||
|
||
To evaluate the requirements for any proposed product, the vendor must provide
|
||
sufficient detail to identify the utility in the market place. The
|
||
information below covers the minimum market information the Center requires to
|
||
assess the probable need in the community. The market information portion of
|
||
the proposal package shall identify:
|
||
|
||
Intended market by product type and level of trust, including a specific
|
||
customer base and/or firmly established requirements.
|
||
|
||
Portion of markets intended to address. How the specific market
|
||
projections were derived. In cases where the product to be developed is
|
||
a retrofit to existing equipment, include the potential volumne of sales
|
||
for those existing equipments that are already fielded.
|
||
|
||
Known or projected U.S. Government requirements that the product will
|
||
satisfy. Distinguish between DOD and Civil Agency.
|
||
|
||
Known or projected commercial requirements that the product will satisfy.
|
||
|
||
WRITTEN PRODUCT PROPOSAL
|
||
|
||
A separate proposal is required for each computer product submitted for
|
||
security evaluation. These products must be of direct and obvious benefit to
|
||
the information security posture of the nation, and should address the
|
||
applicable requirements outlined in established criteria or interpretations.
|
||
This determination will be based on the information contained in the product
|
||
proposal, measured against national computer security needs and priorities.
|
||
|
||
The Center presently conducts three distinct types of product evaluations: 1)
|
||
the system evaluation, 2) the network evaluation, and 3) the subsystem
|
||
evaluation.
|
||
|
||
Proposals For System Evaluations
|
||
|
||
The Center evaluates as a system that product which
|
||
addresses all of the requirements of a given class of the Orange Book.
|
||
|
||
Although complete information about the proposed product may not
|
||
be available at this stage of the design, the written product proposal should
|
||
provide the following information:
|
||
|
||
Technical description of the product.
|
||
|
||
What is the targeted class or level of trust?
|
||
|
||
What is the operating system for your product?
|
||
|
||
Is the proposed product currently in use? If so, what is the
|
||
current installed base?
|
||
|
||
What is the projected installed base over the nextve years?
|
||
|
||
What is the target development schedule? How flexible is this
|
||
schedule and by what date do you plan to bring this product to
|
||
market?
|
||
|
||
What are the known or projected requirements that the product will
|
||
satisfy? (Distinguish between the Department of Defense and Civil
|
||
Agencies.)
|
||
|
||
What are the differences between and advantages of the proposed
|
||
product relative to similar products which are currently available?
|
||
|
||
|
||
Proposals For Network Evaluations
|
||
|
||
The Center defines a network as everything that is needed to
|
||
accomplish a job, end user to end user. The Center defines a
|
||
network component as any part of a network.
|
||
|
||
The Trusted Network Interpretation of The Trusted Computer System
|
||
Evaluation Criteria (TNI) is currently the criteria against which
|
||
networks are evaluated.
|
||
|
||
Written product proposals should provide the following information:
|
||
|
||
A technical description of the product.
|
||
|
||
What is the underlying security policy of the product?
|
||
|
||
What level of protection is provided by the product?
|
||
|
||
What is the projected schedule for development?
|
||
|
||
What are the environments for which the product is intended?
|
||
Include an overall description of the product. Compare it to
|
||
another product currently available if possible.
|
||
|
||
Does your product interact with users directly? If so, does it
|
||
provide all of the functionality identified at one of the criteria
|
||
levels in Part I of the TNI, or only a subset?
|
||
|
||
If it is a network system, what level of trust does it meet
|
||
according to Part I of the TNI?
|
||
|
||
If it is a network component, which of the following
|
||
functionalities does it provide, and at which level of trust is
|
||
each functionality provided?
|
||
|
||
Mandatory Access Control
|
||
|
||
Discretionary Access Control
|
||
|
||
Identification and Authenication
|
||
|
||
What other security services mentioned in Part II of the TNI does
|
||
your product provide?
|
||
|
||
What type of carrier medium, if any, is used or supported
|
||
by your product?
|
||
|
||
Proposals For Subsystem Evaluations
|
||
|
||
The Center defines a computer security subsystem as a physical device or
|
||
software mechanism which is added to a computer system to enhance the computer
|
||
security functionality of the overall system.
|
||
|
||
To be considered for a subsystem evaluation, a company must have an existing
|
||
product which is designed to provide one or more of the following
|
||
capabilities, as described in the Trusted Computer System Evaluation Criteria:
|
||
|
||
1) mandatory access control;
|
||
|
||
2) audit;
|
||
|
||
3) discretionary access control;
|
||
|
||
4) identification and authentication; or.
|
||
|
||
5) object re-use.
|
||
|
||
Written product proposals should provide the following information:
|
||
|
||
|
||
A technical description of the product.
|
||
|
||
Which of the five subsystem functionalities does the product
|
||
implement?
|
||
|
||
|
||
What is the current installed base? What is the projected installed
|
||
base over the next five years?
|
||
|
||
What is the current or projected market for your product (to include
|
||
specific customer base and/or firmly established requirements, if
|
||
possible)? What portion of this market do you intend to address?
|
||
How were the specific market projections derived?
|
||
|
||
What are the known or projected requirements that the product will
|
||
satisfy? (Distinguish between the Department of Defense and Civil
|
||
Agencies.)
|
||
|
||
What are the differences between and advantages of the proposed
|
||
product relative to similar products which are currently available?
|
||
|
||
PROGRAM DECISION
|
||
|
||
Upon receipt of the company's proposal package, the Office of Industrial
|
||
Relations will send the company written notification that the package has been
|
||
received and is under consideration. The proposal will be reviewed to
|
||
determine its value while assessing the capabilities of the company, the
|
||
utility of the product to the Federal Government, and the degree to which the
|
||
product addresses the technical aspects of computer security. The
|
||
availability of adequate Center resources to support the evaluation program is
|
||
also a prime consideration in the program decision. The Center may need to
|
||
meet with the vendor's technical experts to ensure decision making processes
|
||
are based on sound technical understanding of the product. When a decision is
|
||
reached, the Office of Industrial Relations will notify the vendor in writing
|
||
whether the product has been accepted for evaluation. System and network
|
||
evaluations will enter into the Trusted Product Developmental Process as
|
||
described below. Subsystem evaluations enter directly into the formal
|
||
evaluation.
|
||
|
||
|
||
MEMORANDUM OF UNDERSTANDING
|
||
|
||
|
||
If a package for a system or network product is accepted, a Memorandum of
|
||
Understanding is executed between the vendor and the National Security Agency.
|
||
The purpose and function of the Memorandum of Understanding is to establish a
|
||
legal relationship between the National Security Agency and the potential
|
||
vendor in which:
|
||
|
||
The National Security Agency agrees to provide necessary and
|
||
relevant computer security information and guidance to the potential
|
||
vendor.
|
||
|
||
The vendor agrees to provide the National Security Agency the
|
||
information necessary to assess the security of the proposed
|
||
product.
|
||
|
||
The vendor agrees to follow the intent and requirements of the
|
||
procedures leading to a system, network or subsystem evaluation.
|
||
|
||
|
||
The National Security Agency agrees to protect vendor proprietary
|
||
information which is provided under the Memorandum of Understanding.
|
||
|
||
Both parties agree to review the continuation and terms of the
|
||
Memorandum of Understanding periodically.
|
||
|
||
A program manager within the Requirements and Resources Division at the Center
|
||
will be assigned to monitor and coordinate technical and/or administrative
|
||
responses to the vendor, and a technical point of contact within the Product
|
||
Evaluation Division will be identified to the vendor. To determine the
|
||
division and class at which all requirements are met by a computer system, the
|
||
system must be evaluated against the Orange Book. This security evaluation
|
||
will be conducted by a Center evaluation team.
|
||
|
||
|
||
TRUSTED PRODUCT DEVELOPMENTAL PROCESS
|
||
|
||
|
||
The primary thrust of this phase is an in-depth examination of a
|
||
vendor's design either for a new trusted product (system or network) or for
|
||
security enhancements to an existing product.It is intended to ensure that the
|
||
product is actually ready for evaluation with all necessary evidence available
|
||
so the evaluation can be completed without delays for additional development
|
||
or evidence generation. This phase is based primarily on design documentation
|
||
and information supplied by the vendor, and it involves little or no "hands
|
||
on" use of the product.
|
||
|
||
This phase results in the production of an Initial Product Assessment Report.
|
||
This report documents the evaluation team's understanding of the system based
|
||
on the information presented by the vendor, and assigns a candidate Orange
|
||
Book class rating to the system. The candidate rating is an estimate of the
|
||
highest class for which the product has displayed some evidence for each of
|
||
the requirements in the Orange Book.
|
||
|
||
The Center's Technical Review Board provides a consistency check on the
|
||
application of the Orange Book requirements, and ensures the product is ready
|
||
for evaluation. Because the Initial Product Assessment Report does not
|
||
represent a complete analysis of the computer product and may contain
|
||
proprietary information, distribution is restricted to the respective vendor
|
||
and the Center.
|
||
|
||
|
||
SYSTEM AND NETWORK FORMAL EVALUATIONS
|
||
|
||
|
||
To enter this formal evaluation phase, the design of a computer system must be
|
||
finalized and marketable. In addition, the product release being evaluated
|
||
must not undergo any additional development. Once the product is accepted for
|
||
evaluation, a Memorandum of Agreement is signed between the Center and the
|
||
vendor, to address the formal aspects of the product receiving an Evaluated
|
||
Products List rating and the accompanying responsibilities.
|
||
|
||
At the start of this phase, a Product Bulletin is released by the enter
|
||
announcing the evaluation. The Product Bulletin is a brief description of the
|
||
computer system undergoing security evaluation, and includes the candidate
|
||
rating of the system.
|
||
|
||
The evaluation phase is a detailed analysis of the hardware and software
|
||
components of a system, all system documentation, and a mapping of the
|
||
security features and assurances to the Orange Book.<2E> The analysis performed
|
||
during this phase requires "hands on" testing (i.e., functional testing and,
|
||
if applicable, penetration testing).
|
||
|
||
The evaluation phase leads to the Center publishing a Final Evaluation Report
|
||
and an Evaluated Products List entry. The Final Evaluation Report is a summary
|
||
of the security evaluation and includes the Evaluated Products List rating,
|
||
which is the final class at which the product successfully met all Orange Book
|
||
requirements in terms of both security features and assurances. The Final
|
||
Evaluation Report and the Evaluated Products List entry are made public. The
|
||
evaluation process represents a firm commitment from the vendor, and at its
|
||
completion the product will receive a rating from the Center.
|
||
|
||
|
||
SUBSYSTEM FORMAL EVALUATIONS
|
||
|
||
|
||
While the Center devotes much of its resources to encouraging the production
|
||
and use of multipurpose trusted computer systems, there is a recognized need
|
||
for guidance on, and security evaluation of, supplementary computer security
|
||
products. These subsystems may not meet all of the security feature,
|
||
architecture, or assurance requirements of any one security class or level of
|
||
the Orange Book. To meet this need, the Center has established the subsystem
|
||
evaluation process.
|
||
|
||
The goal of the Center's subsystem evaluations is to provide computer
|
||
installation managers with information on subsystems that would be helpful in
|
||
providing immediate computer security improvements in existing installations.
|
||
Once a subsystem product is accepted for evaluation, a Memorandum of Agreement
|
||
is signed between the Center and the vendor, addressing the formal aspects of
|
||
the product being included in the Evaluated Products List and the accompanying
|
||
responsibilities.
|
||
|
||
Subsystems are special-purpose products which can be added to existing
|
||
computer systems to increase some aspect of security and have the potential of
|
||
meeting automatic data processing security needs. For the most part, the scope
|
||
of a subsystem evaluation is limited to consideration of the subsystem itself,
|
||
and does not address or attempt to rate the overall security of the processing
|
||
environment or computer system on which the subsystem may be implemented. To
|
||
promote consistency in evaluations, an attempt is made to assess a subsystem's
|
||
security-relevant performance in light of applicable standards and features
|
||
outlined in the Orange Book. In addition, the evaluation team reviews the
|
||
vendor's claims and documentation for obvious flaws which would violate the
|
||
product's security features, and verifies, through functional testing, that
|
||
the computer product performs as advertised. Upon completion, a summary of the
|
||
Final Evaluation Report will be placed on the Evaluated Products List.
|
||
|
||
The Final Evaluation Report will not assign a specific rating to the computer
|
||
product, but will provide an assessment of the product's effectiveness and
|
||
usefulness in increasing computer security. The Final Evaluation Report and
|
||
the Evaluated Products List entry are made public.
|
||
|
||
EVALUATED PRODUCTS LIST
|
||
|
||
The Evaluated Products List provides computer users, managers and security
|
||
officials, an authoritative and unbiased security evaluation of a computer
|
||
system's suitability for use in processing classified and sensitive
|
||
information. All products on the Evaluated Products List have been evaluated
|
||
against the established criteria and interpretations. A Final Evaluation
|
||
Report is issued for all products. The rating given to a system product is
|
||
the highest class for which all the requirements in the Orange Book have been
|
||
met. Trusted product security evaluation results are published in formal
|
||
reports available from either the Government Printing Office or the National
|
||
Technical Information Service.
|
||
|
||
The overall evaluation class ratings given in the Evaluated Products List
|
||
apply only to the specific hardware/software configurations listed. As such,
|
||
the rating indicates that the product met or exceeded each of the individual
|
||
requirements for the overall Evaluation Class. Although the computer product
|
||
was subjected to the detailed security testing specified in the Orange Book,
|
||
it must be emphasized that such testing is not sufficient to guarantee the
|
||
absence of flaws in the product. The Evaluated Products List entry does not
|
||
constitute a general or overall endorsement of the product by the government,
|
||
nor does it constitute a Department of Defense certification or accreditation
|
||
of the trusted computer product for use in classified or sensitive
|
||
unclassified processing environments. Rather, the security evaluation
|
||
provides an essential part of the technical evidence required for follow on
|
||
certification and accreditation. Ultimate responsibility for the continuing
|
||
integrity provided by the security mechanisms of any trusted computer product
|
||
evaluated by the Center rests solely with the vendor. The Evaluated Products
|
||
List, which documents evaluated computer products, is available to vendors to
|
||
actively market and advertise the overall evaluation class rating achieved by
|
||
their products to procurement authorities and the general public.
|
||
|
||
The Evaluated Products List contains entries for general-purpose operating
|
||
systems, add-on packages, and subsystems. Product Bulletins, which are
|
||
synopses of computer systems currently undergoing formal security evaluations
|
||
by the Center, are also included on the Evaluated Products List.
|
||
|
||
A hard copy of the Evaluated Products List is included in the Information
|
||
Systems Security Products and Services Catalogue. This catalogue is updated
|
||
quarterly and is available through the Government Printing Office.
|
||
|
||
|
||
|
||
RATINGS MAINTENANCE PHASE
|
||
|
||
The Ratings Maintenance Phase provides a mechanism to ensure the validity of a
|
||
previous rating for a new version of an evaluated computer system product. As
|
||
enhancements are made to the computer product the Ratings Maintenance Phase
|
||
ensures that the level of trust is not degraded. A complete re-evaluation is
|
||
required to achieve a higher rating.
|
||
|
||
The Ratings Maintenance Phase is designed to keep the Evaluated Products List
|
||
current. This is accomplished by using the personnel involved in the
|
||
maintenance of the product to manage the change process and reduce the effort
|
||
required to extend the rating.
|
||
|
||
Success of the Ratings Maintenance Phase depends upon the development of a
|
||
cadre of vendor personnel with a strong technical knowledge of computer
|
||
security and of their computer product. These trained personnel will oversee
|
||
the vendor's computer product modification process. They will certify to the
|
||
Center that any modifications or enhancements applied to the product will
|
||
preserve the security mechanisms and maintan the assurances.
|
||
|
||
The Ratings Maintenance Phase is initially designed for C1 - B1 level of trust
|
||
systems. As experience is gained in the program, the intent is to extend to
|
||
higher level systems and to networks.
|
||
|
||
|
||
|
||
EVALUATION SUPPORT SERVICES
|
||
|
||
The Center supports the trusted product security evaluation process within the
|
||
Trusted Product Evaluation Program. The following specialized technical
|
||
services are available to benefit the interactive relationship between the
|
||
computer product vendors and the technical staff of the Center. To obtain
|
||
these services or to gain more insight into their particular detail, refer to
|
||
the Points of Contact section.
|
||
|
||
DOCKMASTER
|
||
|
||
|
||
DOCKMASTER is an unclassified computer system used by the Center for the
|
||
nationwide dissemination and exchange of computer security information.
|
||
DOCKMASTER serves the entire information security community including the
|
||
Federal Government, universities, and private industry. It can distribute
|
||
electronic mail via connections to the ARPANET. DOCKMASTER is accessible
|
||
by direct dial, the MILNET, and McDonnell Douglas Tymnet network.
|
||
|
||
DOCKMASTER is the primary means of communications between the vendor and
|
||
the Center throughout the computer product security evaluation process.
|
||
It allows vendors to use electronic mail, file transfer protocols, and
|
||
the Forum subsystem. Forum is an on-line, interactive meeting facility
|
||
that permits an individual to "meet" with other users through the use of
|
||
a computer terminal.
|
||
|
||
VERIFICATION TOOLS
|
||
|
||
|
||
Vendors who are developing systems that are targeted to meet the
|
||
class A1 requirements of the Orange Book must provide assurance that the
|
||
system implementation is consistent with the system's design. This
|
||
assurance is gained by developing a Formal Top Level Specification of the
|
||
design and verifying that the specifications are consistent with the
|
||
formal security policy model (the security requirements) for the system.
|
||
After the design verification has been completed, an informal mapping is
|
||
performed from the Formal Top Level Specification to the implementation.
|
||
This completes the evidence. Formal Top Level Specification development
|
||
and subsequent verification is a rigorous, mathematical process that can
|
||
be greatly aided by the use of automated verification tools. The Orange
|
||
Book requires the use of such a tool in the verification of A1 systems:
|
||
"This verification evidence shall be consistent with that provided within
|
||
the state-of-the-art of the particular Center endorsed formal
|
||
specification and verification system used."
|
||
|
||
The Center endorsed verification tools are maintained on the
|
||
Endorsed Tools List. Examples of these verification tools are Formal
|
||
Development Methodology, Gypsy, and Enhanced Hierarchical Development
|
||
Methodology. For information concerning the current entries on the
|
||
Endorsed Tools List, vendors should contact the Computer Hardware and
|
||
Software Support Division.
|
||
|
||
|
||
TECHNICAL GUIDELINES
|
||
|
||
To complement the information contained in the Orange Book, the Center
|
||
publishes technical guidelines which serve as additional guidance in
|
||
interpreting the established standard. These technical guidelines aid in the
|
||
evaluation and selection of computer security products, both complete systems
|
||
and subsystems. In addition, they are used throughout the Federal Government
|
||
and by Federal Government contractors as guidance for the procurement, use,
|
||
and disposal of automation systems and their associated magnetic storage
|
||
media.
|
||
|
||
The Technical Guidelines Program contributes to the technical literature on
|
||
issues of computer security. Guidelines are written in response to
|
||
demonstrated need in automated processing environments.
|
||
|
||
Participation in the development of technical guidelines is provided by the
|
||
technical staff of the Center and its associated offices within the National
|
||
Security Agency, by representatives of the Department of Defense and the
|
||
Intelligence Community, by civil agencies of the Federal Government, by
|
||
Federally Funded Research and Development Centers, by contracted analytic and
|
||
technical firms, and by selected experts in the particular field of endeavor.
|
||
Draft versions of proposed documents are extensively reviewed by a wide
|
||
audience of interests, and comments are fielded for consideration before
|
||
publication.
|
||
|
||
PUBLICATIONS
|
||
|
||
Technical guidelines that are published by the Center, and useful to a vendor
|
||
in order to process a computer product through the Trusted Product Evaluation
|
||
Program, will be provided in limited quantity by the INFOSEC Awareness
|
||
Organization.
|
||
|
||
TRAINING
|
||
|
||
The Center provides training on topics of major importance to vendors
|
||
interested in the trusted product security evaluation process.
|
||
|
||
OTHER RELATED SERVICES
|
||
|
||
Within the Information Security Organization, there are several separate but
|
||
complementary programs which relate to the Trusted Product Evaluation Program.
|
||
A brief description of each program is provided in subsequent paragraphs. For
|
||
more details, please contact the specific program office in the Points of
|
||
Contact list.
|
||
|
||
Like the Trusted Product Evaluation Program, the Commercial Communications
|
||
Security Endorsement Program is a business relationship which combines private
|
||
sector leadership and expertise in equipment design, development and high
|
||
volume production with the information security expertise of the National
|
||
Security Agency. Specifically, this program is designed to encourage industry
|
||
to embed United States Government proprietary cryptography into
|
||
telecommunications products to meet the need to protect its classified and
|
||
sensitive unclassified information. The Commercial Communications Security
|
||
Endorsement Program products that are endorsed for protecting sensitive
|
||
unclassified government information only are also available to the private
|
||
sector. In today's computer networking environment, many products require both
|
||
an encryption capability and a trusted computing base to meet user
|
||
requirements. Companies whose products merge both communications and computer
|
||
security disciplines are encouraged to become familiar with the requirements
|
||
of the Commercial Communications Security Endorsement Program.
|
||
|
||
The Secure Data Network System Program was established in August 1986, when
|
||
the National Security Agency joined in partnership with ten major
|
||
telecommunications and computer companies to develop a security architecture
|
||
and a user-friendly key management system using the Open Systems
|
||
Interconnection model.<2E> The ultimate goal of the Secure Data Network System
|
||
Program is to provide for the development of information security products
|
||
that can operate over a broad range of commercial data networks. Once the
|
||
Secure Data Network System architecture is formalized, the development of
|
||
Secure Data Network System products will be carried out under the auspices of
|
||
the Commercial Communications Security Endorsement Program.
|
||
|
||
The Industrial TEMPEST Program is designed to aid industry in developing and
|
||
testing TEMPEST-suppressed equipment which can be offered for sale to the
|
||
United States Government. Companies developing trusted computing products
|
||
should be aware that the United States Government may require that products
|
||
protecting classified information be TEMPEST-suppressed.
|
||
|
||
A company that produces computer security products may be interested in the
|
||
Department of Treasury's Electronic Funds Transfer Certification Program if
|
||
the primary function of its product is to provide message authentication in
|
||
support of United States Government financial transactions. The program
|
||
specifically provides for testing, evaluating and certifying Message
|
||
Authentication Code devices for Federal electronic funds transfer use in
|
||
accordance with American National Standards Institute Standard X9.9. In
|
||
addition, elements of Federal Standard 1027 covering minimum general security
|
||
requirements for implementing the Data Encryption Standard encryption
|
||
algorithm are included. Optional electronic key management is based on
|
||
American National Standards Institute Standard X9.17.
|
||
|
||
Vendors who are developing trusted computer products as Independent Research
|
||
and Development Projects may obtain technical assistance and technical plan
|
||
evaluations by contacting the Center's Office of Computer Security Research
|
||
and Development.
|
||
|
||
The Computer Security Technical Vulnerability Reporting Program, promulgated
|
||
in Department of Defense Instruction 5215.2 in September 1986, provides a
|
||
mechanism for reporting weaknesses or design deficiencies in hardware,
|
||
firmware, or software that leave automated information systems open to
|
||
potential exploitation. Technical vulnerabilities reported in Evaluated
|
||
Products List items could possibly change the overall rating of the product.
|
||
|
||
Points of Contact
|
||
|
||
COMMERCIAL COMMUNICATIONS SECURITY ENDORSEMENT PROGRAM
|
||
|
||
Director, National Security Agency
|
||
Attention: Office of Industrial Relations
|
||
9800 Savage Road
|
||
Fort George G.Meade, MD 20755-6000
|
||
(301) 688-6581
|
||
|
||
TRUSTED PRODUCT EVALUATION PROGRAM
|
||
Director,National Security Agency
|
||
Attention: Office of Industrial Relations
|
||
9800 Savage Road
|
||
Fort George G.Meade, MD 20755-6000
|
||
(301) 688-6581
|
||
|
||
COMPUTER SECURITY TECHNICAL VULNERABILITY REPORTING PROGRAM
|
||
Director,National Security Agency
|
||
Attention: Vulnerability Reporting Program
|
||
9800 Savage Road
|
||
Fort George G. Meade, MD 20755-6000
|
||
(301) 688-6079
|
||
|
||
DEPARTMENT OF TREASURY'S ELECTRONIC FUNDS TRANSFER CERTIFICATION PROGRAM
|
||
Assistant Director, Security Programs
|
||
Department of Treasury
|
||
15th and Pennsylvania Avenue NW
|
||
Washington, DC 20220
|
||
(202) 566-5152
|
||
|
||
DOCKMASTER AND VERIFICATION TOOLS
|
||
National Computer Security Center
|
||
Attention: Computer Hardware and Software Support Division
|
||
9800 Savage Road
|
||
Fort George G. Meade, MD 20755-6000
|
||
(301) 859-4360
|
||
|
||
|
||
INDEPENDENT RESEARCH AND DEVELOPMENT PROJECTS PROGRAM
|
||
National Computer Security Center
|
||
Attention: Office of Computer Security Research and
|
||
Development
|
||
9800 Savage Road
|
||
Fort George G.Meade, MD 20755-6000
|
||
(301) 859-4486
|
||
|
||
INDUSTRIAL TEMPEST PROGRAM
|
||
Ford Aerospace and Communications Corporation
|
||
Attention: Mail Stop 3 (Industrial TEMPEST Program)
|
||
7170 Standard Drive
|
||
Hanover, MD 21076
|
||
(301) 796-5254
|
||
|
||
PUBLICATIONS AND TRAINING
|
||
Superintendent of Documents
|
||
U.S. Government Printing Office
|
||
ashington, DC 20402
|
||
(202) 783-3238
|
||
|
||
U.S. Department of Commerce
|
||
National Technical Information Service
|
||
5285 Port Royal Road
|
||
Springfield, VA 22161
|
||
(703) 487-4650
|
||
|
||
SECURE DATA NETWORK SYSTEM PROGRAM
|
||
Director, National Security Agency
|
||
Attention: Secure Data Network Systems SPO
|
||
9800 Savage Road
|
||
Fort George G. Meade, MD 20755-6000
|
||
(301)668-7110
|
||
|
||
TECHNICAL GUIDELINES
|
||
National Computer Security Center
|
||
Attention: Technical Guidelines Division
|
||
9800 Savage Road
|
||
Fort George G. Meade, MD 20755-6000
|
||
|
||
|
||
|
||
REFERENCES
|
||
|
||
|
||
DoD 3204.1, Independent Research and Development, Under Secretary of Defense
|
||
for Research and Engineering, 1 December 1983.
|
||
|
||
|
||
DoD Directive 5200.28, Security Requirements for Automatic Data Processing
|
||
(ADP) Systems, revised April 1978.
|
||
|
||
DoD 5200.28-STD, Department of Defense Standard, Department of Defense Trusted
|
||
Computer System Evaluation Criteria, December 1985; supersedes CSC-STD-001,
|
||
dated 15 August 1983.
|
||
|
||
DoD Directive 5215.1, Computer Security Evaluation Center, 25 October 1982.
|
||
|
||
DoD Instruction 5215.2, Computer Security Technical Vulnerability Reporting
|
||
Program, 2 September 1986.
|
||
|
||
National Telecommunications and Information System Security Policy No. 200,
|
||
National Policy on Controlled Access Protection Policy, 15 July 1987.
|
||
|
||
NCSC-TG-005 Version 1, Trusted Network Interpretation of The Trusted Computer
|
||
System Evaluation Criteria, 31 July 1987.
|
||
|
||
|
||
ATTACHMENT I
|
||
|
||
SPECIFICATIONS AND DESIGN DOCUMENTATION
|
||
|
||
When a vendor enters into a product evaluation, he must present evidence that
|
||
his system and its design meets the appropriate criteria requirements.
|
||
Examples of the type of evidence normally submitted to support an evaluation
|
||
include the design specifications that explain the security mechanisms, the
|
||
Trusted Computing Base (TCB) arguments that show how the TCB is tamperproof,
|
||
always invoked and small enough to be analyzed. Also, the model (or
|
||
philosophy of protection) and how it relates to the implementation are
|
||
important parts of the evidence. The best test of evidence is that it must
|
||
include all the information such that a new team that is basically unfamiliar
|
||
with the product could evaluate only the evidence and reach the proper
|
||
conclusion.
|
||
|
||
In order for the evaluation team to review this evidence and determine whether
|
||
the system complies with these requirements, the team must develop a
|
||
conceptual understanding of how the system being evaluated operates.
|
||
Generally, the evaluation team can acquire this level of understanding by
|
||
reviewing the vendor's system documentation and specifications. The following
|
||
types of high level system documents are typically required by the evaluation
|
||
team:
|
||
|
||
User-Level Documentation
|
||
|
||
Provides users an overview of the system, its functioning, and
|
||
information on user services.
|
||
|
||
Operational Manuals
|
||
|
||
Contains general description,implementation and usage information
|
||
for the system. It is intended for use by system programmers who
|
||
service the system.
|
||
|
||
Program Logic Manuals
|
||
|
||
Documents the internal operation and organization of a system. It
|
||
is intended for use by system programmers for program maintenance
|
||
and to determine the location of program malfunctions.
|
||
|
||
Administrative Manuals
|
||
|
||
Documents the procedures for installing and generating the system.
|
||
|
||
Hardware and Software System Specifications
|
||
|
||
Includes Hardware and Software design and implementation details of
|
||
the system major components
|
||
|
||
|
||
ATTACHMENT II
|
||
|
||
TEST PLANNING
|
||
|
||
The Department of Defense Trusted Computer System Evaluation Criteria (Orange
|
||
Book) requires that vendors provide a document to the evaluators that
|
||
describes the test plan, test procedures, and the results of the security
|
||
mechanisms functional testing. Security mechanisms are those mechanisms that
|
||
are relevant to the Orange Book. These include object reuse, labeling,
|
||
discretionary access control (DAC), mandatory access control (MAC),
|
||
identification and authentication, auditing, and trusted path. A security
|
||
related functional test plan should determine whether the system being
|
||
evaluated has any design and implementation flaws that would permit a subject
|
||
external to the Trusted Computing Base (TCB) to read, change, or delete data
|
||
which he would not normally have access to under the mandatory or
|
||
discretionary security policy enforced by the TCB. [The TCB is defined by the
|
||
TCSEC as "the totality of protection mechanisms within a computer system --
|
||
including hardware, firmware, and software --the combination of which is
|
||
responsible for enforcing a security policy"]. Security related functional
|
||
tests involve all security properties of a system (i.e., all aspect of the TCB
|
||
that affect or can be affected by a security mechanism).
|
||
|
||
COVERAGE OF TESTING
|
||
|
||
Although many standard testing methods are acceptable in fulfilling the Orange
|
||
Book testing requirements, they are, for all but very small or simplistic
|
||
systems, impractical to use due to the large amount of resources required.
|
||
Some methods of testing that have in the past proven to be sufficient and were
|
||
reasonable to implement are Interface and Mechanism testing.
|
||
|
||
Interface testing refers to testing the TCB at the user interface (i.e., user
|
||
callable routines). Generally, critical boundaries of each security mechanism
|
||
are determined and test cases on both sides of these boundaries are generated.
|
||
The critical boundary of a security mechanism is the point at which the rule
|
||
it is designed to implement is or is not invoked. This provides more
|
||
assurance that the view of the system presented to a user is correct.
|
||
|
||
Mechanism testing refers to the testing of the security mechanisms that the
|
||
TCB supports (i.e., DAC , object reuse, audit, etc.). Mechanism can consist
|
||
of one or more interface, and some interfaces can be called by different
|
||
mechanisms. Mechanism testing shows that the TCB supports these mechanisms.
|
||
The sufficiency of the different methods of testing are dependent on the
|
||
particular class of the Orange Book the system is being evaluated against.
|
||
|
||
|
||
TESTING A B2-A1 SYSTEM:
|
||
|
||
TCB interface testing is sufficient. Every interface must be tested. Since
|
||
B2, B3 or A1 systems are well structured, and their Detailed Top Level
|
||
Specifications (DTLS) and Formal Top Level Specifications (FTLS) provide a
|
||
complete and accurate description of the TCB interface, the testing of the TCB
|
||
interfaces can reasonably be expected to be very comprehensive.
|
||
|
||
TESTING A C1-B1 SYSTEM:
|
||
|
||
Mechanism testing is probably sufficient. The structure allowed by a C1-B1
|
||
architecture would most likely make interface testing impractical. It is
|
||
likely that an evaluation team may determine, through inspection of the
|
||
system's test plan and its architecture, that black box testing of the
|
||
interface is insufficient and requires "white box" testing of instrumental
|
||
code sections.
|
||
|
||
DOCUMENTATION
|
||
|
||
Documentation of a test should be specific and briefly describe the TCB
|
||
mechanism being tested. The expected results of each test case should be set
|
||
forth. The test documentation should also contain an overview of the test
|
||
methods being used, and the security properties which are and are not
|
||
pertinent for each particular mechanism. A list of all assumptions being made
|
||
about the testing environment should also be included .
|
||
|
||
The Orange Book functional testing requirements also require that both the
|
||
system and the test plan be maintained using good configuration management
|
||
techniques. This allows the vendor to provide a form of Life-cycle assurances
|
||
for the system. Life-cycle assurance is a procedure for managing system
|
||
design, development, and maintenance using a method of rigorous and formalized
|
||
controls and standards. It allows the vendor to reevaluate the system when
|
||
changes are made to determine whether the integrity of the protection
|
||
mechanism has been affected
|
||
|
||
|
||
ATTACHMENT III
|
||
|
||
|
||
REQUIRED DOCUMENTATION
|
||
|
||
The Orange Book requires that a vendor produce documentation which describes
|
||
the system protection mechanisms, how the system can operate using these
|
||
protection mechanisms, how the system developer designed security into the
|
||
system, and how these security features and system were tested. The amount of
|
||
documentation required increases with the targeted Orange Book class. The
|
||
specific requirements are listed below starting at the lower Orange Book
|
||
classes and progressing through the higher classes. In some cases, additional
|
||
documentation may be required
|
||
|
||
C1 - DISCRETIONARY ACCESS CONTROL
|
||
|
||
Security Features User's Guide tells users how to use the security mechanisms
|
||
of the system. It provides the necessary information to understand and
|
||
effectively use the discretionary access control mechanisms to protect
|
||
information.
|
||
|
||
Trusted Facility Manual tells the system administrator how to set the system
|
||
up so that it stays secure. It should tell the administrator how to select
|
||
the proper options such that the system is operated in a mode that meets the
|
||
requirements of the Criteria. If there are unsecure modes that the system can
|
||
run in, the manual should clearly state their impact on the security and
|
||
include warnings as appropriate. This manual should also include any
|
||
procedures the administrator should use during operations to maintain
|
||
security. If any of the hardware/software features require administrator
|
||
actions to complete the security protection, they should be thoroughly
|
||
described.
|
||
|
||
Test Documentation describes results of security mechanism's functional
|
||
testing. This documentation is used by the evaluation team to assess the
|
||
testing performed by the vendor. This document describes those tests, how
|
||
they are run, and how to properly interpret the results.
|
||
|
||
Design documentation provides the rationale and supporting evidence for the
|
||
security of the design of the system. The descriptive specifications are
|
||
included in this evidence. It is intended to provide the sort of information
|
||
a new developer would need in order to support the system. It should include
|
||
the manufacturer's philosophy of protection. If the TCB consists of distinct
|
||
modules, the design documentation describes the interfaces between these
|
||
modules.
|
||
|
||
C2 - CONTROLLED ACCESS PROTECTION
|
||
|
||
Security Features User's Guide remains the same as C1.
|
||
|
||
Trusted Facility Manual is the same as C1, but also requires details on how to
|
||
maintain audit data.
|
||
|
||
Test Documentation remains the same as C1.
|
||
|
||
Design Documentation is the same as C1.
|
||
|
||
B1 - MANDATORY PROTECTION
|
||
|
||
Security Features User's Guide remains the same as C2., but also describes the
|
||
additional security mechanisms required at this class (i.e., Mandatory Access
|
||
Control).
|
||
|
||
Trusted Facility Manual remains the same as C2, but also describes the
|
||
operator and administrator functions related to security. This includes an
|
||
explanation of what's involved in changing the security characteristics of a
|
||
user, and a description of facility procedures, warnings, and privileges that
|
||
need to be controlled in order to operate the facility in a secure manner.
|
||
|
||
Test Documentation remains the same as C2.
|
||
|
||
Design Documentation remains the same as C2, but also describes the security
|
||
policy model (either formally, i.e., mathematically, or informally, i.e., in
|
||
English) and how the TCB implements this model.
|
||
|
||
B2 - STRUCTURED PROTECTION
|
||
|
||
Security Features User's Guide remains the same as B1, but also describes the
|
||
additional security mechanisms required by this class (i.e., Trusted Path).
|
||
|
||
Trusted Facility Manual remains the same as B1, but also details what
|
||
constitutes the TCB and how it can be modified. It also describes how
|
||
separate operator and administrator functions need to be supported.
|
||
|
||
Test Documentation remains the same as B1, but includes the results of covert
|
||
channel tests. Covert channels are communication paths that allow a process
|
||
to transfer information in a manner that violates the system's security
|
||
policy.
|
||
|
||
Design Documentation remains the same as B1, but also includes a formal
|
||
description of the model, and proof that it is sufficient for the policy. It
|
||
will also describe how the TCB implements the reference monitor concept and
|
||
how it enforces the principle of least privilege.
|
||
|
||
B3 - SECURITY DOMAINS
|
||
|
||
Security Features User's Guide remains the same as B2, but also describes the
|
||
additional security mechanisms required at this class .
|
||
|
||
Trusted Facility Manual remains the same as B2, but also includes a
|
||
description on how to start up and restore the system security. It also
|
||
describes the role of the Security Administrator.
|
||
|
||
Test Documentation remains the same as B2.
|
||
|
||
Design Documentation remains the same as B2, but also includes the
|
||
correspondence between the Detailed Top Level Specifications and the TCB. The
|
||
TCB implementation is also shown to be informally consistent with the Detailed
|
||
Top Level Specifications.
|
||
|
||
A1 - VERIFIED PROTECTION
|
||
|
||
Security Features Users's Guide remains the same as B3.
|
||
|
||
Trusted Facility Manual remains the same as B3.
|
||
|
||
Test Documentation remains the same as B3, but also includes the results of
|
||
the mapping between the Formal Top Level Specifications and the TCB source
|
||
code.
|
||
|
||
Design Documentation remains the same as B3, but also includes a description
|
||
of the components that are strictly internal to the TCB. It also includes a
|
||
Formal Top Level Specification to TCB correspondence.
|
||
|
||
|