TRUSTED NETWORK INTERPRETATION ENVIRONMENTS GUIDELINE
Table of Contents
NCSCTG-11
Library No. 5-235,465
Version 1
The National Computer Security Center is
issuing the Trusted Network Interpretation Environments Guideline as part of our
Technical Guidelines Program, through which the "Rainbow Series" is produced.
The Technical Guidelines Program ensures that the features of the Trusted
Computer Systems Evaluation Criteria (DOD 5200.28-STD) are discussed in detail
and that guidance is provided for meeting each requirement. The National
Computer Security Center, through its Trusted Product Evaluation Program,
analyses the security features of commercially produced and supported computer
systems. Together, these programs ensure that organisations are capable of
protecting their important data with trusted computer systems.
The Trusted Network Interpretation Environments Guideline is a companion to
the Trusted Network Interpretation of the. Trusted Computer System Evaluation
Criteria (NCSC-TG~O5), published 31 July 1987. The Trusted Network
Interpretation Environments Guideline provides insight into the issues relevant
when integrating, operating, and maintaining trusted computer networks. This
document identifies the minimum security protection required in different
network environments such that network certifiers, integrators, and accreditors
can determine what protection mechanisms and assurances are minimally required
in specific network environments.
This document parallels Computer Security Requirements - Guidance for
Applying the Department of Defense Trusted Computer System Evaluation Criteria
in Specific Environments (CDC-STD~O3-85) and its technical rationale (CSC
STD~0485). It also provides a descriptive presentation of the security issues
that exist in networked computer systems as the networked computer system
environment is inherently more complex and requires additional protection
considerations over stand-alone computer systems.
As the Director, National Computer Security Center, I invite you suggestions
for revising this document. We plan to review this document as the need arises.
PATRICK R. GALLAGHER JR. 1 August 1990
Director
National Computer Security Center
The National Computer Security
Center extends special recognition and acknowledgment for their contributions to
this document to Dr. Marshall D. Abrams, Renee Child, Annabelle Lee, Dr.
Jonathan K. Millen, Samuel I. Schaen, and Dr. Martin W. Schwartz, of The MITRE
Corporation, as authors; Richard Wilmer, also of The MITRE Corporation, as
technical editor; and to Alfred Arsenault, David Chizmadia, id Rick Siebenaler
of the National Computer Security Center, who managed the effort ad participated
in the development.
Special thanks are extended to the many members of the computer security
community who enthusiastically gave their time and expertise in reviewing the
material and providing valuable comments and suggested changes. Special thanks
are extended to James P. Anderson of James P. Anderson Co., Donald L. Brinkley
of Gemini Computers, Inc., Dr. Eric Roskos of The Institute for Defense
Analysis, Dr. Tien Tao of Gemini Computers, Inc., and Dr. John M. Vasak of The
MITRE Corporation for their extensive suggestions and recommendations.
For sale by the Superintendent of Documents, U.S. Government
Printing Office Washington DC 20402
This Trusted Network
Interpretation (TNI) Environments Guideline (TNIEG) addresses many issues in
determining the security protection required in different network environments.
It complements the TNI, just as the Trusted Computer System Evaluation Criteria
(TCSEC) Environments Guideline [1] complements the TCSEC. The TNI interprets the
TCSEC for networks; it contains all of the criteria in the TCSEC, adding
interpretation and rationale to applying trust technology to network systems. In
the same way that the TCSEC Environments Guideline provides guidance on applying
the TCSEC, this TNIEG provides guidance on the use of the TNI. The TCSEC and its
Environments Guideline constitute the foundation on which the TNI and TNIEG add
network applicability.
The National Computer
Security Center (NCSC) is responsible for establishing and maintaining technical
standards and criteria for the evaluation of trusted computer systems. As part
of this responsibility, the NCSC is developing guidance on how new security
technology should be used. Two objectives of this guidance are:
- Establishing a metric for categorizing systems according to the security
protection they provide, and
- Identifying the minimum security protection required in different
environments.
The TCSEC [2] helps to satisfy the first objective by
categorizing computer systems into hierarchical classes based on evaluation of
their security features and assurances. The TCSEC Environments Guideline [1]
helps to satisfy the second objective by identifying the minimum classes
appropriate for systems in different risk environments. These two documents,
however, apply to stand-alone computer systems.
The TNI [3] satisfies the first objective by interpreting the TCSEC for
networks. The TNI also provides guidance for selecting and specifying other
security services (e.g., communications integrity, denial of service,
transmission security). The TNIEG is the first step toward addressing the second
objective.
The NCSC has decided to provide guidance concerning
security in networks and distributed Automated Information Systems (AISs)1 in a
series of publications. The subject area is collectively identified as Trusted
Network Technology (TNT). The TNI is the first TNT publication. This TNIEG is
the second TNT publication. It contains the best guidance that is available at
this time; as technology advances and more experience is gained in implementing
trusted networks, more specific guidance will be provided. This TNIEG provides
elaboration and clarification on the TNI. Guidance concerning Interconnected AIS
which initially appeared in the TNI, Appendix C, has been revised and
incorporated into this document (see Section 6 and Appendix A). This document
does not address all of the security issues that are excluded from the TNI.
Other topics, such as composing a trusted system from evaluated components, will
be discussed in future TNT publications.
The overall purpose of this
TNIEG is to assist program managers, integrators, certifiers, and Accreditors
with identifying the minimum security protection needed for different trusted
computer network environments. For brevity, this audience is referred to as
security managers. Not all questions can be answered at this time. The NCSC
invites suggestions for topics to be addressed in future TNT publications.
This guideline is not a tutorial on security and networking; it is assumed
that the reader will have some background in both areas. Suggested background
references are identified in Appendix B. This guideline is designed to be self
contained; a fair amount of background information that can be found in the TNI
is also included here. The interested reader may consult the TNI and other
documents referenced in this guideline for further detail.
This document describes an
environmental assessment process that helps determine the minimum level of trust
recommended for a specific network operational environment. The primary focus of
this document (and also of the TNI) is on the AIS
- 1 Definitions of terms particularly important to this document are given
in Section 2.
- hardware, firmware, and software aspects of security; therefore, neither
this guideline nor the TNI address all the security requirements that may be
imposed on a network. Depending on the particular environment, communications
security (COMSEC), emanations security (TEMPEST), physical security, personnel
security, administrative security, and other information security (INFOSEC)
measures or safeguards are also required. This document applies to networks
that are entrusted with the processing of information, regardless of whether
that information is classified, sensitive, or otherwise relevant to national
security.
Section 2 of
this document defines terms and Section 3 discusses Network Security
Architecture and Design. Section 4 guides security managers in applying Part I
of the TNI; Section 5 does the same for Part II. Section 6 addresses security
issues that arise when AIS are interconnected. Appendix A discusses the Cascade
Condition in greater detail; Appendix B provides tutorial and background
references on network security; and Appendix C discusses encryption and
encryption mechanisms.
Many of the terms used in the
TNI are drawn from diverse specialization areas. Their special meaning in
context may differ from common English usage. In this section we explain how
such terms are used in the TNI and how these definitions have been refined in
this document. Terms are printed in boldface when they are defined.
An AIS is
defined in DODD 5200.28 as "an assembly of computer hardware, software, and/or
firmware configured to collect, create, communicate, compute, disseminate,
process, store, and/or control data or information" [4]. This is both a broad
definition and a new one, since DODD 5200.28 was published after the TNI. The
TNI states that "automatic data processing (ADP) systems, referred to in this
[TNI] document as Automated Information System (AIS)...", and equates AIS and
ADP. We will use the DODD 5200.28 definition since it is broader and more
authoritative. We also note that DODD 5200.28 tends to pluralize AIS as AISs
while the TNI considers AIS to be a collective noun. We have followed the latter
convention.
The
Network Trusted Computing Base (NTCB) is the totality of protection mechanisms
within a network system2-including hardware, firmware, and software- the
combination of which is responsible for enforcing a security policy. The NTCB is
the network generalization of the trusted computing base (TCB). An NTCB
Partition is the totality of mechanisms within a single network subsystem3 for
enforcing the network policy, as allocated to that subsystem; it is the part of
the NTCB within a single network subsystem.
2~e distinction between a system and a subsystem is a matter of the viewpoint
of the observer. One observer's system may be another observer's subsystem. For
example, the vendor of a local area network may regard his product as a system,
while the customer's network architect may consider it to be a subsystem along
with hosts, workstations, etc.
~e THI uses component in the definition of NTCB Partition. We use subsystem
to be consistent in this document.
The terms system
add component need to be related to each other. Unfortunately, the TNI is not
completely consistent in its use of these terms. We will first cite the relevant
sections from the TNI; then we will reconcile them as used in this guideline. As
discussed below, we define the relationship as follows: A component is a
physical unit contained within a system.
The TNI Introduction states (emphasis added):
- A network system is the entire collection of hardware, firmware, and
software necessary to provide a desired functionality. A component is any part
of a system that, taken by itself, provides all or a portion of the total
functionality required of a system. A component is recursively defined to be
an individual unit, not useful to further subdivide, or a collection of
components up to and including the entire system.
Appendix A of the TNI presents the view:
- a trusted network represents a composition of trusted components....
- The approach to evaluation of a network suggested by this view is to
partition the system into components, rate each component to determine its
security-relevant characteristics, and then evaluate the composition of the
components to arrive at an overall rating class for the network. This
approach... allows for the evaluation of components which in and of themselves
do not support all the policies required by the TCSEC, ... contribute[s] to
the overall evaluation of any network which uses them and allows for the reuse
of the evaluated component in different networks without the need for a
re-evaluation of the component.
Appendix A goes on to state that:
- The set of policy-related features to be supported by the component need
not be the complete set required for a stand-alone system: features not
supplied by one component for the system are supplied by another.
We see a difference
between the Introduction and Appendix A of the TNI. We will use the definition
of component as an individual unit that does not provide a complete set of
end-user services. As a consequence, a subsystem can operate on its own and a
component will require an external connection to perform a useful function.
Appendix C of the TNI uses component, as follows, where we would use
subsystem:
- Any AIS that is connected to other AIS must enforce an "Interconnection
Rule" that limits the sensitivity levels of information that it may send or
receive. Using the component connection view, each component responsible for
maintaining the separation of multiple levels of information must decide
locally whether or not information ca be sent or received.
A
component may support all the policy and accountability requirements: M, D, I,
ad A4; however, as defined above, this is not applicable to determining whether
an individual unit is a component. A component which supports some part of the
security policy contains an NTCB partition. In the extreme, a component may not
have any security-relevant function; in this case it doesn't support any TCSEC
policy and doesn't contain an NTCB partition.
To summarize the
previous discussions, following are definitions for component ad
system/subsystem.
- Component: An individual physical unit that does not provide a complete
set of end-user services.
- System/subsystem: A collection of hardware, firmware, and software
necessary configured to collect, create, communicate, compute, disseminate
process, store, and/or control data ad information [4].
NCSC-evaluation refers
specifically to the process in which the NCSC determines whether a
commercial-off-the-shelf (COTS) product satisfies the TCSE~C. Application of the
TCSEC to a particular product may be assisted by an interpretation guideline
such as the TNI [5]. In such a case, the guideline clarifies the meaning of the
TCSEC's language with regard to a particular type of product, but in no case
circumvents or grants exception to the requirements of the TCSEC. The purpose of
an NCSC- evaluation is as follows:
- The primary goal of the NCSC is to encourage the widespread availability
of trusted computer systems. This goal is realized, in large measure, through
the NCSC's Commercial Product Evaluation Program. This program is focused on
the technical evaluation of the protection capabilities of off-the- shelf,
commercially produced and supported systems that meet the computer security
needs of government departments and agencies. This product evaluation
culminates in the publication of an Evaluated Products List (EPL) report...
[6].
An NCSC evaluation places a product in one of four divisions:
D, C, B, or A. Division D is for systems that have been evaluated but fail to
meet the requirements for a higher NCSC evaluation rating. Division C has two
classes: C1 and C2, which require discretionary (need-to-know) protection.
Division B has three classes: B1, B2, and B3, which require support for
sensitivity labels and increasing robustness of system architecture. Division A
has only class Al, which requires additional assurance through formal
verification methods.
- 4 Mandatory access control, discretionary access control, identification
and authentication, and audit, respectively.
Certification is defined
as "the technical evaluation of a system's security features, made as part of
and in support of the approval/accreditation process, that establishes the
extent to which a particular system's design and implementation meet a set of
specified security requirements" [7]. In this definition, the word evaluation is
used in the generic sense and should not be confused with NCSC evaluation. The
primary distinction is that certification is an evaluation with respect to
specified requirements, and NCSC evaluation is an evaluation against the TCSEC
(and the TNI).
Certification is conducted in support of the accreditation decision. For most
systems, the hardware, system software, applications software, communications
equipment, and the operational facility must be configured and tested during
certification. Certification should be performed by technical personnel
independent of the development organization, according to an acceptable
methodology. Certification should identify the level of security protection with
regard to a procedure, program, or system. Certification results in the issuance
of the Certification Statement, which states whether system security
requirements are met, describes all known remaining vulnerabilities, and advises
the Accreditor relative to the accreditation decision. If requirements are no
met, the Certification Statement lists problem areas and identifies suggested
solutions (if known). A certification documentation package, called the
Certification Report of Findings, submitted to the Accreditor includes the
Certification Statement, certification analysis, results of Security Test and
Evaluation, id results of Operational Test and Evaluation.
Accreditation is "the
managerial authorization and approval granted to an ADP system or network to
process sensitive data in an operational environment, made on the basis of a
certification by designated technical personnel..." [3]. Accreditation is a
management decision to operate a system or network employing specific
safeguards, against a defined threat, at an acceptable level of risk, under a
stated operational concept, with stated interconnections, in a specific
operational environment, with a specific security mode of operation. Other terms
have been used to identify the formal managerial approval for operation; in this
document we use the term Accreditation. FIPS PUB 102 defines Accrediting
Officials as "the agency officials who have authority to accept an application's
security safeguards and issue an accreditation statement that records that
decision. The Accrediting Officials must also possess authority to allocate
resources to achieve acceptable security and to remedy security deficiencies"
[7]. The ultimate responsibility for system security rests with the Accreditor.
DODD 5200.28 employs the term Designated Approving Authority (DAA) to refer to
the same officials or officers [4].
All AIS must be accredited before they may process or use sensitive or
classified information, unless a written waiver is granted by the Accreditor.
Accreditation is based on a technical investigation and a formal review of the
certification Report of Findings. Before authorizing an AIS to operate, the
Accreditor must ensure that satisfactory security measures have been installed
and that any residual risk is within acceptable limits. Often, the Accreditor
must weigh the technical shortcomings of an AIS against operational necessity.
Lacking other ways to accomplish an operational mission, the Accreditor may
determine that it is preferable to accept a residual security risk than to
preclude the mission. To ensure that the accreditation goals and objectives are
adequately met, the Accreditor must be involved throughout the system life
cycle.
A network may be
defined as either an interconnection of accredited AIS or as a Unified Network.
When it is not necessary to differentiate in this guideline, the term network is
used.
The TNI defines a
Network Single Trusted System while DODD 5200.28 Enclosure (5) defines a Unified
Network; this TNIEG conforms to the latter usage. The section of Enclosure (5)
that addresses Unified Networks is brief and instructive 5:
- Some networks may be accredited as a whole without prior accreditation of
their component AIS. It is necessary to treat a network as unified when some
of its AIS subsystems are so specialized or dependent on other subsystems of
the network for security support that individual accreditation of such
subsystems is not possible or meaningful with respect to secure network
operation. In order to be accredited, a Unified Network shall possess a
coherent network architecture and design, and it should be developed with an
attention to security requirements, mechanisms, and assurances commensurate
with the range of sensitivity of information for which it is to be
accredited.
- The recommended approach for accrediting a Unified Network is to apply
Enclosure 4 to the entire network to derive an evaluation class. Requirements
to meet that evaluation class then are obtained from an applicable
interpretation of DOD5200.28-STD [the TCSEC], such as NCSC- TG~05 [the
TNI].
- Enclosure (5) of DODD 5200.28 also discusses Interconnected Accredited
AIS:
- If a network consists of previously accredited AIS, a Memorandum of
Agreement6 [MOA] is required between the DAA of each DOD Component AIS and the
DAA responsible for the network ... The network DAA must ensure that interface
restrictions and limitations are observed for connections between DOD
Component AIS. ... In particular, connections between accredited AIS must be
consistent with the mode of operation of each AIS, the specific sensitivity
level or range of sensitivity levels for which each AIS is accredited, any
additional interface constraints associated with the particular