Path: senator-bedfellow.mit.edu!faqserv

Path: senator-bedfellow.mit.edu!faqserv
From: Trusted Product Evaluation Program <[email protected]>
Newsgroups: comp.security.misc,comp.security.unix,comp.answers,news.answers
Subject: Computer Security Evaluation FAQ, Version 2.1
Supersedes: <computer-security/[email protected]>
Followup-To: poster
Date: 18 Feb 1998 11:03:28 GMT
Organization: Trusted Product Evaluation Program
Lines: 1148
Approved: [email protected]
Expires: 3 Apr 1998 10:52:15 GMT
Message-ID: <computer-security/[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: penguin-lust.mit.edu
X-Last-Updated: 1996/08/13
Originator: [email protected]
Xref: senator-bedfellow.mit.edu comp.security.misc:44555 comp.security.unix:44440 comp.answers:30140 news.answers:123639

Posting-Frequency: monthly
Archive-name: computer-security/evaluations

The Computer Security Evaluation Frequently Answered Questions (V2.1)

This FAQ is designed to answer common questions about the evaluation of
trusted products. It is being posted to comp.security.misc
comp.security.unix, comp.answers and news.answers. We have attempted to be as
clear, precise, accurate, and correct as possible. Some answers are
undoubtedly closer to this ideal than others. Comments on the FAQ may be sent
to [email protected]. The current official version of this FAQ may be
found at <http://www.radium.ncsc.mil/tpep/process/faq.html>.

----------

Subject: Contents

Section I: The Trusted Product Evaluation Program (TPEP)
1. What is the National Computer Security Center (NCSC)?
2. What is TPEP?
3. How is TPEP related to the National Security Agency (NSA)?
4. How is TPEP related to the National Institute of Standards
and Technology (NIST)?
5. How do I contact the TPEP?
6. What is the TTAP?
7. What is Dockmaster?
8. Why doesn't TPEP have a WWW server on Dockmaster?
Section II: Criteria
1. What is the criteria used for evaluation?
2. What is the TCSEC?
3. What is the Orange Book?
4. What are interpretations?
5. What is the Interpreted TCSEC (ITCSEC)?
6. What is the ITSEC (as opposed to the ITCSEC)?
7. What is the CTCPEC?
8. What is the Common Criteria?
9. What is the TNI?
10. What is the TDI?
11. What is the Rainbow Series?
12. What are Process Action Team (PAT) Guidance Working Group (PGWG)
documents?
13. Is there a criteria for commercial (as opposed to military) systems?
14. What is the Federal Criteria?
15. What are the CMWREQs and the CMWEC?
Section III: Criteria Concepts
1. What are security features?
2. What is assurance?
3. What is a division?
4. What is a class?
5. What is a network component?
6. What is a Network Security Architecture Design (NSAD) document?
7. How do I interpret a rating?
8. The TCSEC is 10 years old, doesn't that mean it's outdated?
9. How do the TCSEC and its interpretations apply to routers and
firewalls?
10. Does a trusted system require custom hardware?
11. What are the requirements for a D/C1/C2/B1/B2/B3/A1 system?
Section IV: Evaluations
1. How do I get my product evaluated?
2. What is the evaluation process?
3. How long does an evaluation take?
4. How much does an evaluation cost?
5. How do I find out about the evaluation process?
6. Who actually performs the evaluations?
7. What information is released about an evaluated product?
8. What is RAMP?
Section V: Evaluated Products
1. Should I buy an evaluated product?
2. Does NSA buy/use evaluated products?
3. How do I know if a product is evaluated?
4. What does it mean for a product to be "in evaluation"?
5. What does it mean for a product to be "compliant" with the TCSEC?
6. What and where is the Evaluated Products List (EPL)?
7. How do I get a copy of an evaluation report?
8. Is an evaluated product "hacker proof?"
9. What is the rating of DOS?
10. What is the rating of UNIX?
11. What should I do if evaluated Product X appears to fail a requirement?
12. Why should I buy a B2/B3/A1 product over a C2/B1 product?
13. Is there an approved program to declassify my hard drive?

----------

Subject: Section I: The Trusted Product Evaluation Program (TPEP)

1. What is the National Computer Security Center (NCSC)?

The Department of Defense Computer Security Center was
established in 1981 to encourage the widespread availability of
trusted computer systems for use by facilities processing
classified or other sensitive information. In August 1985 the
name of the organization was changed to the National Computer
Security Center (NCSC). The NCSC may be reached at:

National Computer Security Center
9800 SAVAGE ROAD
FT MEADE MD 20755-6000

or by phone at (410) 859-4376.

2. What is TPEP?

The Trusted Product Evaluation Program (TPEP) is the program by
which the NCSC evaluates computer systems against security
criteria. The Trusted Product Evaluation Program (TPEP) is
operated by an organization separate from the National Computer
Security Center (NCSC). The TPEP performs computer security
evaluations for, and on behalf of, the NCSC.

3. How is TPEP related to the National Security Agency (NSA)?

Both the Trusted Product Evaluation Program (TPEP) and the
National Computer Security Center (NCSC) are organizational
units within the National Security Agency (NSA). The TPEP and
NCSC are two of a number of organizational units within the NSA
responsible for the information system security mission with
respect to classified and sensitive data (see
<http://www.nsa.gov:8080/>).

4. How is TPEP related to the National Institute of Standards
and Technology (NIST)?

In Public Law 100-235 congress directed the National Security
Agency (NSA), of which the Trusted Product Evaluation Program
(TPEP) is a part, to lead the efforts of the United States
Government in information systems security for classified
information. The National Institute of Standards and Technology
(NIST) as part of the Department of Commerce is directed to
lead the efforts for sensitive but unclassified information
with technical support from the NSA. The NSA and NIST have
established a Memorandum of Understanding detailing the
responsibilities of each organization with respect to the other
in this area. While NSA and NIST each have individual efforts,
the agencies attempt to develop methods and standards that are
compatible. (see <http://csrc.ncsl.nist.gov/>)

5. How do I contact the TPEP?

The Trusted Product Evaluation Program can be reached by mail at

V24, TRUSTED PRODUCT EVALUATION PROGRAM
NATIONAL SECURITY AGENCY
9800 SAVAGE ROAD STE 6753
FT MEAD MD 20755-6753

or by phone at (410) 859-4458.

6. What is the TTAP?

The Trust Technology Assessment Program (TTAP) is a joint
National Security Agency (NSA) and National Institute of
Standards and Technology (NIST) effort to commercialize the
evaluation of commercial-off-the-shelf (COTS) products at the
lower levels of trust. Under the auspice of the National
Voluntary Laboratory Accreditation Program (NVLAP), TTAP will
establish, accredit and oversee commercial evaluation
laboratories focusing initially on products with features and
assurances characterized by the Trusted Computer System
Evaluation Criteria (TCSEC) B1 and lower levels of trust
(see Section II, Question 2 and Section III, Question 4).
Vendors desiring a level of trust evaluation will contract with
an accredited laboratory and pay a fee for their product's
evaluation. (see <http://csrc.ncsl.nist.gov/ttap/>)

TTAP approval and oversight mechanisms will assure continued
quality and fairness. Using the NVLAP model of standardized
testing and analysis procedures, TTAP will strive to achieve
mutual recognition of evaluations with other nations. The
European Community evaluations are performed under the purview
of national test standardization bodies associated with NVLAP.

The TTAP is being established with a planned transition from
TCSEC based evaluations to Common Criteria based evaluations
(see Section II, Question 8). The implementation of the Common
Criteria will occur upon acceptance of the Common Criteria and
the Common Evaluation Methodology, which is in the process of
being developed.

7. What is Dockmaster?

Dockmaster, or more precisely dockmaster.ncsc.mil, is an
unclassified computer system used by the Trusted Product
Evaluation Program (TPEP) to exchange information between
product evaluators, vendors, and others within the computer
system security community. Dockmaster is based on the
B2-evaluated Honeywell MULTICS product. This is a very old
platform, and efforts are underway to replace Dockmaster with a
more current product. In addition to use by the TPEP and the
NCSC, dockmaster provides service to the information security
community through electronic mail, bulletin boards, and forums
for the exchange of ideas. Online access to the INFOSEC Product
and Services Catalogue is available. Information is provided
about training courses and scheduled INFOSEC conferences.

To register for an account, write to:

Attn: Dockmaster Accounts Administrator
National Computer Security Center
9800 SAVAGE ROAD
FT MEADE MD 20755-6000

8. Why doesn't TPEP have a WWW server on Dockmaster?

Many desirable network access features are not available in the
MULTICS operating system used by Dockmaster. As the system is
upgraded, it is anticipated that it will support some of these
features. The TPEP WWW server is available at
<http://www.radium.ncsc.mil/tpep/>.

----------

Subject: Section II: Criteria

1. What is the criteria used for evaluation?

The criteria currently used by the Trusted Product Evaluation
Program (TPEP) to grade the security offered by a product is
the Trusted Computer System Evaluation Criteria (TCSEC), dated
1985 (see Section II, Question 2)

2. What is the TCSEC?

The Trusted Computer System Evaluation Criteria (TCSEC) is a
collection of criteria used to grade or rate the security
offered by a computer system product. The TCSEC is sometimes
referred to as "the Orange Book" because of its orange cover.
The current version is dated 1985 (DOD 5200.28-STD, Library No.
S225,711) The TCSEC, its interpretations and guidelines all
have different color covers, and are sometimes known as the
"Rainbow Series" (see Section II, Question 11.) It is available at
<http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html>

3. What is the Orange Book?

See Section II, Question 2.

4. What are interpretations?

It is often the case that there are several ways to read a
given statement in the Trusted Computer System Evaluation
Criteria (TCSEC). Interpretations are official statements
articulating which of a number of possible ways to read the
requirement are the acceptable ways for purposes of evaluation
by the TPEP. Interpretations are developed by an group of
highly experienced product evaluators. These interpretations
in proposed form are available for comment by all users of
Dockmaster (see Section 1, Question 6) including vendors with
products in evaluation. After considering the comments and
revising the interpretation as appropriate (sometime through
several rounds of comments and revision) the interpretation is
accepted by the TPEP and officially announced.

5. What is the Interpreted TCSEC (ITCSEC)?

The Interpreted Trusted Computer System Evaluation Criteria
(ITCSEC) is a version of the TCSEC maintained by the Trusted
Product Evaluation Program (TPEP) that annotates the TCSEC
requirements with all current interpretations. It is available
in postscript from
<http://www.radium.ncsc.mil/tpep/library/tpep/ITCSEC.ps>.

6. What is the ITSEC (as opposed to the ITCSEC)?

The Information Technology Security Evaluation Criteria (ITSEC)
is a European-developed criteria filling a role roughly
equivalent to the TCSEC. While the ITSEC and TCSEC have many
similar requirements, there are some important distinctions.
The ITSEC places increased emphasis on integrity and
availability, and attempts to provide a uniform approach to the
evaluation of both products and systems. The ITSEC also
introduces a distinction between doing the right job
(effectiveness) and doing the job right (correctness). In so
doing, the ITSEC allows less restricted collections of
requirements for a system at the expense of more complex and
less comparable ratings and the need for effectiveness analysis
of the features claimed for the evaluation. The question of
whether the ITSEC or TCSEC is the better approach is the
subject of sometimes intense debate. The ITSEC is available in
postscript at
<http://www.radium.ncsc.mil/tpep/library/non-US/ITSEC-1.2.html>.

On 21 August 1995, The National Institute of Standards and
Technology (NIST) released a draft National Computer Systems
Laboratoty (NCSL) Bulletin. This draft bulletin adresses the
relationship of low assurance products evaluated under the
TCSEC, ITSEC, and CTCPEC. In the case of the ITSEC, it is
recommended that if an appropriate C2 rated product is not
available, that ITSEC rated FC2/E2 products be used.

7. What is the CTCPEC?

The Canadian Trusted Computer Product Evaluation Criteria is
the Canadian equivalent of the TCSEC. It is somewhat more
flexible than the TCSEC (along the lines of the ITSEC) while
maintaining fairly close compatibility with individual TCSEC
requirements. The CTCPEC is available at
<http://www.cse.dnd.ca/Services/Criteria/English/Criteria.html>.

On 21 August 1995, The National Institute of Standards and
Technology (NIST) released a draft National Computer Systems
Laboratoty (NCSL) Bulletin. This draft bulletin adresses the
relationship of low assurance products evaluated under the
TCSEC, ITSEC, and CTCPEC. In the case of the CTCPEC, it is
recommended that if an appropriate C2 rated product is not
available, that CTCPEC products rated with a C2 functionality
profile and T1 assurance be used.

8. What is the Common Criteria?

The Common Criteria (CC) occasionally (and somewhat
incorrectly) referred to as the Harmonized Criteria, is a
multinational effort to write a successor to the TCSEC and
ITSEC that combines the best aspects of both. An initial
version (V 1.0) was released in January of 1996. The CC has
a structure closer to the ITSEC than the TCSEC and includes
the concept of a "profile" to collect requirements into easily
specified and compared sets. The TPEP is actively working to
develop profiles and an evaluation process for the CC. We
anticipate beginning several trial CC evaluations late in
calendar year 1996. It is available in postscript from
<http://www.radium.ncsc.mil/tpep/library/ccitse/>

9. What is the TNI?

The Trusted Network Interpretation (TNI) of the TCSEC, also
referred to as "The Red Book," is a restating of the
requirements of the TCSEC in a network context. Evaluations of
the type of systems (sometimes called distributed or
homogeneous) described by Part I are often evaluated directly
against the TCSEC without reference to the TNI. TNI component
evaluations are evaluations performed against Appendix A of the
TNI. (see Section III, Question 5) It is available in at
<http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-005.html>.

10. What is the TDI?

The Trusted Database Interpretation (TDI) of the TCSEC is
similar to the Trusted Network Interpretation (TNI) in that it
decomposes a system into independently evaluatable components.
It differs from the TNI in that the paradigm for this
decomposition is the evaluation of an application (e.g.,
database) running on an already evaluated system. The Trusted
Product Evaluation Program (TPEP) has to date only evaluated
databases using this interpretation. In principle arbitrary
trusted applications could be evaluated. It is available at
<http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-021.html>.

11. What is the Rainbow Series?

The "Rainbow Series" is the name given to the collection of
interpretation documents (e.g., TNI and TDI) and guidance
documents (e.g., Guide to understanding MAC, Password
Guidelines) published by the National Computer Security Center
(NCSC). Each document has a different color cover, thus the
name "Rainbow Series." The guidelines of the rainbow series,
are designed to expand on, and clarify, the requirements in the
Trusted Computer System Evaluation Criteria (TCSEC). They are,
however, only guidance. The words of the requirements and
interpretations are used as the metric for evaluation, not the
guidelines. A single copy of every rainbow series
document is available without charge to U.S. addresses
by writing to:

INFOSEC AWARENESS, ATTN: Y13/IAOC
DEPARTMENT OF DEFENSE
9800 SAVAGE ROAD
FT MEADE MD 20755-6000

or by calling (410) 766-8729. Additional copies may be
obtained from the Government Printing Office. The Trusted
Computer System Evaluation Criteria (TCSEC) and most of the
other rainbow series documents are available at
<http://www.radium.ncsc.mil/tpep/library/rainbow/>.

12. What are Process Action Team (PAT) Guidance Working Group (PGWG)
documents?

The PGWG (often pronounced pig-wig) documents are also known
as the Form and Content documents. These documents are
published directly by the Trusted Product Evaluation Program
(TPEP) and are designed to provide guidance to vendors
submitting products for evaluation. This guidance is not
security or requirements guidance in the Rainbow Series style.
Rather, these documents provide rules used by the TPEP in
accepting products into evaluation to ensure that the
information provided to the evaluation team is in a state that
is most conducive to a expeditious and trouble-free
evaluation. The document discussing design documentation is
available in postscript at
<http://www.radium.ncsc.mil/tpep/library/process_documents/PATdesign.ps>.
The document discussing test documentation is available in
postscript from
<http://www.radium.ncsc.mil/tpep/library/process_documents/PATtest.ps>.

13. Is there a criteria for commercial (as opposed to military) systems?

The Trusted Product Evaluation Program (TPEP) is prohibited by
the Computer Security Act of 1987 from attempting to directly
address the needs of commercial systems. The TPEP does not
subscribe, however, to the often loudly espoused belief that
the requirements of military systems are entirely divorced from
the requirements of commercial systems. It seems reasonable to
believe that commercial computer system users require many of
the same basic features of military systems: identification and
authentication of the users requesting information or service
from the system; ability to audit the actions of users; and
control of access to information, both at the discretion of the
information owner and by corporate policy. Because the TCSEC
couched its requirements in terms of DoD classifications, many
people have not thought about applying them to similar needs
for mandatory controls on protected information pertaining to
product development, marketing, and personnel decisions. It is
one of the aims of the Common Criteria to provide criteria that
use more general terminology.

14. What is the Federal Criteria?

The Federal Criteria was an attempt to develop a criteria to
replace the Trusted Computer System Evaluation Criteria
(TCSEC). A draft version was released for public comment in
December 1992. However, this effort was supplanted by the
Common Criteria effort (see Section II, Question 8), and the
Federal Criteria never moved beyond the draft stage (although
many of its ideas are retained in the Common Criteria). There
is no FINAL Federal Criteria; the draft should not be treated
as a final criteria document. The draft of the Federal
Criteria is available at <http://hightop.nrl.navy.mil/rainbow.html>.

15. What are the CMWREQs and the CMWEC?

The criteria used by the Defense Intelligence Agency (DIA) to
rate a product as a Compartmented Mode Workstation (CMW) is the
Compartmented Mode Workstation Evaluation Criteria (CMWEC),
which superseded the CMW Requirements (CMWREQs) in 1991. This
criteria defines a minimum level of assurance equivalent to the
B1 level of the TCSEC (see Section III, Questions 2-4). It
also defines a minimum set of functionality and usability
features outside the scope of the TCSEC (e.g. a graphical user
interface via a window system is required along with the
capability to cut and paste between windows). Neither set of
requirements are currently used by the Trusted Product Evaluation
Program (TPEP) although products that are designed to have these
features may be evaluated as B1 or higher products.

----------

Subject: Section III: Criteria Concepts

1. What are security features?

A security feature is a specific implementable function in a
system which supports some part of the system's security
policy. Examples of security features would be access control,
trusted path, and audit. The Trusted Computer System
Evaluation Criteria (TCSEC) (see Section II, Question 1)
ratings are not designed to express the rating of individual
features, as are some other criteria. Rather, each class
specifies a set of security features that a system must
implement in order to be rated at that class. However, many
evaluations are given "extra credit" in the evaluation results
for successful implementations of features that are required
only in a higher overall rating in the criteria.

2. What is assurance?

In the context of the Trusted Computer System Evaluation
Criteria (TCSEC), assurance coincides with correctness
assurance. It is a measure of confidence that the security
features and architecture of a computer system accurately
mediate and enforce the system security policy. The TCSEC's
assurance-related requirements constrain development methods
(e.g., configuration management) and software engineering
practices (e.g., modular code). Higher evaluation classes
contain more assurance-promoting requirements and give more
confidence in correctness.

3. What is a division?

A division is a set of classes (see Question 5) from the
Trusted Computer System Evaluation Criteria (TCSEC) (see
Section II, Question 1). There are 4 divisions A, B, C, and D
in decreasing order of assurance and features. Thus, a system
evaluated at a class in division B has more security features
and/or a higher confidence that the features work as intended
than a system evaluated at a class in division C. Although the
Computer Security Subsystem Interpretation (CSSI) of the TCSEC
specifies criteria for various D ratings, these are not
reflected in the TCSEC itself, which has no requirements for D
division systems. An unrated system is, by default, division
D.

4. What is a class?

A class is the specific collection of requirements in the
Trusted Computer System Evaluation Criteria (TCSEC) to which an
evaluated system conforms. There are seven classes in the
TCSEC A1, B3, B2, B1, C2, C1, and D, in decreasing order of
features and assurances. Thus, a system evaluated at class B3
has more security features and/or greater confidence that the
security features work as intended than a system evaluated at
class B1. The requirements for a higher class are always a
superset of the lower class. Thus a B2 system meets every C2
functional requirement and has a higher level of assurance.

5. What is a network component?

A "network component" is the target of evaluation for a Trusted
Network Interpretation (TNI) evaluation (see Section II,
Question 9) done against appendix A of the TNI. These
"network component" evaluations allocate basic requirements
(Mandatory Access Control (MAC); Discretionary Access Control
(DAC); Audit; and Identification and Authentication) to
components of a "network system". Each component may be
evaluated in isolation. The TPEP does evaluate degenerate TNI
components that independently meet all basic requirements (but
nevertheless have an interface to other, perhaps identical
components), but has not evaluated any degenerate TNI component
that met none of the basic requirements (relying totally on
other components for the security features). The TPEP is
currently developing a more integrated approach to the evaluation
of TNI components. The preliminary report of the changes
envisioned are available in postscript at
<http://www.radium.ncsc.mil/tpep/library/process_documents/cwg-draft.ps>.

6. What is a Network Security Architecture Design (NSAD) document?

The documentation for a network component (see Section III,
Question 5) must include a Network Security Architecture Design
(NSAD) document which describes the security expectations by this
component about other components. Each component evaluation
proceeds under the assumption that the expectations of the NSAD
are met by the other components. A collection of components
designed around the same architecture should interoperate
securely.

7. How do I interpret a rating?

A product evaluated by the Trusted Product Evaluation Program
(TPEP) will have one of several styles of ratings. A product
evaluated against the Trusted Computer System Evaluation
Criteria (TCSEC) will have one of the seven class ratings: A1,
B3, B2, B1, C2, C1, or D (see Section III, Question 4.) In
addition a TCSEC evaluated product may be evaluated to have met
requirements above it's class. These would be specified
additionally such as "meets the B1 requirements and the B2
Trusted Path requirement." It is very important to note that,
for example, a B1 evaluated system with B2 trusted path,
provides significantly less confidence that trusted path is
implemented correctly than a B2 evaluated system. That is to
say that the assurance is always that of the system's rated
class.

Some systems have been evaluated against the Compartmented Mode
Workstation (CMW) criteria. The CMW criteria levies minimum
features and assurances from the TCSEC as well as additional
usability criteria (e.g., specifying that the window system must
manipulate windows at multiple levels in certain ways.) The
TPEP has treated these systems as standard TCSEC evaluations
with additional requirements. From a security perspective the
CMW requirements do not preclude a B2 or higher CMW, however,
to this point all CMW evaluated systems are B1 evaluated with
additional TCSEC features above the evaluated class.

Another form of rating is a Trusted Network Interpretation
(TNI) component (see Section III, Question 5) rating. TNI
component ratings specify the evaluated class as well as which
of the four basic security services the evaluated component
provides. Thus, a B2-MD component is one that provides both
Mandatory Access Control (MAC) and Discretionary Access Control
(DAC). A B1-MDIA component is one that provides MAC, DAC,
Identification and Authentication, and Audit. Since a B1-MDIA
component meets all the Trusted Computer System Evaluation
Criteria (TCSEC) requirements for B1, it is likely that this
component is also evaluated as a B1 system if it can be used in
a non-network configuration.

A third form of rating is a Trusted Database Interpretation
(TDI) rating. This rating is the same as a TCSEC rating except
that the rating applies to the composite of the evaluated
application and each of the listed underlying systems.

Finally, products evaluated against the Computer Security
Subsystem Interpretation (CSSI) of the TCSEC have been given
variations of D division (see Question 4) ratings. These
appear for example as I&A/D2, Audit/D1, DAC/D3, and OR/D.
These products all have very low assurance regardless of the
features.

8. The TCSEC is 10 years old, doesn't that mean it's outdated?

The Trusted Computer System Evaluation Criteria (TCSEC) was
published in 1985. While some of the details need
interpretation for current systems, in general the requirements
of the TCSEC are at a level of abstraction that has not
experienced great change. For the areas where it is becoming
difficult to use the TCSEC, the Common Criteria (see Section
II, Question 8) should provide more relevant criteria.

9. How do the TCSEC and its interpretations apply to routers and
firewalls?

The Trusted Network Interpretation (TNI) of the TCSEC has been
used to evaluate these types of products. While there is some
value to those evaluations it is true that many of the specific
mechanisms of these products on which one might wish to have an
evaluator comment are not recognized by the TNI. It is hoped
that the Common Criteria (see Section II, Question 8) will be
able to address these products more directly with, for example,
an appropriate profile.

10. Does a trusted system require custom hardware?

A system does not require custom hardware to be successfully
evaluated against the Trusted Computer System Evaluation
Criteria (TCSEC). However, an evaluation does consider the
security of the system hardware as well as software. For every
evaluated product, there is an evaluated configuration. The
evaluated configuration lists the specific hardware and
software evaluated. A given evaluation may require hardware
with certain security features used by the software, and the
software may require certain optional features be enabled or
disabled. The Final Evaluation Report (FER) (see Section V,
Question 7) lists the evaluated hardware and software. The
Trusted Facility Manual (TFM) for the product will give
detailed guidance on configuring the hardware and software
securely.

11. What are the requirements for a D/C1/C2/B1/B2/B3/A1 system?

The Interpreted Trusted Computer System Evaluation Criteria
(ITCSEC) available in postscript at
<http://www.radium.ncsc.mil/tpep/library/tcsec/ITCSEC.ps>
contains the definitive set of requirements for each TCSEC
class. In Summary:

Class D: Minimal Protection

Class D is reserved for those systems that have been evaluated
but that fail to meet the requirements for a higher evaluation
class.

Class C1: Discretionary Security Protection

The Trusted Computing Base (TCB) of a class C1 system
nominally satisfies the discretionary security requirements by
providing separation of users and data. It incorporates some
form of credible controls capable of enforcing access
limitations on an individual basis, i.e., ostensibly suitable
for allowing users to be able to protect project or private
information and to keep other users from accidentally reading
or destroying their data. The class C1 environment is
expected to be one of cooperating users processing data at the
same level of sensitivity.

Class C2: Controlled Access Protection

Systems in this class enforce a more finely grained
discretionary access control than C1 systems, making users
individually accountable for their actions through login
procedures, auditing of security-relevant events, and resource
isolation.

Class B1: Labeled Security Protection

Class B1 systems require all the features required for class
C2. In addition, an informal statement of the security policy
model, data labeling (e.g., secret or proprietary), and
mandatory access control over named subjects and objects must
be present. The capability must exist for accurately labeling
exported information.

Class B2: Structured Protection

In class B2 systems, the TCB is based on a clearly defined and
documented formal security policy model that requires the
discretionary and mandatory access control enforcement found
in class B1 systems be extended to all subjects and objects in
the automated data processing system. In addition, covert
channels are addressed. The TCB must be carefully structured
into protection-critical and non- protection-critical
elements. The TCB interface is well-defined and the TCB
design and implementation enable it to be subjected to more
thorough testing and more complete review. Authentication
mechanisms are strengthened, trusted facility management is
provided in the form of support for system administrator and
operator functions, and stringent configuration management
controls are imposed. The system is relatively resistant to
penetration.

Class B3: Security Domains

The class B3 TCB must satisfy the reference monitor
requirements that it mediate all accesses of subjects to
objects, be tamperproof, and be small enough to be subjected
to analysis and tests. To this end, the TCB is structured to
exclude code not essential to security policy enforcement,
with significant system engineering during TCB design and
implementation directed toward minimizing its complexity. A
security administrator is supported, audit mechanisms are
expanded to signal security-relevant events, and system
recovery procedures are required. The system is highly
resistant to penetration.

Class A1: Verified Design

Systems in class A1 are functionally equivalent to those in
class B3 in that no additional architectural features or
policy requirements are added. The distinguishing feature of
systems in this class is the analysis derived from formal
design specification and verification techniques and the
resulting high degree of assurance that the TCB is correctly
implemented. This assurance is developmental in nature,
starting with a formal model of the security policy and a
formal top-level specification (FTLS) of the design. An FTLS
is a top level specification of the system written in a
formal mathematical language to allow theorems (showing the
coorespondence of the system specification to its formal
requirements) to be hypothesized and formally proven. In
keeping with the extensive design and development analysis of
the TCB required of systems in class A1, more stringent
configuration management is required and procedures are
established for securely distributing the system to sites. A
system security administrator is supported.

----------

Subject: Section IV: Evaluations

1. How do I get my product evaluated?

Product developers who have a product that they wish to have
evaluated need to request a proposal package from:

V24, TRUSTED PRODUCT EVALUATION PROGRAM
NATIONAL SECURITY AGENCY
9800 SAVAGE ROAD STE 6740
FT MEADE MD 20755-6740

The ultimate proposal for product evaluation will include
technical and marketing details for the product. Because the
Trusted Product Evaluation Program (TPEP) is legislatively
prohibited from directly evaluating products that are not
intended to protect classified information, the proposal
marketing information should include details about the market
potential within the United States Department of Defense and
intelligence communities. Additionally, the TPEP in general
does not accept products targeting the C1 and below evaluation
classes, as these are usually inappropriate for processing any
classified information. TPEP currently accepts for evaluation
at the C2 and higher levels, networked systems which meet the
market and technical criteria. The product technical details
will include descriptions of the product's documentation and how
that documentation's structure compares to that required by the
PGWG documents (see Section II, Question 11). Finally, the
proposed configuration of the product should be a configuration
likely to be used by the described potential market.

2. What is the evaluation process?

The evaluation process is described in detail at
<http://www.radium.ncsc.mil/tpep/process/procedures.html> In
general terms, a successful evaluation proceeds through the
following stages:

Proposal Review

A product proposal, submitted by a vendor for consideration of
evaluation by TPEP is reviewed for two purposes. The first is
to determine the potential market benefits of accepting the
product for evaluation (i.e., the DoD customer base). The
market analysis is performed based upon both the vendor's proposal
and upon TPEP customer input, which is actively solicited on a
regular basis. The second part of the proposal review is to
determine, at a very preliminary level, if the product appears
to provide feasible security mechanisms such that the requirements
of the TCSEC can be satisfied. Once the review of the product
proposal is completed, the vendor is notified in writing of the
acceptance or rejection of the product for evaluation.

Technical Assessment

Products whose proposals were recommended as "accept" are
considered candidates for evaluation and proceed to the next
step in pre-evaluation, the Technical Assessment (TA), where
a vendor must demonstrate that the product design and the
associated evaluation evidence are complete. A TA is often
the first examination of the product and the evidence by a
technical evaluation team. Vendors may have excellent and
complete documentation, indicating a readiness to undergo an
Intensive Preliminary Technical Review (IPTR) which is the
gateway to evaluation when successfully completed. Advice may
be recommended based on readiness.

Advice

The purpose of advice is to aid the vendor in producing a product
and supporting documentation that is capable of being evaluated
against the TCSEC and its interpretations. Advice can be provided
by contractors outside of TPEP or TPEP evaluators may be assigned
to advise the vendor. TPEP-provided advice begins after a vendor
has submitted a proposal and a technical assessment has been
performed that deemed the product suitable for evaluation, but
not yet ready for an IPTR.

Intensive Preliminary Technical Review (IPTR)

The IPTR is an independent assessment by the TPEP evaluators to
determine a product's readiness for evaluation. An IPTR lasts
for approximately 7-10 days and is performed by a team of
approximately 5 TPEP evaluators. During the IPTR, which is
usually held at the vendor's site, the team becomes familiar with
the product (through vendor presentations); reviews documentation,
test plans, and procedures; and documents its findings in a report.
The IPTR report is provided to the vendor and TPEP management and
documents the team's assessment of the product's readiness for
evaluation. Completion of a successful IPTR results in the
product moving into evaluation (pending availability of TPEP
evaluation resources).

Evaluation

Evaluation is the comprehensive technical analysis of a product's
security functionality. At the beginning of evaluation, the
vendor provides the evaluation team with system level, developer-
oriented training for the product. Training is followed by
analysis of the product design, focusing specifically on security
features. This analysis includes both hardware and software
components of the product and associated documentation. Testing
of the product involves running the vendor's test suite, as well
as tests formulated by the evaluation team. Upon successful
completion of testing and rigorous technical reviews by senior
members of the evaluation community, the product is awarded an
Evaluated Products List (EPL) entry.

Rating Maintenance Phase (RAMP)

RAMP provides a mechanism for a vendor to maintain the TCSEC
rating of a product throughout its life cycle. During RAMP,
the vendor works with the TPEP assigned Technical Point of
Contact (TPOC) to analyze the security impact of proposed changes
to the evaluated product. The Vendor Security Analyst (VSA)
actually performs the security analysis of the product changes
as they occur. The changes and associated analysis results are
presented to a TPEP Technical Review Board (TRB) which recommends
approval (or disapproval) of the rating for the "new" product.

3. How long does an evaluation take?

The length of time a developer needs to prepare for an
Intensive Preliminary Technical Review (IPTR) varies
considerably. The IPTR is a short (one to two week) assessment
of the state of the product documentation and testing. A
successfull IPTR ensures that the materials needed for
evaluation are complete and usable. Currently, we expect
successful evaluations at the C2/B1 class to take approximately
one year to complete from successful IPTR to final technical
review. IPTRs should ideally take place approximately eight
months before product release for a typical C2/B1 product, and
even earlier in the product cycle for products targeted at B2,
B3 or A1. We continue to explore ways to reduce the time
required. Higher class evaluations take longer, although this
is somewhat mitigated by the fact that the TPEP is usually
involved earlier in the design process for systems at
relatively higher classes. Problems during evaluation, changes
in the configuration the vendor is planning to market, and
system complexity can all add to the length of evaluation.
Vendors participating in the RAMP (Rating Maintenance) process
can perform analysis of changes to an already evaluated system
to maintain the evaluated rating on subsequent versions and
configurations. The length of time to obtain a RAMP rating is
largely dependent on the vendor and on the nature and
complexity of the change. However, it is reasonable to expect
this RAMP to take far less time than an evaluation.

4. How much does an evaluation cost?

The Trusted Product Evaluation Program (TPEP) does not charge
for evaluations. It may be a significant expense for a product
developer to prepare for and support evaluation. There are
often travel expenses for staff, training costs for the
evaluation team, and the cost of having development personnel
take time to respond to the evaluation team's questions. In
addition, if the product did not previously meet the
requirements for a given class, the cost of improving the
product (i.e., doing the testing, analysis and documentation)
can be high. Ultimately, this should result in an improved
product that will be recognized as superior to competitors.

5. How do I find out about the evaluation process?

For an abstract view of the evaluation process you can read
this list of Frequently Answered Questions (FAQ)! For a more
detailed view appropriate to those who wish to participate in
the process, the process is described in some detail at
<http://www.radium.ncsc.mil/tpep/process/procedures.html>.

6. Who actually performs the evaluations?

Trusted product evaluators come from the Trusted Product
Evaluation Program (TPEP) organization within the National
Security Agency (NSA) as well as from a small group of federal
contract research organizations. Some evaluations have also
benefitted from the participation of evaluators from the
security evaluation organizations of other cooperating
governments. In cooperation with the National Institute of
Standards and Technology (NIST), a program is being developed to
evaluate products in the lower Trusted Computer System
Evaluation Criteria (TCSEC) classes (i.e., C2/B1) using
approved commercial evaluation facilities. However, many
details remain to be finalized for that program.

7. What information is released about an evaluated product?

As we begin working with a product, the vendor and target
rating are made available. When that product is accepted into
evaluation, information such as the vendor, target rating, and
target completion date are announced in a product announcement
on the Evaluated Products List (EPL) (see Section V, Question
6). When the evaluation is completed the general evaluated
product configuration, general product information, and rating
are announced in an entry on the EPL. In addition at the
completion of evaluation a report is published (see Section V,
Question 7). This report contains the analysis of the
evaluation team, a complete description of the evaluated
product, and often comments about the usability of the product
in its evaluated configuration by the evaluation team. Recent
EPL entries and a few Final Evaluation Reports are available at
<http://www.radium.ncsc.mil/tpep/epl/>.

8. What is RAMP?

The Rating Maintenance Phase (RAMP) Program was established to
provide a mechanism to extend the previous rating to a new
version of a previously evaluated computer system product.
RAMP seeks to reduce evaluation time and effort required to
maintain a rating by using the personnel involved in the
maintenance of the product to manage the change process and
perform Security Analysis. Thus, the burden of proof for RAMP
efforts lies with those responsible for system maintenance
(i.e., the vendor) instead of with an evaluation team.

----------

Subject: Section V: Evaluated Products

1. Should I buy an evaluated product?

An evaluated product has the benefit of providing an
independent assessment that the product meets the criteria for
the rating it achieved. When considering a specific
installation the value of the data and the threat to that data
both need to be considered. These are often related, in that
more valuable data has a higher threat. If some of the threats
to the data can be countered by the features or assurance of a
trusted product, then it is certainly worthwhile to consider
that in your purchase decision. All other things being equal
(which is rarely the case) the independent assessment of an
evaluated product adds value.

2. Does NSA buy/use evaluated products?

NSA endevours to be an exemplary customer of the products it
recommends for use by its customers and expects NSA-evaluated
products to comprise the foundation of its own secure information
systems architecture and is developing policy towards that end.

3. How do I know if a product is evaluated?

The simplest way to find out if a product is not evaluated is
to ask the product vendor. If the vendor has an evaluated
product, it is a pretty good bet that the company marketing
people are aware of it. Many products that have NOT been
evaluated have names containing a rating or have declared
themselves as "designed to meet" a specific rating. These products
have not withstood the same scrutiny as products listed on the EPL.

If a vendor claims to have an evaluated product, you should
independently verify the details of the evaluation (e.g.,
product version, configuration, rating.) All evaluated products
are placed on the Evaluated Products List (EPL) (see Section V,
Question 6). That is the first place to look. The EPL entries
that have been awarded within the last three years are available
at <http://www.radium.ncsc.mil/tpep/epl/>. To verify a specific
detail (e.g., the rating) of an evaluation, you may call the Trusted
Product Evaluation Program (TPEP) directly at (410) 859-4458 This
will often result in less complete information since generally we
don't read entire EPL entries over the phone.

For the most complete information about a specific evaluated
product, you should request a copy of the evaluation report.
(see Section V, Question 7) Unfortunately, the publication of
the report sometimes postdates the evaluation significantly.
An increasing number of final evaluation reports are available
via links from the product's electronic EPL entry or from
<http://www.radium.ncsc.mil/tpep/library/fers/> by report number.

4. What does it mean for a product to be "in evaluation"?

In the past it has been the case that Trusted Product
Evaluation Program (TPEP) evaluations where conducted over
longer periods of time and included time for a developer to
work out problems with their documentation and testing that a
current Intensive Preliminary Architecture Review (IPTR) is
designed to limit. Currently a product is not announced to be
in evaluation until it has successfully passed an IPTR. Even
so, a product may go through several releases, incorporate
fixes during the course of evaluation, or even potentially drop
out of evaluation or fail evaluation. Because of this a
product in evaluation is not equivalent to an evaluated
product. While it does show some intent to have an evaluated
product, and a consideration of security criteria in the
product development, it does not necessarily imply any security
features or assurances. Buyers of products in evaluation
should consider what options will be available to them should
the evaluated configuration differ significantly from the
purchased configuration, or if the product does not ultimately
complete evaluation.

5. What does it mean for a product to be "compliant" with the TCSEC?

If a product has been evaluated by the Trusted Product
Evaluation Program (TPEP) to comply with the requirements of a
rated class, then it means that an independent assessment
showed the product to have the features and assurances of that
class. It does not mean that the product is impenetrable. It
is even possible that the independent assessment overlooked
some failure to meet the criteria, although we expend a lot of
energy attempting to prevent that. A vendor claim to be
"compliant" without an evaluation often doesn't mean very much
since the vendor's interpretation of the requirement may not be
the same as an independent assessor's would be.

6. What and where is the Evaluated Products List (EPL)?

The Evaluated Products List (EPL) officially is published
quarterly in the INFOSEC Products and Services Catalog (as a
chapter). The INFOSEC Products and Services Catalog is
available from the Government Printing Office. The EPL is also
maintained electronically on Dockmaster and updated as new
products are announced. (see Section I, Question 7) There is no
anonymous access to Dockmaster so this is available only to
Dockmaster users. EPL entries issued within the last three years
are available at <http://www.radium.ncsc.mil/tpep/epl/>.

7. How do I get a copy of an evaluation report?

Single copies of evaluation reports are available without charge
by writing:

INFOSEC AWARENESS, ATTN: Y13/IAOC
DEPARTMENT OF DEFENSE
9800 SAVAGE ROAD
FT MEADE MD 20755-6000

Multiple copies are available from the Government Printing
Office. In either case you will need the report number
(CSC-EPL-xx/xxx or CSC-FER-xx/xxx) which is given in the
Evaluated Products List (EPL) entry for the product. (see
Section V, Question 6)

8. Is an evaluated product "hacker proof?"

No product can be guaranteed to be "hacker proof" or
"impenetrable." An evaluated product has demonstrated certain
features and assurances, as specified by the rating criteria.
Those features and assurances counter certain threats. Thus an
evaluated product is usually vulnerable to fewer threats than
an unevaluated product. Products with higher ratings are
vulnerable to fewer threats than products with low ratings.
Vulnerabilities to threats that remain in products can often be
addressed through other means. No rating class used by the
Trusted Product Evaluation Program (TPEP), for example,
counters the threat of directly tampering with the hardware.
That threat would need to be addressed physically or
procedurally if it was realistic for the particular system
environment.

Finally, it seems many "hackers" today prefer to use "social
engineering" to accomplish their goals. As with other
insider-related threats, education is necessary in preventing
naive users from disclosing sensitive information. However,
technical measures can also help. They can enforce the the
principle of least privilege, check the reasonableness of
administrative inputs, and provide timely on-line cautions.

9. What is the rating of DOS?

MS-DOS, PC-DOS, and DR-DOS have not been evaluated. Without
modification, it is apparent from the most cursory examination
that they do not implement many of the features required by the
C1 class of the Trusted Computer System Evaluation Criteria
(TCSEC). Several vendors support a DOS application interface
in products designed to achieve higher class ratings.

10. What is the rating of UNIX?

There are a number of evaluated products conforming to one or
another of the UNIX interface standards (see Section V,
Question 3). These products range from class C2 to class B3.
In general, unevaluated UNIX products lack several features,
including sufficient auditing, to achieve anything other than a
D class rating without some modification.

11. What should I do if evaluated Product X appears to fail a requirement?

If an evaluated product does not seem to meet the requirements,
the first thing to do is carefully look at the Final Evaluation
Report (FER) and the product's Trusted Facility Manual (TFM).
The product was evaluated with specific configuration options and
on specific hardware. These should be stated in the TFM and FER
respectively. If the evaluated configuration still seems to not
meet some requirement for its rated class, then it is possible that
there was an oversight during the evaluation. You can send that
information to [email protected] and we may investigate the
issue.

12. Why should I buy a B2/B3/A1 product over a C2/B1 product?

While the features and assurances of each class increase, the
increase is not linear. B1 and below rated products provide a
basic set of security features and an independent assesment that
those features are implemented correctly. At B2 and above there
is significantly more effort and analysis both in development and
in evaluation that the features are correctly implemented. The
additional development effort often translates into increased cost
for the product. For applications involving sensitive data, the
added cost may be well worth the added protection.

13. Is there an approved program to declassify my hard drive?

In summary, no; in general, overwriting may be sufficient to have
media released for other use, but it must retain its original
classification.

You should contact your security officer or contracts manager for
official guidance. Often, your contract will determine how to
declassify disks. This is usually indirect, by referencing a
DOD-STD or other document. Be prepared to submit the disk drive
(or at least the little metal thingy with the iron oxide) for total
destruction.

If you need to retrieve unclassified data that reside on a
classified disk, there are often detailed procedures to accomplish
this.