FOREWORD

This publication is issued by the National Computer
Security Center (NCSC) as part of its program to promulgate
technical computer security guidelines. The interpretations
extend the evaluation classes of the Trusted Systems Evalua-
tion Criteria (DOD 5200.28-STD) to trusted network systems
and components.

This document will be used for a period of at least one
year after date of signature. During this period the NCSC
will gain experience using the Trusted Network Interpreta-
tion in several network evaluations. In addition, the NCSC
will conduct a series of tutorials and workshops to educate
the community on the details of the Trusted Network
Interpretation and receive feedback. After this trial
period, necessary changes to the document will be made and a
revised version issued.

Workshops and tutorials will be open to any member of
the network security community interested in providing feed-
back. Anyone wishing more information, or wishing to pro-
vide comments on the usefulness or correctness of the
Trusted Network Interpretation may contact: Chief, Techni-
cal Guidelines Division, National Computer Security Center,
Ft. George G. Meade, MD 20755-6000, ATTN: C11. The tele-
phone number is (301) 859-4452.

______________________________________________
PATRICK R. GALLAGHER, JR. 31 July 1987
Director
National Computer Security Center

ACKNOWLEDGMENT
______________

Acknowledgment is extended to the members of the Work-
ing Group who produced this Interpretation. Members were:
Alfred Arsenault, National Computer Security Center (Chair);
Dr. Roger Schell, Gemini Computers; Stephen Walker, Trusted
Information Systems; Dr. Marshall Abrams, MITRE; Dr.
Jonathan Millen, MITRE; Leonard LaPadula, MITRE; Robert
Morris, NCSC; and Jack Moskowitz, NCSC. Also due ack-
nowledgement for their many inputs to this interpretation
are Steve Padilla and William Shockley, Gemini Computers.

Introduction
____________

I.1. Scope
_ _ _____

Part I of this document provides interpretations of the
Department of Defense Trusted Computer System Evaluation
Criteria (TCSEC) (DOD-5200.28-STD), for trusted
computer/communications network systems. The specific secu-
rity feature, the assurance requirements, and the rating
structure of the TCSEC are extended to networks of computers
ranging from isolated local area networks to wide-area
internetwork systems.

Part II of this document describes a number of addi-
tional security services (e.g., communications integrity,
denial of service, transmission security) that arise in con-
junction with networks. Those services available in
specific network offerings, while inappropriate for the
rigorous evaluation applied to TCSEC related feature and
assurance requirements, may receive qualitative ratings.

The TCSEC related feature and assurance requirements,
and the additional security services described herein are
intended for the evaluation of trusted network systems
designed to protect a range of sensitive information. As
such, they require that physical, administrative, pro-
cedural, and related protection measures adequate to the
sensitivity of the information being handled are already in
place. It is possible, and indeed common practice, to
operate a network in a secure manner at a single system high
sensitivity level without meeting any trust related feature
or assurance requirements described herein. The full range
of physical and administrative security measures appropriate
to the highest sensitivity level of information on the net-
work must be in place in order to operate a trusted network
as described in this Interpretation.

It is important to note that this Interpretation does
not describe all the security requirements that may be
imposed on a network. Depending upon the particular
environment, there may be communications security (COMSEC),
emanations security, physical security, and other measures
required.

An environmental evaluation process, such as that
described in the ``Computer Security Requirements--Guidance
for Applying the DoD TCSEC in Specific Environments'' (CSC-
STD-003-85), can be used to determine the level of trust
required by specific system environments. Similar analyses
are applicable to networks evaluated under these Interpreta-
tions.

I.2. Purpose
_ _ _______

As with the TCSEC itself, this Interpretation has been
prepared for the following purposes:

1. To provide a standard to manufacturers as to what
security features and assurance levels to build into
their new and planned, commercial network products
in order to provide widely available systems that
satisfy trust requirements for sensitive applica-
tions

2. To provide a metric by which to evaluate the degree
of trust that can be placed in a given network sys-
tem for processing sensitive information

3. To provide a basis for specifying security require-
ments in acquisition specifications.

With respect to the second purpose for development of
the criteria, i.e., providing a security evaluation metric,
evaluations can be delineated into two types: an evaluation
can be performed on a network product from a perspective
that excludes the application environment, or an evaluation
can be done to assess whether appropriate security measures
have been taken to permit the system to be used operation-
ally in a specific environment. The former type of evalua-
tion is done by the National Computer Security Center
through the Commercial Product Evaluation Process.

The latter type of evaluation, those done for the pur-
pose of assessing a system's security attributes with
respect to a specific operational mission, is known as a
certification evaluation. It must be understood that the
completion of a formal product evaluation does not consti-
tute certification or accreditation for the system to be
used in any specific application environment. On the con-
trary, the evaluation report only provides a trusted network
system's evaluation rating along with supporting data
describing the product system's strengths and weaknesses
from a computer security point of view. The system security
certification and the formal approval/accreditation pro-
cedure, done in accordance with the applicable policies of
the issuing agencies, must still be followed before a net-
work can be approved for use in processing or handling clas-
sified information. Designated Approving Authorities (DAAs)
remain ultimately responsible for specifying the security of
systems they accredit.

This Interpretation can be used directly and indirectly
in the certification process. Along with applicable policy,
it can be used directly as technical guidance for evaluation
of the total system and for specifying system security and
certification requirements for new acquisitions. Where a
system being evaluated for certification employs a product
that has undergone a Commercial Product Evaluation, reports
from that process will be used as input to the certification
evaluation. Technical data will be furnished to designers,
evaluators, and the DAAs to support their needs for making
decisions.

The fundamental computer security requirements as
defined in the TCSEC apply to this Interpretation.

I.3. Background
_ _ __________

The term ``sponsor'' is used throughout this document
to represent the individual or entity responsible for
presenting a component or network system for evaluation. The
sponsor may be a manufacturer, vendor, architect, developer,
program manager, or related entity.

A network system is the entire collection of hardware,
firmware, and software necessary to provide a desired func-
tionality.

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 sys-
tem.

Because the term integrity has been used in various
contexts to denote specific aspects of an overall issue, it
is important for the reader to understand the context in
which the term is used in this document. Within Part I, as
in the TCSEC itself, the use of this term is limited to (1)
the correct operation of NTCB hardware/firmware and (2) pro-
tection against unauthorized modification of labels and
data. Specifically, all NTCBs that support sensitivity
labels (viz., Divisions A and B) must, as detailed in the
Label Integrity section of the TCSEC, protect the labels
that represent the sensitivity of information (contained in
objects) and the corresponding authorizations of users (with
subjects as surrogates). In addition, for network systems
with a defined data integrity policy, the NTCB must control
the accesses of users that modify information-. As part of
the NTCB itself, such integrity policies will be supported
by access control mechanisms based on the identity of indi-
viduals (for discretionary integrity) and/or sensitivity
levels (for mandatory integrity). In contrast, within Part
II the term integrity relates to the mechanisms for informa-
tion transfer between distinct components. This communica-
tions integrity includes the issues for correctness of mes-
sage transmission, authentication of source/destination,
data/control/protocol communication field correctness and
related areas.
_________________________
- See, for example, K. J. Biba, Integrity Considera-
_________ _________
tions for Secure Computer Systems, MTR-3153, The MITRE
_____ ___ ______ ________ _______
Corporation, Bedford, MA, June 1975.

In many network environments, encryption can play an
essential role in protecting sensitive information. In Part
I of this document, encryption is referenced as a basis for
providing data and label integrity assurance. In Part II,
encryption is described as a tool for protecting data from
compromise or modification attacks. Encryption algorithms
and their implementation are outside the scope of this docu-
ment. This document was prepared from a DoD perspective and
requires NSA approval relative to the use of encryption. In
other contexts, alternate approval authority may exist.

As with the TCSEC itself, this is a reference document
and is not intended to be used as a tutorial. The reader is
assumed to be familiar with the background literature on
computer security and communications networks=. Part II
assumes a familiarity with the terminology used within ISO
Security Services documentation.

_________________________
= See, for example, M. D. Abrams and H. J. Podell,
Tutorial: Computer and Network Security, IEEE Computer
________ ________ ___ _______ ________
Society Press, 1987.
* ISO 7498/Part 2 - Security Architecture, ISO / TC
___ ____ ____ _ ________ ____________
97 / SC 21 / N1528 / WG 1 Ad hoc group on Security,
Project 97.21.18, September 1986.

I.3.1. Trusted Computer System Evaluation Criteria
_ _ _ _______ ________ ______ __________ ________

The DoD TCSEC was published in December 1985 to provide
a means of evaluating specific security features and
assurance requirements available in ``trusted commercially
available automatic data processing (ADP) systems,''
referred to in this document as Automated Information System
(AIS). The rating scale of the TCSEC extends from a rating
which represents a minimally useful level of trust to one
for ``state of the art'' features and assurance measures.
These technical criteria guide system builders and evalua-
tors in determining the level of trust required for specific
systems. When combined with environmental guidelines,
minimum security protection requirements, and appropriate
accreditation decisions for specific installations can be
determined. The philosophy of protection embodied in the
TCSEC requires that the access of subjects (i.e., human
users or processes acting on their behalf) to objects (i.e.,
containers of sensitive information) be mediated in accor-
dance with an explicit and well defined security policy.

In order to ensure strict compatibility between TCSEC
evaluated AIS and networks and their components, and to
avoid the possible evolution of incompatible evaluation cri-
teria, Part I of this document has been specifically
prepared as an INTERPRETATION of the TCSEC for networks. It
is based entirely on the principles of the TCSEC, uses all
TCSEC basic definitions, and introduces new concepts only
where essential to understanding the TCSEC in a network con-
text. Unless otherwise stated, the TCSEC requirements apply
as written. The approach of interpreting the TCSEC for net-
works in general has already been successfully employed in a
number of specific complex network and AIS applications.

There are several security policy models that may be
used with the reference monitor concept. The Bell-LaPadula
model is commonly used but is not mandated. Similarly for
integrity policy, models such as Biba have been proposed but
are not mandated. For this network interpretation, no
specific access control policy is required; however, it is
necessary that either a secrecy policy, an integrity policy,
or both be specified for enforcement by the reference moni-
tor.

In the context of network systems, there are a number
of additional security services that do not normally arise
in individual AIS, and are not appropriate to the detailed
feature and assurance evaluation prescribed by the TCSEC.
These security services, which may or may not be available
in specific network offerings, include provisions for com-
munications security, denial of service, transmission secu-
rity, and supportive primitives, such as encryption mechan-
isms and protocols. Part II of this document describes
these services and provides a qualitative means of evaluat-
ing their effectiveness when provided.

Evaluation of Part II offered services is dependent
upon the results of the system's Part I evaluation or
component's Appendix A evaluation. A Part II evaluation
rating of good in a component or system which has a low Part
I trust rating is of limited value. The sponsor must iden-
tify which security services are offered by a system or com-
ponent for evaluation against Part II. The evaluators will
normally give a none, minimum, fair or good rating for those
services offered. In some cases, a rating of present is all
that can be given or a quantitative measure of strength may
be used as the basis for rating. A not applicable rating
will be given for services not offered by the product. Part
II services may be provided by mechanisms outside the NTCB.

I.3.2. Two Network Views
_ _ _ ___ _______ _____

DoD Directive 5200.28 (and similar policies elsewhere
in government) establishes the concept of a DAA, an indivi-
dual who is responsible for approving the use of an AIS for
processing classified information. For stand-alone AIS,
this approval process and the technical advisory role to the
DAA provided by the TCSEC are well understood. The same
approval process applies to networks of AIS and plays a key
role in determining how and when networks can be evaluated
using this Interpretation.

Depending upon the operational and technical charac-
teristics of the environment in which a network exists,
either of two views for accreditation and evaluation pur-
poses applies: as a collection of two or more intercon-
nected separately accredited AIS or as a single unified sys-
tem the security accreditation of which is the responsibil-
ity of a single authority.

The security feature and assurance requirements of a
specified network, and hence its suitability for evaluation
under this Interpretation, is greatly impacted by which view
of the network is appropriate.

I.3.2.1. Interconnected Accredited AIS View
_ _ _ _ ______________ __________ ___ ____

The interconnected accredited AIS view is an opera-
tional perspective that recognizes that parts of the network
may be independently created, managed, and accredited.
Where different accrediting jurisdictions are involved, the
joint approval process is required, describing the handling
practices and classification levels that will be exchanged
between the components involved.

Interconnected accredited AIS consist of multiple sys-
tems (some of which may be trusted) that have been indepen-
dently assigned operational sensitivity ranges (the highest
and lowest sensitivity levels of information that may be
simultaneously processed on that system). In this view, the
individual AIS may be thought of as ``devices'' with which
neighboring systems can send and receive information. Each
AIS is accredited to handle sensitive information at a sin-
gle level or over a range between a minimum and maximum
level.

The range of sensitive information that may be
exchanged between two such AIS is a range, agreed upon by
each system's approving authorities, which cannot exceed the
maximum sensitivity levels in common between the two sys-
tems.

Because of the complex structure of a network consist-
ing of interconnected accredited AIS, it may not be practi-
cal to evaluate such a network using this Interpretation or
to assign it a trusted system rating. In this case, the
accreditor is forced to accept the risk of assessing the
security of the network without the benefit of an evaluation
against the principles of the TCSEC as interpreted in Part I
of the document. Appendix C describes the rules for con-
necting separately accredited AIS and the circumstances in
which these rules apply.

I.3.2.2. Single Trusted System View
_ _ _ _ ______ _______ ______ ____

The policy enforcement by trusted components in a
``single trusted system'' exhibits a common level of trust
throughout. A single trusted system is accredited as a sin-
gle entity by a single accrediting authority. (In certain
circumstances where a system will process information from
multiple sensitive sources, more then one accrediting
authority may be involved, but their responsibility will be
for accrediting the whole system as a single entity for use
processing the information for which they have authority.)
Networks such as these can be evaluated against this
Interpretation and given a rating compatible with trusted
AIS evaluated by the TCSEC itself.

A ``single trusted system'' network implements a refer-
ence monitor to enforce the access of subjects to objects in
accordance with an explicit and well defined network secu-
rity policy. The network has a single trusted computing
base, referred to as the Network Trusted Computing Base
(NTCB), which is partitioned (see section I.4.2) among the
network components in a manner that ensures the overall net-
work security policy is enforced by the network as a whole.

Every component that is trusted must enforce a
component-level security policy that may contain elements of
the overall network security policy. The sum of all
component-level security policies must be shown to enforce
the overall network security policy.

There is no requirement that every component in the
network have an NTCB partition nor that any such partition
comprise a complete TCB (e.g., a network component could be
dedicated to supporting the audit function and implement
only that portion of the NTCB). Interaction among NTCB par-
titions shall be via communications channels, operating at
either single or multiple levels as appropriate. The net-
work security architect must identify how the NTCB is parti-
tioned and how all the trusted system requirements are
satisfied.

A given component that does not enforce the full imple-
mentation of all polices (i.e., mandatory access control,
discretionary access control, identification/ authentication
and audit) must be evaluated as a component as specified in
Appendix A. For example, a network architecture that does
not operate above Level 3 of the ISO protocol model and typ-
ically does not enforce discretionary access control must be
evaluated as a component under Appendix A and not as a full
system.

I.3.2.2.1. Connection-Oriented Abstraction
_ _ _ _ _ __________ ________ ___________

In many networking environments, the overall network
security policy includes controlling the establishment of
authorized connections across the network. The access con-
trol mediation performed by the components of these networks
enforces the establishment of connections between host com-
puters on the network in accordance with some form of
authorized connection list. While a connection-oriented
policy may be suitable from an overall network perspective,
specifying such a policy in terms of component level
abstractions may be difficult but is required in order to
evaluate the network.

Individual trusted network components may employ a
local mechanism to enforce mediation only between local sub-
jects and objects, as described in the TCSEC. Some of these
components may have no direct involvement with the enforce-
ment of network connections. Others, however, will have an
additional higher level network connection enforcement role.
This higher level connection-oriented abstraction may be
enforced solely within an individual component or may be
distributed across many components (e.g., in the end-to-end
encryption case, cryptographic front end devices enforce the
network connection authorization decisions made by an access
control/key management center.)

With the connection-oriented abstraction, the role of
the network as a whole in controlling information flow may
be more easily understood, but there may be no simple way to
extend this abstraction to the reference monitor require-
ments of individual components in the network. The overall
network security policy must be decomposed into policy ele-
ments that are allocated to appropriate components and used
as the basis for security policy models for these com-
ponents.

The reference monitor subject/object definitions as
given in the TCSEC represent the fundamental security policy
enforcement at the individual component level but may not
directly describe the overall network security policy issues
such as the network's connection policy. The connection-
oriented abstraction may be essential to understanding the
overall network security policy. The network architecture
must demonstrate the linkage between the connection-oriented
abstraction and its realization in the individual components
of the network.

I.3.2.2.2. Subjects and Objects
_ _ _ _ _ ________ ___ _______

For purposes of this trusted network interpretation,
the terms ``subject'' and ``object'' are defined as in the
TCSEC.

The subjects of a trusted network commonly fall into
two classes: those that serve as direct surrogates for a
user (where ``user'' is synonymous with ``human being''),
and ``internal'' subjects that provide services for other
subjects--typically representing software process rather
than being made part of each user surrogate subject.

There is a set of TCSEC requirements that are directed
at users, rather than subjects. In the network context,
services used to facilitate communications between users and
AIS (e.g., protocol handlers) are usually provided by inter-
nal subjects. Some components that provide only communica-
tions facilitating services have only internal subjects.

Examples of ``single trusted system'' networks or com-
ponents could include- packet-switched communications sub-
networks (as found in the Defense Data Network (DDN), end-
to-end (or host-to-host) encryption systems (such as used in
Blacker or ANSI X9.17 implementations), application level
networks or closed user community systems (such as the Inter
Service/Agency Automated Message Processing Exchange [I S/A
AMPE] and SACDIN Programs), local area networks, digital
PABX systems, private switched networks (such as circuit-
switched telecommunications systems), future Integrated Ser-
vices Digital Network (ISDN) implementations, and a Virtual
Machine Monitor (VMM) on a single computer when analyzed as
a network.

I.4. Evaluation of Networks
_ _ __________ __ ________

The TCSEC provides a means for evaluating the
trustworthiness of a system and assigning an evaluation
class based on its technical properties - independent of the
particular use for or the sensitivity of information being
processed on the system. In this Interpretation, a network
as a whole with its various interconnected components is
recognized as a special instance of a trusted system. The
designer of a trusted system is unconstrained by the TCSEC
on design and implementation choices as long as for the
_________________________
- Examples are employed throughout this document to
clarify the concepts presented. The naming of an exam-
ple implies no judgement of the product or system named
nor on its suitability for any particular purpose.

system as a whole there is a clearly distinguished TCB with
a definitive protection domain boundary. The features and
assurance measures provided within the TCB perimeter will
determine the evaluation class. The network must be viewed
as PARTITIONED into a set of interconnected components,
where each component may have an independent ``NTCB parti-
tion.'' All interaction between such trusted components
must be via ``communication channels or I/O devices'' as
defined by the TCSEC. For Division A and B networks these
will generally be ``multilevel devices.''

I.4.1. Network Security Architecture and Design
_ _ _ _______ ________ ____________ ___ ______

Any network evaluated under this Interpretation must
possess a coherent Network Security Architecture and Design.
(Interconnection of components that do not adhere to such a
Network Security Architecture is addressed in the Intercon-
nection Rules, Appendix C.) The Network Security Architec-
ture must address the security-relevant policies, objec-
tives, and protocols. The Network Security Design specifies
the interfaces and services that must be incorporated into
the network so that it can be evaluated as a trusted entity.
There may be multiple designs that conform to the same
architecture but which are more or less incompatible and
non-interoperable (except through the Interconnection
Rules). Security related mechanisms that require coopera-
tion among components are specified in the design in terms
of their visible interfaces; mechanisms which have no visi-
ble interfaces are not specified in this document but are
left as implementation decisions.

The Network Security Architecture and Design must be
available from the network sponsor before evaluation of the
network, or any component, can be undertaken. The Network
Security Architecture and Design must be sufficiently com-
plete, unambiguous, and free from obvious flaws to permit
the construction or assembly of a trusted network based on
the structure it specifies.

When a component is being designed or presented for
evaluation, or when a network assembled from components is
assembled or presented for evaluation, there must be a
priori evidence that the Network Security Architecture and
Design are satisfied. That is, the components are assembl-
able into a network that conforms in every way with the Net-
work Security Architecture and Design to produce a physical
realization which is trusted to the extent that its evalua-
tion indicates.

In order for a trusted network to be constructed from
components that can be built independently, the Network
Security Architecture and Design must completely and unambi-
guously define the security functionality of components as
well as the interfaces between or among components. The
Network Security Architecture and Design must be evaluated
to determine that a network constructed to its specifica-
tions will in fact be trusted, that is, it will be
evaluatable under these Interpretations.

I.4.2. The Partitioned NTCB
_ _ _ ___ ___________ ____

Like a stand-alone system, the network as a whole
possesses a single TCB, referred to as the NTCB, consisting
of the totality of security-relevant portions of the net-
work. But, unlike a stand-alone system, the design and
evaluation of the network rests on an understanding of how
the security mechanisms are distributed and allocated to
various components, in such a way that the security policy
is supported reliably in spite of (1) the vulnerability of
the communication paths and (2) the concurrent, asynchronous
operation of the network components.

Some distributed systems have reliable, protected com-
munication paths and thus satisfy only the first charac-
teristic of a network: the division into concurrently
operating, communicating processing components. Although
certain interpretations in this Interpretation will not
apply to them, it may be beneficial to employ this Interpre-
tation to evaluate them, and to take advantage of the
interpretations relating to component properties and inter-
faces.

An NTCB that is distributed over a number of network
components is referred to as partitioned, and that part of
the NTCB residing in a given component is referred to as an
NTCB partition. A network host may possess a TCB that has
previously been evaluated as a stand-alone system. Such a
TCB does not necessarily coincide with the NTCB partition in
the host, in the sense of having the same security perime-
ter. Whether it does or not depends on whether the security
policy for which the host TCB was evaluated coincides with
the network security policy, to the extent that it is allo-
cated to that host.

Even when a network host has a TCB that has been previ-
ously evaluated at a given class, and the host's TCB coin-
cides with the host's NTCB partition, there is still no a
priori relationship between the evaluation class of the host
and the evaluation class of the network. Some examples will
be given below to illustrate this point.

To evaluate a network at a given class, each require-
ment in Part I for that class must be satisfied by the net-
work as a whole. It is also necessary to understand how
each requirement is allocated among the network's com-
ponents. Some components, such as the hosts, may satisfy
the entire security policy in isolation; others, such as
packet switches and access control centers, may have more
specialized functions that satisfy only a subset of the net-
work security policy. In addition, distinct subsets of the
network security policy may be allocated to different net-
work components.

Forcing every component to satisfy a specific Part I
requirement is neither necessary nor sufficient to ensure
that the network as a whole meets that requirement.

To show that it is not sufficient, consider two trusted
multilevel AIS that export and import labeled information to
and from each other over a direct connection. Both satisfy
the Label Integrity requirement that a sensitivity label be
accurately and unambiguously associated with exported data.
If they were to have different, incompatible label encodings
for the same sensitive information, the network as a whole
would fail to satisfy the label integrity requirement. As a
result, these Interpretations require at the B1 level and
above that there be uniform labeling of sensitive informa-
tion throughout the network.

To show that it is not necessary, consider the Manda-
tory Access Control requirement that at least two sensi-
tivity levels be supported. Suppose that the network con-
sists of a number of untrusted hosts that are incapable of
maintaining labels and are operating at different levels in
a single-level mode. If they are interconnected through
suitable multilevel interface units, the network as a whole
can support the ``two or more levels'' requirement.

The allocation of a requirement to a component does not
simply mean that the component satisfies the requirement in
isolation, but includes the possibility that it depends on
other components to satisfy the requirement locally, or
cooperates with other components to ensure that the require-
ment is satisfied elsewhere in the network.

Taken together, these examples illustrate the essential
role of an overall network security architecture in design-
ing and evaluating a trusted network.

I.4.3. Component Evaluation
_ _ _ _________ __________

Because network components are often supplied by dif-
ferent vendors and are designed to support standardized or
common functions in a variety of networks, significant
advantages can accrue from a procedure for evaluating indi-
vidual components. The purpose of component evaluation is
to aid both the network designer and the evaluator by per-
forming the evaluation process once and reusing the results
whenever that component is incorporated into a network.

There are four types of security policies that may be
supported by a network component:

1. Mandatory Access Control

2. Discretionary Access Control

3. Supportive policies (e.g., Authentication, Audit)

4. Application policies (e.g., the policy supported
by a DBMS that is distinct from that supported by
the underlying system)

Application level policies are user dependent and will not
be considered further in these Interpretations.

For a component to support a policy such as Mandatory
Access Controls, it must support all the required features
for that policy with all of the required assurances of the
given class.

I.5. Structure of the Document
_ _ _________ __ ___ ________

The remainder of this document is divided into two
parts, three appendices, a list of acronyms, a glossary, and
a list of references. Part I presents TCSEC statements and
detailed interpretations, which together constitute the
requirements against which networks will be evaluated; and
rationale for the network interpretation of the TCSEC. The
TCSEC statement applies as modified by the Interpretation.
Part II is a description of other Security Services not
covered in the TCSEC interpretation which may be applicable
to networks. Appendix A describes the evaluation of network
components. Appendix B describes the rationale for network
partitioning into individual components. Appendix C
describes the interconnect rules for linking interconnected
accredited AIS.

Part I: Interpretations of the
____ _ _______________ __ ___

Trusted Computer System Evaluation Criteria
_______ ________ ______ __________ ________


Highlighting (ALL CAPS) is used in Part I to indicate criteria
not contained in a lower class or changes and additions to
already defined criteria. Where there is no highlighting,
requirements have been carried over from lower classes without
addition or modification.


1.0 DIVISION D: MINIMAL PROTECTION
_ _ ________ _ _______ __________


This division contains only one class. It is reserved for
those systems that have been evaluated but that fail to meet
the requirements for a higher evaluation class.




2.0 DIVISION C: DISCRETIONARY PROTECTION
_ _ ________ _ _____________ __________


Classes in this division provide for discretionary (need-
to-know) protection and, through the inclusion of audit
capabilities, for accountability of subjects and the actions
they initiate.



2.1 CLASS (C1): DISCRETIONARY SECURITY PROTECTION
_ _ _____ __ _____________ ________ __________


THE NETWORK TRUSTED COMPUTING BASE (NTCB) OF A
CLASS (C1) NETWORK SYSTEM NOMINALLY SATISFIES THE
DISCRETIONARY SECURITY REQUIREMENTS BY PROVIDING
SEPARATION OF USERS AND DATA. IT INCORPORATES
SOME FORM OF CREDIBLE CONTROLS CAPABLE OF ENFORC-
ING ACCESS LIMITATIONS ON AN INDIVIDUAL BASIS,
I.E., OSTENSIBLY SUITABLE FOR ALLOWING USERS TO BE
ABLE TO PROTECT PRIVATE OR PROJECT 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 PRO-
CESSING DATA AT THE SAME LEVEL(S) OF SENSITIVITY.
THE FOLLOWING ARE MINIMAL REQUIREMENTS FOR SYSTEMS
ASSIGNED A CLASS (C1) RATING.


2.1.1 Security Policy


+ Statement from DoD 5200.28-STD

Implied from the Introduction to the TCSEC.


+ Interpretation

THE NETWORK SPONSOR SHALL DESCRIBE THE OVERALL NETWORK
SECURITY POLICY ENFORCED BY THE NTCB. AT A MINIMUM, THIS
POLICY SHALL INCLUDE THE DISCRETIONARY REQUIREMENTS APPLICA-
BLE TO THIS CLASS. THE POLICY MAY REQUIRE DATA SECRECY, OR
DATA INTEGRITY, OR BOTH. THE POLICY SHALL INCLUDE A DISCRE-
TIONARY POLICY FOR PROTECTING THE INFORMATION BEING PRO-
CESSED BASED ON THE AUTHORIZATIONS OF USERS OR GROUPS OF
USERS. THIS ACCESS CONTROL POLICY STATEMENT SHALL DESCRIBE
THE REQUIREMENTS ON THE NETWORK TO PREVENT OR DETECT "READ-
ING OR DESTROYING" SENSITIVE INFORMATION BY UNAUTHORIZED
USERS OR ERRORS. UNAUTHORIZED USERS INCLUDE BOTH THOSE THAT
ARE NOT AUTHORIZED TO USE THE NETWORK AT ALL (E.G., A USER
ATTEMPTING TO USE A PASSIVE OR ACTIVE WIRE TAP) OR A LEGITI-
MATE USER OF THE NETWORK WHO IS NOT AUTHORIZED TO ACCESS A
SPECIFIC PIECE OF INFORMATION BEING PROTECTED.

NOTE THAT "USERS" DOES NOT INCLUDE "OPERATORS," "SYSTEM
PROGRAMMERS," "TECHNICAL CONTROL OFFICERS," "SYSTEM SECURITY
OFFICERS," AND OTHER SYSTEM SUPPORT PERSONNEL. THEY ARE
DISTINCT FROM USERS AND ARE SUBJECT TO THE TRUSTED FACILITY
MANUAL AND THE SYSTEM ARCHITECTURE REQUIREMENTS. SUCH INDI-
VIDUALS MAY CHANGE THE SYSTEM PARAMETERS OF THE NETWORK SYS-
TEM, FOR EXAMPLE, BY DEFINING MEMBERSHIP OF A GROUP. THESE
INDIVIDUALS MAY ALSO HAVE THE SEPARATE ROLE OF USERS.

SECRECY POLICY: THE NETWORK SPONSOR SHALL DEFINE THE
FORM OF THE DISCRETIONARY SECRECY POLICY THAT IS
ENFORCED IN THE NETWORK TO PREVENT UNAUTHORIZED
USERS FROM READING THE SENSITIVE INFORMATION
ENTRUSTED TO THE NETWORK.


DATA INTEGRITY POLICY: THE NETWORK SPONSOR SHALL
DEFINE THE DISCRETIONARY INTEGRITY POLICY TO PREVENT
UNAUTHORIZED USERS FROM MODIFYING, VIZ., WRITING,
SENSITIVE INFORMATION. THE DEFINITION OF DATA
INTEGRITY PRESENTED BY THE NETWORK SPONSOR REFERS TO
THE REQUIREMENT THAT THE INFORMATION HAS NOT BEEN
SUBJECTED TO UNAUTHORIZED MODIFICATION IN THE NET-
WORK.


+ Rationale

THE WORD "SPONSOR" IS USED IN PLACE OF ALTERNATIVES
(SUCH AS "VENDOR," "ARCHITECT," "MANUFACTURER," AND
"DEVELOPER") BECAUSE THE ALTERNATIVES INDICATE PEOPLE WHO
MAY NOT BE AVAILABLE, INVOLVED, OR RELEVANT AT THE TIME THAT
A NETWORK SYSTEM IS PROPOSED FOR EVALUATION.

A TRUSTED NETWORK IS ABLE TO CONTROL BOTH THE READING
AND WRITING OF SHARED SENSITIVE INFORMATION. CONTROL OF
WRITING IS USED TO PROTECT AGAINST DESTRUCTION OF INFORMA-
TION. A NETWORK NORMALLY IS EXPECTED TO HAVE POLICY REQUIRE-
MENTS TO PROTECT BOTH THE SECRECY AND INTEGRITY OF THE
INFORMATION ENTRUSTED TO IT. IN A NETWORK THE INTEGRITY IS
FREQUENTLY AS IMPORTANT OR MORE IMPORTANT THAN THE SECRECY
REQUIREMENTS. THEREFORE THE SECRECY AND/OR INTEGRITY POLICY
TO BE ENFORCED BY THE NETWORK MUST BE STATED FOR EACH NET-
WORK REGARDLESS OF ITS EVALUATION CLASS. THE ASSURANCE THAT
THE POLICY IS FAITHFULLY ENFORCED IS REFLECTED IN THE
EVALUATION CLASS OF THE NETWORK.


THIS CONTROL OVER MODIFICATION IS TYPICALLY USED TO
PROTECT INFORMATION SO THAT IT MAY BE RELIED UPON AND TO
CONTROL THE POTENTIAL HARM THAT WOULD RESULT IF THE INFORMA-
TION WERE CORRUPTED. THE OVERALL NETWORK POLICY REQUIRE-
MENTS FOR INTEGRITY INCLUDES THE PROTECTION FOR DATA BOTH
WHILE BEING PROCESSED IN A COMPONENT AND WHILE BEING
TRANSMITTED IN THE NETWORK. THE ACCESS CONTROL POLICY
ENFORCED BY THE NTCB RELATES TO THE ACCESS OF SUBJECTS TO
OBJECTS WITHIN EACH COMPONENT. COMMUNICATIONS INTEGRITY
ADDRESSED WITHIN PART II RELATES TO INFORMATION WHILE BEING
TRANSMITTED.



2.1.1.1 Discretionary Access Control

+ Statement from DoD 5200.28-STD

THE TCB SHALL DEFINE AND CONTROL ACCESS BETWEEN NAMED USERS
AND NAMED OBJECTS (E.G., FILES AND PROGRAMS) IN THE ADP SYS-
TEM. THE ENFORCEMENT MECHANISM (E.G., SELF/GROUP/PUBLIC
CONTROLS, ACCESS CONTROL LISTS) SHALL ALLOW USERS TO SPECIFY
AND CONTROL SHARING OF THOSE OBJECTS BY NAMED INDIVIDUALS OR
DEFINED GROUPS OF INDIVIDUALS, OR BOTH.


+ Interpretation

THE DISCRETIONARY ACCESS CONTROL (DAC) MECHANISM(S) MAY
BE DISTRIBUTED OVER THE PARTITIONED NTCB IN VARIOUS WAYS.
SOME PART, ALL, OR NONE OF THE DAC MAY BE IMPLEMENTED IN A
GIVEN COMPONENT OF THE NETWORK SYSTEM. IN PARTICULAR, COM-
PONENTS THAT SUPPORT ONLY INTERNAL SUBJECTS (I.E., THAT HAVE
NO SUBJECTS ACTING AS DIRECT SURROGATES FOR USERS), SUCH AS
A PUBLIC NETWORK PACKET SWITCH, MIGHT NOT IMPLEMENT THE DAC
MECHANISM(S) DIRECTLY (E.G., THEY ARE UNLIKELY TO CONTAIN
ACCESS CONTROL LISTS).

IDENTIFICATION OF USERS BY GROUPS MAY BE ACHIEVED IN
VARIOUS WAYS IN THE NETWORKING ENVIRONMENT. FOR EXAMPLE,
THE NETWORK IDENTIFIERS (E.G., INTERNET ADDRESSES) FOR VARI-
OUS COMPONENTS (E.G., HOSTS, GATEWAYS) CAN BE USED AS IDEN-
TIFIERS OF GROUPS OF INDIVIDUAL USERS (E.G., "ALL USERS AT
HOST A," "ALL USERS OF NETWORK Q") WITHOUT EXPLICIT IDENTIF-
ICATION OF INDIVIDUAL USERS, NOR EVEN AN EXPLICIT NUMBER OF
USERS IMPLIED), IF THIS IS CONSISTENT WITH THE NETWORK SECU-
RITY POLICY.

FOR NETWORKS, INDIVIDUAL HOSTS WILL IMPOSE NEED-TO-KNOW
CONTROLS OVER THEIR USERS - MUCH LIKE (IN FACT, PROBABLY THE
SAME) CONTROLS USED WHEN THERE IS NO NETWORK CONNECTION.

WHEN GROUP IDENTIFIERS ARE ACCEPTABLE FOR ACCESS CON-
TROL, THE IDENTIFIER OF SOME OTHER HOST MAY BE EMPLOYED, TO
ELIMINATE THE MAINTENANCE THAT WOULD BE REQUIRED IF INDIVI-
DUAL IDENTIFICATION OF REMOTE USERS WAS EMPLOYED.

THE DAC MECHANISM OF A NTCB PARTITION MAY BE IMPLE-
MENTED AT THE INTERFACE OF THE REFERENCE MONITOR OR MAY BE
DISTRIBUTED IN SUBJECTS THAT ARE PART OF THE NTCB IN THE
SAME OR DIFFERENT COMPONENT. THE REFERENCE MONITOR MANAGES
ALL THE PHYSICAL RESOURCES OF THE SYSTEM AND FROM THEM
CREATES THE ABSTRACTION OF SUBJECTS AND OBJECTS THAT IT CON-
TROLS. SOME OF THESE SUBJECTS AND OBJECTS MAY BE USED TO
IMPLEMENT A PART OF THE NTCB.

WHEN INTEGRITY IS INCLUDED AS PART OF THE NETWORK DIS-
CRETIONARY SECURITY POLICY, THE ABOVE INTERPRETATIONS SHALL
BE SPECIFICALLY APPLIED TO THE CONTROLS OVER MODIFICATION,
VIZ, THE WRITE MODE OF ACCESS, WITHIN EACH COMPONENT BASED
ON IDENTIFIED USERS OR GROUPS OF USERS.


+ Rationale

IN THIS CLASS, THE SUPPORTING ELEMENTS OF THE OVERALL
DAC MECHANISM ARE TREATED EXACTLY AS UNTRUSTED SUBJECTS ARE
TREATED WITH RESPECT TO DAC IN AN ADP SYSTEM, WITH THE SAME
RESULT AS NOTED IN THE INTERPRETATION. STRENGTHENING OF THE
DAC MECHANISM IN THE NETWORK ENVIRONMENT IS PROVIDED IN
CLASS (C2) (SEE THE DISCRETIONARY ACCESS CONTROL SECTION).

A TYPICAL SITUATION FOR DAC IS THAT A SURROGATE PROCESS
FOR A REMOTE USER WILL BE CREATED IN SOME HOST FOR ACCESS TO
OBJECTS UNDER THE CONTROL OF THE NTCB PARTITION WITHIN THAT
HOST. THE INTERPRETATION REQUIRES THAT A USER IDENTIFIER BE
ASSIGNED AND MAINTAINED FOR EACH SUCH PROCESS BY THE NTCB,
SO THAT ACCESS BY A SURROGATE PROCESS IS SUBJECT TO ESSEN-
TIALLY THE SAME DISCRETIONARY CONTROLS AS ACCESS BY A PRO-
CESS ACTING ON BEHALF OF A LOCAL USER WOULD BE. HOWEVER,
WITHIN THIS INTERPRETATION A RANGE OF POSSIBLE INTERPRETA-
TIONS OF THE ASSIGNED USER IDENTIFICATION IS PERMITTED.

THE MOST OBVIOUS SITUATION WOULD EXIST IF A GLOBAL
DATABASE OF NETWORK USERS WERE TO BE MADE PERMANENTLY AVAIL-
ABLE ON DEMAND TO EVERY HOST, (I.E., A NAME SERVER EXISTED)
SO THAT ALL USER IDENTIFICATIONS WERE GLOBALLY MEANINGFUL.

IT IS ALSO ACCEPTABLE, HOWEVER, FOR SOME NTCB PARTI-
TIONS TO MAINTAIN A DATABASE OF LOCALLY-REGISTERED USERS FOR
ITS OWN USE. IN SUCH A CASE, ONE COULD CHOOSE TO INHIBIT
THE CREATION OF SURROGATE PROCESSES FOR LOCALLY UNREGISTERED
USERS, OR (IF PERMITTED BY THE LOCAL POLICY) ALTERNATIVELY,
TO PERMIT THE CREATION OF SURROGATE PROCESSES WITH
PRESELECTED USER AND GROUP IDENTIFIERS WHICH, IN EFFECT,
IDENTIFY THE PROCESS AS EXECUTING ON BEHALF OF A MEMBER OF A
GROUP OF USERS ON A PARTICULAR REMOTE HOST. THE INTENT OF
THE WORDS CONCERNING AUDIT IN THE INTERPRETATION IS TO PRO-
VIDE A MINIMALLY ACCEPTABLE DEGREE OF AUDITABILITY FOR CASES
SUCH AS THE LAST DESCRIBED. WHAT IS REQUIRED IS THAT THERE
BE A CAPABILITY, USING THE AUDIT FACILITIES PROVIDED BY THE
NETWORK NTCB PARTITIONS INVOLVED, TO DETERMINE WHO WAS
LOGGED IN AT THE ACTUAL HOST OF THE GROUP OF REMOTE USERS AT
THE TIME THE SURROGATE PROCESSING OCCURED.

ASSOCIATING THE PROPER USER ID WITH A SURROGATE PROCESS
IS THE JOB OF IDENTIFICATION AND AUTHENTICATION. THIS MEANS
THAT DAC IS APPLIED LOCALLY, WITH RESPECT TO THE USER ID OF
THE SURROGATE PROCESS. THE TRANSMISSION OF THE DATA BACK
ACROSS THE NETWORK TO THE USER'S HOST, AND THE CREATION OF A
COPY OF THE DATA THERE, IS NOT THE BUSINESS OF DAC.

COMPONENTS THAT SUPPORT ONLY INTERNAL SUBJECTS IMPACT
THE IMPLEMENTATION OF THE DAC BY PROVIDING SERVICES BY WHICH
INFORMATION (E.G., A USER-ID) IS MADE AVAILABLE TO A COM-
PONENT THAT MAKES A DAC DECISION. AN EXAMPLE OF THE LATTER
WOULD BE THE CASE THAT A USER AT HOST A ATTEMPTS TO ACCESS A
FILE AT HOST B. THE DAC DECISION MIGHT BE (AND USUALLY
WOULD BE) MADE AT HOST B ON THE BASIS OF A USER-ID TRANSMIT-
TED FROM HOST A TO HOST B.

UNIQUE USER IDENTIFICATION MAY BE ACHIEVED BY A VARIETY
OF MECHANISMS, INCLUDING (A) A REQUIREMENT FOR UNIQUE IDEN-
TIFICATION AND AUTHENTICATION ON THE HOST WHERE ACCESS TAKES
PLACE; (B) RECOGNITION OF FULLY QUALIFIED NETWORK
ADDRESSES AUTHENTICATED BY ANOTHER HOST AND FORWARDED TO THE
HOST WHERE ACCESS TAKES PLACE; OR (C) ADMINISTRATIVE SUPPORT
OF A NETWORK-WIDE UNIQUE PERSONNEL IDENTIFIER THAT COULD BE
AUTHENTICATED AND FORWARDED BY ANOTHER HOST AS IN (B) ABOVE,
OR COULD BE AUTHENTICATED AND FORWARDED BY A DEDICATED NET-
WORK IDENTIFICATION AND AUTHENTICATION SERVER. THE PROTO-
COLS WHICH IMPLEMENT (B) OR (C) ARE SUBJECT TO THE SYSTEM
ARCHITECTURE REQUIREMENTS.

NETWORK SUPPORT FOR DAC MIGHT BE HANDLED IN OTHER WAYS
THAN THAT DESCRIBED AS "TYPICAL" ABOVE. IN PARTICULAR, SOME
FORM OF CENTRALIZED ACCESS CONTROL IS OFTEN PROPOSED. AN
ACCESS CONTROL CENTER MAY MAKE ALL DECISIONS FOR DAC, OR IT
MAY SHARE THE BURDEN WITH THE HOSTS BY CONTROLLING HOST-TO-
HOST CONNECTIONS, AND LEAVING THE HOSTS TO DECIDE ON ACCESS
TO THEIR OBJECTS BY USERS AT A LIMITED SET OF REMOTE HOSTS.
IN THIS CASE THE ACCESS CONTROL CENTER PROVIDES THE LINKAGE
BETWEEN THE CONNECTION ORIENTED ABSTRACTION (AS DISCUSSED IN
THE INTRODUCTION) AND THE OVERALL NETWORK SECURITY POLICY
FOR DAC. IN ALL CASES THE ENFORCEMENT OF THE DECISION MUST
BE PROVIDED BY THE HOST WHERE THE OBJECT RESIDES.


2.1.2 Accountability


2.1.2.1 Identification and Authentication

+ Statement from DoD 5200.28-STD

THE TCB SHALL REQUIRE USERS TO IDENTIFY THEMSELVES TO IT
BEFORE BEGINNING TO PERFORM ANY OTHER ACTIONS THAT THE TCB
IS EXPECTED TO MEDIATE. FURTHERMORE, THE TCB SHALL USE A
PROTECTED MECHANISM (E.G., PASSWORDS) TO AUTHENTICATE THE
USER'S IDENTITY. THE TCB SHALL PROTECT AUTHENTICATION DATA
SO THAT IT CANNOT BE ACCESSED BY ANY UNAUTHORIZED USER.

+ Interpretation

THE REQUIREMENT FOR IDENTIFICATION AND AUTHENTICATION
OF USERS IS THE SAME FOR A NETWORK SYSTEM AS FOR AN ADP SYS-
TEM. THE IDENTIFICATION AND AUTHENTICATION MAY BE DONE BY
THE COMPONENT TO WHICH THE USER IS DIRECTLY CONNECTED OR
SOME OTHER COMPONENT, SUCH AS AN IDENTIFICATION AND AUTHEN-
TICATION SERVER. AVAILABLE TECHNIQUES, SUCH AS THOSE
DESCRIBED IN THE PASSWORD GUIDELINE=, ARE GENERALLY ALSO
APPLICABLE IN THE NETWORK CONTEXT. HOWEVER, IN CASES WHERE
THE NTCB IS EXPECTED TO MEDIATE ACTIONS OF A HOST (OR OTHER
NETWORK COMPONENT) THAT IS ACTING ON BEHALF OF A USER OR
GROUP OF USERS, THE NTCB MAY EMPLOY IDENTIFICATION AND
AUTHENTICATION OF THE HOST (OR OTHER COMPONENT) IN LIEU OF
IDENTIFICATION AND AUTHENTICATION OF AN INDIVIDUAL USER.

AUTHENTICATION INFORMATION, INCLUDING THE IDENTITY OF A
USER (ONCE AUTHENTICATED) MAY BE PASSED FROM ONE COMPONENT
TO ANOTHER WITHOUT REAUTHENTICATION, SO LONG AS THE NTCB
PROTECTS (E.G., BY ENCRYPTION) THE INFORMATION FROM UNAU-
THORIZED DISCLOSURE AND MODIFICATION. THIS PROTECTION SHALL
PROVIDE AT LEAST A SIMILAR LEVEL OF ASSURANCE (OR STRENGTH
OF MECHANISM) AS PERTAINS TO THE PROTECTION OF THE AUTHENTI-
CATION MECHANISM AND AUTHENTICATION DATA.


+ Rationale

THE NEED FOR ACCOUNTABILITY IS NOT CHANGED IN THE CON-
TEXT OF A NETWORK SYSTEM. THE FACT THAT THE NTCB IS PARTI-
TIONED OVER A SET OF COMPONENTS NEITHER REDUCES THE NEED NOR
IMPOSES NEW REQUIREMENTS. THAT IS, INDIVIDUAL ACCOUNTABIL-
ITY IS STILL THE OBJECTIVE. HOWEVER, IN THE CONTEXT OF A
NETWORK SYSTEM AT THE (C1) LEVEL (WHEREIN EXPLICIT INDIVI-
DUAL USER ACCOUNTABILITY IS NOT REQUIRED), "INDIVIDUAL
ACCOUNTABILITY" CAN BE SATISFIED BY IDENTIFICATION OF A HOST
(OR OTHER COMPONENT). IN ADDITION, THERE IS NO NEED IN A
DISTRIBUTED PROCESSING SYSTEM LIKE A NETWORK TO REAUTHENTI-
CATE A USER AT EACH POINT IN THE NETWORK WHERE A PROJECTION
OF A USER (VIA THE SUBJECT OPERATING ON BEHALF OF THE USER)
INTO ANOTHER REMOTE SUBJECT TAKES PLACE.

THE PASSING OF IDENTIFIERS AND/OR AUTHENTICATION INFOR-
MATION FROM ONE COMPONENT TO ANOTHER IS USUALLY DONE IN SUP-
PORT TO THE IMPLEMENTATION OF THE DISCRETIONARY ACCESS CON-
TROL (DAC). THIS SUPPORT RELATES DIRECTLY TO THE DAC
REGARDING ACCESS BY A USER TO A STORAGE OBJECT IN A DIF-
FERENT NTCB PARTITION THAN THE ONE WHERE THE USER WAS
AUTHENTICATED. EMPLOYING A FORWARDED IDENTIFICATION IMPLIES
ADDITIONAL RELIANCE ON THE SOURCE AND COMPONENTS ALONG THE
PATH.


2.1.3 Assurance


2.1.3.1 Operational Assurance


2.1.3.1.1 System Architecture

+ Statement from DoD 5200.28-STD

THE TCB SHALL MAINTAIN A DOMAIN FOR ITS OWN EXECUTION THAT
PROTECTS IT FROM EXTERNAL INTERFERENCE OR TAMPERING (E.G.,
BY MODIFICATION OF ITS CODE OR DATA STRUCTURES). RESOURCES
CONTROLLED BY THE TCB MAY BE A DEFINED SUBSET OF THE SUB-
JECTS AND OBJECTS IN THE ADP SYSTEM.

+ Interpretation

THE SYSTEM ARCHITECTURE CRITERION MUST BE MET INDIVIDU-
ALLY BY ALL NTCB PARTITIONS. IMPLEMENTATION OF THE REQUIRE-
MENT THAT THE NTCB MAINTAIN A DOMAIN FOR ITS OWN EXECUTION
IS ACHIEVED BY HAVING EACH NTCB PARTITION MAINTAIN A DOMAIN
FOR ITS OWN EXECUTION.

THE SUBSET OF NETWORK RESOURCES OVER WHICH THE NTCB HAS
CONTROL ARE THE UNION OF THE SETS OF RESOURCES OVER WHICH
THE NTCB PARTITIONS HAVE CONTROL. CODE AND DATA STRUCTURES
BELONGING TO THE NTCB, TRANSFERRED AMONG NTCB SUBJECTS
(I.E., SUBJECTS OUTSIDE THE REFERENCE MONITOR BUT INSIDE THE
NTCB) BELONGING TO DIFFERENT NTCB PARTITIONS, MUST BE PRO-
TECTED AGAINST EXTERNAL INTERFERENCE OR TAMPERING. FOR
EXAMPLE, A CRYPTOGRAPHIC CHECKSUM OR PHYSICAL MEANS MAY BE
EMPLOYED TO PROTECT USER AUTHENTICATION DATA EXCHANGED
BETWEEN NTCB PARTITIONS.

+ Rationale

THE REQUIREMENT FOR THE PROTECTION OF COMMUNICATIONS
BETWEEN NTCB PARTITIONS IS SPECIFICALLY DIRECTED TO SUBJECTS
THAT ARE PART OF THE NTCB PARTITIONS. ANY REQUIREMENTS FOR
SUCH PROTECTION FOR THE SUBJECTS THAT ARE OUTSIDE THE NTCB
PARTITIONS ARE ADDRESSED IN RESPONSE TO THE INTEGRITY
REQUIREMENTS OF THE SECURITY POLICY.


2.1.3.1.2 System Integrity

+ Statement from DoD 5200.28-STD

HARDWARE AND/OR SOFTWARE FEATURES SHALL BE PROVIDED THAT CAN
BE USED TO PERIODICALLY VALIDATE THE CORRECT OPERATION OF
THE ON-SITE HARDWARE AND FIRMWARE ELEMENTS OF THE TCB.

+ Interpretation

IMPLEMENTATION OF THE REQUIREMENT IS PARTLY ACHIEVED BY
HAVING HARDWARE AND/OR SOFTWARE FEATURES THAT CAN BE USED TO
PERIODICALLY VALIDATE THE CORRECT OPERATION OF THE HARDWARE
AND FIRMWARE ELEMENTS OF EACH COMPONENT'S NTCB PARTITION.
FEATURES SHALL ALSO BE PROVIDED TO VALIDATE THE IDENTITY AND
CORRECT OPERATION OF A COMPONENT PRIOR TO ITS INCORPORATION
IN THE NETWORK SYSTEM AND THROUGHOUT SYSTEM OPERATION. FOR
EXAMPLE, A PROTOCOL COULD BE DESIGNED THAT ENABLES THE COM-
PONENTS OF THE PARTITIONED NTCB TO EXCHANGE MESSAGES PERIOD-
ICALLY AND VALIDATE EACH OTHER'S CORRECT RESPONSE. THE PRO-
TOCOL SHALL BE ABLE TO DETERMINE THE REMOTE ENTITY'S ABILITY
TO RESPOND. NTCB PARTITIONS SHALL PROVIDE THE CAPABILITY TO
REPORT TO NETWORK ADMINISTRATIVE PERSONNEL THE FAILURES
DETECTED IN OTHER NTCB PARTITIONS.

INTERCOMPONENT PROTOCOLS IMPLEMENTED WITHIN A NTCB
SHALL BE DESIGNED IN SUCH A WAY AS TO PROVIDE CORRECT OPERA-
TION IN THE CASE OF FAILURES OF NETWORK COMMUNICATIONS OR
INDIVIDUAL COMPONENTS. THE ALLOCATION OF DISCRETIONARY
ACCESS CONTROL POLICY IN A NETWORK MAY REQUIRE COMMUNICATION
BETWEEN TRUSTED SUBJECTS THAT ARE PART OF THE NTCB PARTI-
TIONS IN DIFFERENT COMPONENTS. THIS COMMUNICATION IS NOR-
MALLY IMPLEMENTED WITH A PROTOCOL BETWEEN THE SUBJECTS AS
PEER ENTITIES. INCORRECT ACCESS WITHIN A COMPONENT SHALL
NOT RESULT FROM FAILURE OF AN NTCB PARTITION TO COMMUNICATE
WITH OTHER COMPONENTS.

+ Rationale

THE FIRST PARAGRAPH OF THE INTERPRETATION IS A
STRAIGHTFORWARD EXTENSION OF THE REQUIREMENT INTO THE CON-
TEXT OF A NETWORK SYSTEM AND PARTITIONED NTCB AS DEFINED FOR
THESE NETWORK CRITERIA.

NTCB PROTOCOLS SHOULD BE ROBUST ENOUGH SO THAT THEY
PERMIT THE SYSTEM TO OPERATE CORRECTLY IN THE CASE OF LOCAL-
IZED FAILURE. THE PURPOSE OF THIS PROTECTION IS TO PRESERVE
THE INTEGRITY OF THE NTCB ITSELF. IT IS NOT UNUSUAL FOR ONE
OR MORE COMPONENTS IN A NETWORK TO BE INOPERATIVE AT ANY
TIME, SO IT IS IMPORTANT TO MINIMIZE THE EFFECTS OF SUCH
FAILURES ON THE REST OF THE NETWORK. ADDITIONAL INTEGRITY
AND DENIAL OF SERVICE ISSUES ARE ADDRESSED IN PART II.


2.1.3.2 Life-Cycle Assurance


2.1.3.2.1 Security Testing

+ Statement from DoD 5200.28-STD

THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED
AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION.
TESTING SHALL BE DONE TO ASSURE THAT THERE ARE NO OBVIOUS
WAYS FOR AN UNAUTHORIZED USER TO BYPASS OR OTHERWISE DEFEAT
THE SECURITY PROTECTION MECHANISMS OF THE TCB. (SEE THE
SECURITY TESTING GUIDELINES.)

+ Interpretation

TESTING OF A COMPONENT WILL REQUIRE A TESTBED THAT
EXERCISES THE INTERFACES AND PROTOCOLS OF THE COMPONENT.
THE TESTING OF A SECURITY MECHANISM OF THE NETWORK SYSTEM
FOR MEETING THIS CRITERION SHALL BE AN INTEGRATED TESTING
PROCEDURE INVOLVING ALL COMPONENTS CONTAINING AN NTCB PARTI-
TION THAT IMPLEMENT THE GIVEN MECHANISM. THIS INTEGRATED
TESTING IS ADDITIONAL TO ANY INDIVIDUAL COMPONENT TESTS
INVOLVED IN THE EVALUATION OF THE NETWORK SYSTEM. THE SPON-
SOR SHOULD IDENTIFY THE ALLOWABLE SET OF CONFIGURATIONS
INCLUDING THE SIZES OF THE NETWORKS. ANALYSIS OR TESTING
PROCEDURES AND TOOLS SHALL BE AVAILABLE TO TEST THE LIMITS
OF THESE CONFIGURATIONS. A CHANGE IN CONFIGURATION WITHIN
THE ALLOWABLE SET OF CONFIGURATIONS DOES NOT REQUIRE RETEST-
ING.

+ Rationale

TESTING IS THE PRIMARY METHOD AVAILABLE IN THIS EVALUA-
TION DIVISION TO GAIN ANY ASSURANCE THAT THE SECURITY
MECHANISMS PERFORM THEIR INTENDED FUNCTION.

2.1.4 Documentation

2.1.4.1 Security Features User's Guide

+ Statement from DoD 5200.28-STD

A SINGLE SUMMARY, CHAPTER, OR MANUAL IN USER DOCUMENTATION
SHALL DESCRIBE THE PROTECTION MECHANISMS PROVIDED BY THE
TCB, INTERPRETATIONS ON THEIR USE, AND HOW THEY INTERACT
WITH ONE ANOTHER.

+ Interpretation

THIS USER DOCUMENTATION DESCRIBES USER VISIBLE PROTEC-
TION MECHANISMS AT THE GLOBAL (NETWORK SYSTEM) LEVEL AND AT
THE USER INTERFACE OF EACH COMPONENT, AND THE INTERACTION
AMONG THESE.

+ Rationale

THE INTERPRETATION IS AN EXTENSION OF THE REQUIREMENT
INTO THE CONTEXT OF A NETWORK SYSTEM AS DEFINED FOR THESE
NETWORK CRITERIA. DOCUMENTATION OF PROTECTION MECHANISMS
PROVIDED BY INDIVIDUAL COMPONENTS IS REQUIRED BY THE CRI-
TERIA FOR TRUSTED COMPUTER SYSTEMS THAT ARE APPLIED AS
APPROPRIATE FOR THE INDIVIDUAL COMPONENTS.


2.1.4.2 Trusted Facility Manual

+ Statement from DoD 5200.28-STD

A MANUAL ADDRESSED TO THE ADP SYSTEM ADMINISTRATOR SHALL
PRESENT CAUTIONS ABOUT FUNCTIONS AND PRIVILEGES THAT SHOULD
BE CONTROLLED WHEN RUNNING A SECURE FACILITY.

+ Interpretation

THIS MANUAL SHALL CONTAIN SPECIFICATIONS AND PROCEDURES
TO ASSIST THE SYSTEM ADMINISTRATOR(S) MAINTAIN COGNIZANCE OF
THE NETWORK CONFIGURATION. THESE SPECIFICATIONS AND PRO-
CEDURES SHALL ADDRESS THE FOLLOWING:

1.THE HARDWARE CONFIGURATION OF THE NETWORK ITSELF;

2.THE IMPLICATIONS OF ATTACHING NEW COMPONENTS TO THE
NETWORK;

3.THE CASE WHERE CERTAIN COMPONENTS MAY PERIODICALLY
LEAVE THE NETWORK (E.G., BY CRASHING, OR BY BEING
DISCONNECTED) AND THEN REJOIN;

4.NETWORK CONFIGURATION ASPECTS THAT CAN IMPACT THE
SECURITY OF THE NETWORK SYSTEM; (FOR EXAMPLE, THE
MANUAL SHOULD DESCRIBE FOR THE NETWORK SYSTEM
ADMINISTRATOR THE INTERCONNECTIONS AMONG COMPONENTS
THAT ARE CONSISTENT WITH THE OVERALL NETWORK SYSTEM
ARCHITECTURE.)

5.LOADING OR MODIFYING NTCB SOFTWARE OR FIRMWARE
(E.G., DOWN-LINE LOADING).

THE PHYSICAL AND ADMINISTRATIVE ENVIRONMENTAL CONTROLS
SHALL BE SPECIFIED. ANY ASSUMPTIONS ABOUT SECURITY OF A
GIVEN NETWORK SHOULD BE CLEARLY STATED (E.G., THE FACT THAT
ALL COMMUNICATIONS LINKS MUST BE PHYSICALLY PROTECTED TO A
CERTAIN LEVEL).


+ Rationale

THERE MAY BE MULTIPLE SYSTEM ADMINISTRATORS WITH
DIVERSE RESPONSIBILITIES. THE TECHNICAL SECURITY MEASURES
DESCRIBED BY THESE CRITERIA MUST BE USED IN CONJUNCTION WITH
OTHER FORMS OF SECURITY IN ORDER TO ACHIEVE SECURITY OF THE
NETWORK. ADDITIONAL FORMS INCLUDE ADMINISTRATIVE SECURITY,
PHYSICAL SECURITY, EMANATIONS SECURITY, ETC.


EXTENSION OF THIS CRITERION TO COVER CONFIGURATION
ASPECTS OF THE NETWORK IS NEEDED BECAUSE, FOR EXAMPLE,
PROPER INTERCONNECTION OF COMPONENTS IS TYPICALLY ESSENTIAL
TO ACHIEVE A CORRECT REALIZATION OF THE NETWORK ARCHITEC-
TURE.


CRYPTOGRAPHY IS ONE COMMON MECHANISM EMPLOYED TO PRO-
TECT COMMUNICATION CIRCUITS. ENCRYPTION TRANSFORMS THE
REPRESENTATION OF INFORMATION SO THAT IT IS UNINTELLIGIBLE
TO UNAUTHORIZED SUBJECTS. REFLECTING THIS TRANSFORMATION,
THE SENSITIVITY OF THE CIPHERTEXT IS GENERALLY LOWER THAN
THE CLEARTEXT. IF ENCRYPTION METHODOLOGIES ARE EMPLOYED,
THEY SHALL BE APPROVED BY THE NATIONAL SECURITY AGENCY
(NSA).

THE ENCRYPTION ALGORITHM AND ITS IMPLEMENTATION ARE
OUTSIDE THE SCOPE OF THESE INTERPRETATIONS. THIS ALGORITHM
AND IMPLEMENTATION MAY BE IMPLEMENTED IN A SEPARATE DEVICE
OR MAY BE A FUNCTION OF A SUBJECT IN A COMPONENT NOT DEDI-
CATED TO ENCRYPTION. WITHOUT PREJUDICE, EITHER IMPLEMENTA-
TION PACKAGING IS REFERRED TO AS AN ENCRYPTION MECHANISM
HEREIN.

2.1.4.3 Test Documentation

+ Statement from DoD 5200.28-STD

THE SYSTEM DEVELOPER SHALL PROVIDE TO THE EVALUATORS A DOCU-
MENT THAT DESCRIBES THE TEST PLAN, TEST PROCEDURES THAT SHOW
HOW THE SECURITY MECHANISMS WERE TESTED, AND RESULTS OF THE
SECURITY MECHANISMS' FUNCTIONAL TESTING.


+ Interpretation

THE "SYSTEM DEVELOPER" IS INTERPRETED AS "THE NETWORK
SYSTEM SPONSOR". THE DESCRIPTION OF THE TEST PLAN SHOULD
ESTABLISH THE CONTEXT IN WHICH THE TESTING WAS OR SHOULD BE
CONDUCTED. THE DESCRIPTION SHOULD IDENTIFY ANY ADDITIONAL
TEST COMPONENTS THAT ARE NOT PART OF THE SYSTEM BEING
EVALUATED. THIS INCLUDES A DESCRIPTION OF THE TEST-RELEVANT
FUNCTIONS OF SUCH TEST COMPONENTS AND A DESCRIPTION OF THE
INTERFACING OF THOSE TEST COMPONENTS TO THE SYSTEM BEING
EVALUATED. THE DESCRIPTION OF THE TEST PLAN SHOULD ALSO
DEMONSTRATE THAT THE TESTS ADEQUATELY COVER THE NETWORK
SECURITY POLICY. THE TESTS SHOULD INCLUDE THE FEATURES
DESCRIBED IN THE SYSTEM ARCHITECTURE AND THE SYSTEM
INTEGRITY SECTIONS. THE TESTS SHOULD ALSO INCLUDE NETWORK
CONFIGURATION AND SIZING.

+ Rationale

THE ENTITY BEING EVALUATED MAY BE A NETWORKING SUBSYS-
TEM (SEE APPENDIX A) TO WHICH OTHER COMPONENTS MUST BE ADDED
TO MAKE A COMPLETE NETWORK SYSTEM. IN THAT CASE, THIS
INTERPRETATION IS EXTENDED TO INCLUDE CONTEXTUAL DEFINITION
BECAUSE, AT EVALUATION TIME, IT IS NOT POSSIBLE TO VALIDATE
THE TEST PLANS WITHOUT THE DESCRIPTION OF THE CONTEXT FOR
TESTING THE NETWORKING SUBSYSTEM.



2.1.4.4 Design Documentation

+ Statement from DoD 5200.28-STD

DOCUMENTATION SHALL BE AVAILABLE THAT PROVIDES A DESCRIPTION
OF THE MANUFACTURER'S PHILOSOPHY OF PROTECTION AND AN EXPLA-
NATION OF HOW THIS PHILOSOPHY IS TRANSLATED INTO THE TCB. IF
THE TCB IS COMPOSED OF DISTINCT MODULES, THE INTERFACES
BETWEEN THESE MODULES SHALL BE DESCRIBED.

+ Interpretation

EXPLANATION OF HOW THE SPONSOR'S PHILOSOPHY OF PROTEC-
TION IS TRANSLATED INTO THE NTCB SHALL INCLUDE A DESCRIPTION
OF HOW THE NTCB IS PARTITIONED. THE SECURITY POLICY ALSO
SHALL BE STATED. THE DESCRIPTION OF THE INTERFACES BETWEEN
THE NTCB MODULES SHALL INCLUDE THE INTERFACE(S) BETWEEN NTCB
PARTITIONS AND MODULES WITHIN THE PARTITIONS IF THE MODULES
EXIST. THE SPONSOR SHALL DESCRIBE THE SECURITY ARCHITECTURE
AND DESIGN, INCLUDING THE ALLOCATION OF SECURITY REQUIRE-
MENTS AMONG COMPONENTS. APPENDIX A ADDRESSES COMPONENT
EVALUATION ISSUES.

+ Rationale

THE INTERPRETATION IS A STRAIGHTFORWARD EXTENSION OF
THE REQUIREMENT INTO THE CONTEXT OF A NETWORK SYSTEM AS
DEFINED FOR THIS NETWORK INTERPRETATION. OTHER DOCUMENTA-
TION, SUCH AS DESCRIPTION OF COMPONENTS AND DESCRIPTION OF
OPERATING ENVIRONMENT(S) IN WHICH THE NETWORKING SUBSYSTEM
OR NETWORK SYSTEM IS DESIGNED TO FUNCTION, IS REQUIRED ELSE-
WHERE, E.G., IN THE TRUSTED FACILITY MANUAL.

IN ORDER TO BE EVALUATED, A NETWORK MUST POSSESS A
COHERENT NETWORK SECURITY ARCHITECTURE AND DESIGN. (INTER-
CONNECTION OF COMPONENTS THAT DO NOT ADHERE TO SUCH A SINGLE
COHERENT NETWORK SECURITY ARCHITECTURE IS ADDRESSED IN THE
INTERCONNECTION OF ACCREDITED AIS, APPENDIX C.) THE NETWORK
SECURITY ARCHITECTURE MUST ADDRESS THE SECURITY-RELEVANT
POLICIES, OBJECTIVES, AND PROTOCOLS. THE NETWORK SECURITY
DESIGN SPECIFIES THE INTERFACES AND SERVICES THAT MUST BE
INCORPORATED INTO THE NETWORK SO THAT IT CAN BE EVALUATED AS
A TRUSTED ENTITY. THERE MAY BE MULTIPLE DESIGNS THAT CON-
FORM TO THE SAME ARCHITECTURE BUT ARE MORE OR LESS INCOMPA-
TIBLE AND NON-INTEROPERABLE (EXCEPT THROUGH THE INTERCONNEC-
TION RULES). SECURITY RELATED MECHANISMS REQUIRING COOPERA-
TION AMONG COMPONENTS ARE SPECIFIED IN THE DESIGN IN TERMS
OF THEIR VISIBLE INTERFACES; MECHANISMS HAVING NO VISIBLE
INTERFACES ARE NOT SPECIFIED IN THIS DOCUMENT BUT ARE LEFT
AS IMPLEMENTATION DECISIONS.

THE NETWORK SECURITY ARCHITECTURE AND DESIGN MUST BE
AVAILABLE FROM THE NETWORK SPONSOR BEFORE EVALUATION OF THE
NETWORK, OR ANY COMPONENT, CAN BE UNDERTAKEN. THE NETWORK
SECURITY ARCHITECTURE AND DESIGN MUST BE SUFFICIENTLY COM-
PLETE, UNAMBIGUOUS, AND FREE FROM OBVIOUS FLAWS TO PERMIT
THE CONSTRUCTION OR ASSEMBLY OF A TRUSTED NETWORK BASED ON
THE STRUCTURE IT SPECIFIES.

WHEN A COMPONENT IS BEING DESIGNED OR PRESENTED FOR
EVALUATION, OR WHEN A NETWORK ASSEMBLED FROM COMPONENTS IS
ASSEMBLED OR PRESENTED FOR EVALUATION, THERE MUST BE A
PRIORI EVIDENCE THAT THE NETWORK SECURITY ARCHITECTURE AND
DESIGN ARE SATISFIED. THAT IS, THE COMPONENTS CAN BE ASSEM-
BLED INTO A NETWORK THAT CONFORMS IN EVERY WAY WITH THE NET-
WORK SECURITY ARCHITECTURE AND DESIGN TO PRODUCE A PHYSICAL
REALIZATION THAT IS TRUSTED TO THE EXTENT THAT ITS EVALUA-
TION INDICATES.

IN ORDER FOR A TRUSTED NETWORK TO BE CONSTRUCTED FROM
COMPONENTS THAT CAN BE BUILT INDEPENDENTLY, THE NETWORK
SECURITY ARCHITECTURE AND DESIGN MUST COMPLETELY AND UNAMBI-
GUOUSLY DEFINE THE SECURITY FUNCTIONALITY OF COMPONENTS AS
WELL AS THE INTERFACES BETWEEN OR AMONG COMPONENTS. THE
NETWORK SECURITY ARCHITECTURE AND DESIGN MUST BE EVALUATED
TO DETERMINE THAT A NETWORK CONSTRUCTED TO ITS
SPECIFICATIONS WILL IN FACT BE TRUSTED, THAT IS, IT WILL BE
EVALUATABLE UNDER THESE INTERPRETATIONS.




2.2 CLASS (C2): CONTROLLED ACCESS PROTECTION
_ _ _____ __ __________ ______ __________


NETWORK SYSTEMS IN THIS CLASS ENFORCE A MORE
FINELY GRAINED DISCRETIONARY ACCESS CONTROL THAN
(C1) NETWORK SYSTEMS, MAKING USERS INDIVIDUALLY
ACCOUNTABLE FOR THEIR ACTIONS THROUGH LOGIN PRO-
CEDURES, AUDITING OF SECURITY-RELEVANT EVENTS, AND
RESOURCE ISOLATION. THE FOLLOWING ARE MINIMAL
REQUIREMENTS FOR SYSTEMS ASSIGNED A CLASS (C2)
RATING.


2.2.1 Security Policy
_ _ _ ________ ______

+ Statement from DoD 5200.28-STD

Implied from the Introduction to the TCSEC.


+ Interpretation

The network sponsor shall describe the overall network
security policy enforced by the NTCB. At a minimum, this
policy shall include the discretionary requirements applica-
ble to this class. The policy may require data secrecy, or
data integrity, or both. The policy shall include a discre-
tionary policy for protecting the information being pro-
cessed based on the authorizations of INDIVIDUALS, users, or
groups of users. This access control policy statement shall
describe the requirements on the network to prevent or
detect "reading or destroying" sensitive information by
unauthorized users or errors. Unauthorized users include
both those that are not authorized to use the network at all
(e.g., a user attempting to use a passive or active wire
tap) or a legitimate user of the network who is not author-
ized to access a specific piece of information being pro-
tected.

Note that "users" does not include "operators," "system
programmers," "technical control officers," "system security
officers," and other system support personnel. They are
distinct from users and are subject to the Trusted Facility
Manual and the System Architecture requirements. Such indi-
viduals may change the system parameters of the network
system, for example, by defining membership of a group.
These individuals may also have the separate role of users.


SECRECY POLICY: The network sponsor shall define the
form of the discretionary secrecy policy that is
enforced in the network to prevent unauthorized
users from reading the sensitive information
entrusted to the network.


DATA INTEGRITY POLICY: The network sponsor shall
define the discretionary integrity policy to prevent
unauthorized users from modifying, viz., writing,
sensitive information. The definition of data
integrity presented by the network sponsor refers to
the requirement that the information has not been
subjected to unauthorized modification in the net-
work.

+ Rationale

The word "sponsor" is used in place of alternatives
(such as "vendor," "architect," "manufacturer," and
"developer") because the alternatives indicate people who
may not be available, involved, or relevant at the time that
a network system is proposed for evaluation.

A trusted network is able to control both the reading
and writing of shared sensitive information. Control of
writing is used to protect against destruction of informa-
tion. A network normally is expected to have policy require-
ments to protect both the secrecy and integrity of the
information entrusted to it. In a network the integrity is
frequently as important or more important than the secrecy
requirements. Therefore the secrecy and/or integrity policy
to be enforced by the network must be stated for each net-
work regardless of its evaluation class. The assurance that
the policy is faithfully enforced is reflected in the
evaluation class of the network.

This control over modification is typically used to
protect information so that it may be relied upon and to
control the potential harm that would result if the informa-
tion were corrupted. The overall network policy require-
ments for integrity includes the protection for data both
while being processed in a component and while being
transmitted in the network. The access control policy
enforced by the NTCB relates to the access of subjects to
objects within each component. Communications integrity
addressed within Part II relates to information while being
transmitted.

2.2.1.1 Discretionary Access Control

+ Statement from DoD 5200.28-STD

The TCB shall define and control access between named users
and named objects (e.g., files and programs) in the ADP sys-
tem. The enforcement mechanism (e.g., self/group/public
controls, access control lists) shall allow users to specify
and control sharing of those objects by named individuals or
defined groups OF INDIVIDUALS, or both, AND SHALL PROVIDE
CONTROLS TO LIMIT PROPAGATION OF ACCESS RIGHTS. THE DISCRE-
TIONARY ACCESS CONTROL MECHANISM SHALL, EITHER BY EXPLICIT
USER ACTION OR BY DEFAULT, PROVIDE THAT OBJECTS ARE PRO-
TECTED FROM UNAUTHORIZED ACCESS. THESE ACCESS CONTROLS
SHALL BE CAPABLE OF INCLUDING OR EXCLUDING ACCESS TO THE
GRANULARITY OF A SINGLE USER. ACCESS PERMISSION TO AN
OBJECT BY USERS NOT ALREADY POSSESSING ACCESS PERMISSION
SHALL ONLY BE ASSIGNED BY AUTHORIZED USERS.

+ Interpretation

The discretionary access control (DAC) mechanism(s) may
be distributed over the partitioned NTCB in various ways.
Some part, all, or none of the DAC may be implemented in a
given component of the network system. In particular, com-
ponents that support only internal subjects (i.e., that have
no subjects acting as direct surrogates for users), such as
a public network packet switch, might not implement the DAC
mechanism(s) directly (e.g., they are unlikely to contain
access control lists).

Identification of users by groups may be achieved in
various ways in the networking environment. For example,
the network identifiers (e.g., internet addresses) for vari-
ous components (e.g., hosts, gateways) can be used as iden-
tifiers of groups of individual users (e.g., "all users at
Host A," "all users of network Q") SO LONG AS THE INDIVIDU-
ALS INVOLVED IN THE GROUP ARE IMPLIED BY THE GROUP IDENTIF-
IER. FOR EXAMPLE, HOST A MIGHT EMPLOY A PARTICULAR GROUP-ID,
FOR WHICH IT MAINTAINS A LIST OF EXPLICIT USERS IN THAT
GROUP, IN ITS NETWORK EXCHANGE WITH HOST B, WHICH ACCEPTS
THE GROUP-ID UNDER THE CONDITIONS OF THIS INTERPRETATION.

For networks, individual hosts will impose need-to-know
controls over their users ON THE BASIS OF NAMED INDIVIDUALS
- much like (in fact, probably the same) controls used when
there is no network connection.

When group identifiers are acceptable for access con-
trol, the identifier of some other host may be employed, to
eliminate the maintenance that would be required if indivi-
dual identification of remote users was employed. IN CLASS
C2 AND HIGHER, HOWEVER, IT MUST BE POSSIBLE FROM THAT AUDIT
RECORD TO IDENTIFY (IMMEDIATELY OR AT SOME LATER TIME)
EXACTLY THE INDIVIDUALS REPRESENTED BY A GROUP IDENTIFIER AT
THE TIME OF THE USE OF THAT IDENTIFIER. THERE IS ALLOWED TO
BE AN UNCERTAINTY BECAUSE OF ELAPSED TIME BETWEEN CHANGES IN
THE GROUP MEMBERSHIP AND THE ENFORCEMENT IN THE ACCESS CON-
TROL MECHANISMS.

The DAC mechanism of a NTCB partition may be imple-
mented at the interface of the reference monitor or may be
distributed in subjects that are part of the NTCB in the
same or different component. The reference monitor manages
all the physical resources of the system and from them
creates the abstraction of subjects and objects that it con-
trols. Some of these subjects and objects may be used to
implement a part of the NTCB. WHEN THE DAC MECHANISM IS
DISTRIBUTED IN SUCH NTCB SUBJECTS (I.E., WHEN OUTSIDE THE
REFERENCE MONITOR), THE ASSURANCE REQUIREMENTS (SEE THE
ASSURANCE SECTION) FOR THE DESIGN AND IMPLEMENTATION OF THE
DAC SHALL BE THOSE OF CLASS C2 FOR ALL NETWORKS OF CLASS C2
OR ABOVE.

When integrity is included as part of the network dis-
cretionary security policy, the above interpretations shall
be specifically applied to the controls over modification,
viz, the write mode of access, within each component based
on identified users or groups of users.

+ Rationale

In this class, THE SUPPORTING ELEMENTS OF THE OVERALL
DAC MECHANISM ARE REQUIRED TO ISOLATE INFORMATION (OBJECTS)
THAT SUPPORTS DAC SO THAT IT IS SUBJECT TO AUDITING REQUIRE-
MENTS (SEE THE SYSTEM ARCHITECTURE SECTION). THE USE OF
NETWORK IDENTIFIERS TO IDENTIFY GROUPS OF INDIVIDUAL USERS
COULD BE IMPLEMENTED, FOR EXAMPLE, AS AN X.25 COMMUNITY OF
INTEREST IN THE NETWORK PROTOCOL LAYER (LAYER 3). IN ALL
OTHER RESPECTS, the supporting elements of the overall DAC
mechanism are treated exactly as untrusted subjects are
treated with respect to DAC in an ADP system, with the same
result as noted in the interpretation.

A typical situation for DAC is that a surrogate process
for a remote user will be created in some host for access to
objects under the control of the NTCB partition within that
host. The interpretation requires that a user identifier be
assigned and maintained for each such process by the NTCB,
so that access by a surrogate process is subject to essen-
tially the same discretionary controls as access by a pro-
cess acting on behalf of a local user would be. However,
within this interpretation a range of possible interpreta-
tions of the assigned user identification is permitted.

The most obvious situation would exist if a global
database of network users were to be made permanently avail-
able on demand to every host, (i.e., a name server existed)
so that all user identifications were globally meaningful.

It is also acceptable, however, for some NTCB parti-
tions to maintain a database of locally-registered users for
its own use. In such a case, one could choose to inhibit
the creation of surrogate processes for locally unregistered
users, or (if permitted by the local policy) alternatively,
to permit the creation of surrogate processes with
preselected user and group identifiers which, in effect,
identify the process as executing on behalf of a member of a
group of users on a particular remote host. The intent of
the words concerning audit in the interpretation is to pro-
vide a minimally acceptable degree of auditability for cases
such as the last described. What is required is that there
be a capability, using the audit facilities provided by the
network NTCB partitions involved, to determine who was
logged in at the actual host of the group of remote users at
the time the surrogate processing occured.

Associating the proper user id with a surrogate process
is the job of identification and authentication. This means
that DAC is applied locally, with respect to the user id of
the surrogate process. The transmission of the data back
across the network to the user's host, and the creation of a
copy of the data there, is not the business of DAC.

Components that support only internal subjects impact
the implementation of the DAC by providing services by which
information (e.g., a user-id) is made available to a com-
ponent that makes a DAC decision. An example of the latter
would be the case that a user at Host A attempts to access a
file at Host B. The DAC decision might be (and usually
would be) made at Host B on the basis of a user-id transmit-
ted from Host A to Host B.

Unique user identification may be achieved by a variety
of mechanisms, including (a) a requirement for unique iden-
tification and authentication on the host where access takes
place; (b) recognition of fully qualified network
addresses authenticated by another host and forwarded to the
host where access takes place; or (c) administrative support
of a network-wide unique personnel identifier that could be
authenticated and forwarded by another host as in (b) above,
or could be authenticated and forwarded by a dedicated net-
work identification and authentication server. The proto-
cols which implement (b) or (c) are subject to the System
Architecture requirements.

Network support for DAC might be handled in other ways
than that described as "typical" above. In particular, some
form of centralized access control is often proposed. An
access control center may make all decisions for DAC, or it
may share the burden with the hosts by controlling host-to-
host connections, and leaving the hosts to decide on access
to their objects by users at a limited set of remote hosts.
In this case the access control center provides the linkage
between the connection oriented abstraction (as discussed in
the Introduction) and the overall network security policy
for DAC. In all cases the enforcement of the decision must
be provided by the host where the object resides.

2.2.1.2 Object Reuse

+ Statement from DoD 5200.28-STD

ALL AUTHORIZATIONS TO THE INFORMATION CONTAINED WITHIN A
STORAGE OBJECT SHALL BE REVOKED PRIOR TO INITIAL ASSIGNMENT,
ALLOCATION OR REALLOCATION TO A SUBJECT FROM THE TCB'S POOL
OF UNUSED STORAGE OBJECTS. NO INFORMATION, INCLUDING
ENCRYPTED REPRESENTATIONS OF INFORMATION, PRODUCED BY A
PRIOR SUBJECT'S ACTIONS IS TO BE AVAILABLE TO ANY SUBJECT
THAT OBTAINS ACCESS TO AN OBJECT THAT HAS BEEN RELEASED BACK
TO THE SYSTEM.

+ Interpretation

THE NTCB SHALL ENSURE THAT ANY STORAGE OBJECTS THAT IT
CONTROLS (E.G., MESSAGE BUFFERS UNDER THE CONTROL OF A NTCB
PARTITION IN A COMPONENT) CONTAIN NO INFORMATION FOR WHICH A
SUBJECT IN THAT COMPONENT IS NOT AUTHORIZED BEFORE GRANTING
ACCESS. THIS REQUIREMENT MUST BE ENFORCED BY EACH OF THE
NTCB PARTITIONS.

+ Rationale

IN A NETWORK SYSTEM, STORAGE OBJECTS OF INTEREST ARE
THINGS THAT THE NTCB DIRECTLY CONTROLS, SUCH AS MESSAGE
BUFFERS IN COMPONENTS. EACH COMPONENT OF THE NETWORK SYSTEM
MUST ENFORCE THE OBJECT REUSE REQUIREMENT WITH RESPECT TO
THE STORAGE OBJECTS OF INTEREST AS DETERMINED BY THE NETWORK
SECURITY POLICY. FOR EXAMPLE, THE DAC REQUIREMENT IN THIS
DIVISION LEADS TO THE REQUIREMENT HERE THAT MESSAGE BUFFERS
BE UNDER THE CONTROL OF THE NTCB PARTITION. A BUFFER
ASSIGNED TO AN INTERNAL SUBJECT MAY BE REUSED AT THE DISCRE-
TION OF THAT SUBJECT WHICH IS RESPONSIBLE FOR PRESERVING THE
INTEGRITY OF MESSAGE STREAMS. SUCH CONTROLLED OBJECTS MAY
BE IMPLEMENTED IN PHYSICAL RESOURCES, SUCH AS BUFFERS, DISK
SECTORS, TAPE SPACE, AND MAIN MEMORY, IN COMPONENTS SUCH AS
NETWORK SWITCHES.


2.2.2 Accountability
_ _ _ ______________


2.2.2.1 Identification and Authentication

+ Statement from DoD 5200.28-STD

The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB
is expected to mediate. Furthermore, the TCB shall use a
protected mechanism (e.g., passwords) to authenticate the
user's identity. The TCB shall protect authentication data
so that it cannot be accessed by any unauthorized user. THE
TCB SHALL BE ABLE TO ENFORCE INDIVIDUAL ACCOUNTABILITY BY
PROVIDING THE CAPABILITY TO UNIQUELY IDENTIFY EACH INDIVI-
DUAL ADP SYSTEM USER. THE TCB SHALL ALSO PROVIDE THE CAPA-
BILITY OF ASSOCIATING THIS IDENTITY WITH ALL AUDITABLE
ACTIONS TAKEN BY THAT INDIVIDUAL.

+ Interpretation

The requirement for identification and authentication
of users is the same for a network system as for an ADP sys-
tem. The identification and authentication may be done by
the component to which the user is directly connected or
some other component, such as an identification and authen-
tication server. Available techniques, such as those
described in the Password Guideline=, are generally also
applicable in the network context. However, in cases where
the NTCB is expected to mediate actions of a host (or other
network component) that is acting on behalf of a user or
group of users, the NTCB may employ identification and
authentication of the host (or other component) in lieu of
identification and authentication of an individual user, SO
LONG AS THE COMPONENT IDENTIFIER IMPLIES A LIST OF SPECIFIC
USERS UNIQUELY ASSOCIATED WITH THE IDENTIFIER AT THE TIME OF
ITS USE FOR AUTHENTICATION. THIS REQUIREMENT DOES NOT APPLY
TO INTERNAL SUBJECTS.

Authentication information, including the identity of a
user (once authenticated) may be passed from one component
to another without reauthentication, so long as the NTCB
protects (e.g., by encryption) the information from unau-
thorized disclosure and modification. This protection shall
provide at least a similar level of assurance (or strength
of mechanism) as pertains to the protection of the authenti-
cation mechanism and authentication data.

+ Rationale

The need for accountability is not changed in the con-
text of a network system. The fact that the NTCB is parti-
tioned over a set of components neither reduces the need nor
imposes new requirements. That is, individual accountabil-
ity is still the objective. ALSO, in the context of a net-
work system at the (C2) LEVEL OR HIGHER "INDIVIDUAL ACCOUN-
TABILITY" CAN BE SATISFIED BY IDENTIFICATION OF A HOST (OR
OTHER COMPONENT) SO LONG AS THE REQUIREMENT FOR TRACEABILITY
TO INDIVIDUAL USERS OR A SET OF SPECIFIC INDIVIDUAL USERS
WITH ACTIVE SUBJECTS IS SATISFIED. THERE IS ALLOWED TO BE AN
UNCERTAINTY IN TRACEABILITY BECAUSE OF ELAPSED TIME BETWEEN
CHANGES IN THE GROUP MEMBERSHIP AND THE ENFORCEMENT IN THE
ACCESS CONTROL MECHANISMS. In addition, there is no need in
a distributed processing system like a network to reauthen-
ticate a user at each point in the network where a projec-
tion of a user (via the subject operating on behalf of the
user) into another remote subject takes place.
_________________________
= Department of Defense Password Management Guide-
__________ __ _______ ________ __________ _____
line, CSC-STD-002-85
____

The passing of identifiers and/or authentication infor-
mation from one component to another is usually done in sup-
port to the implementation of the discretionary access con-
trol (DAC). This support relates directly to the DAC
regarding access by a user to a storage object in a dif-
ferent NTCB partition than the one where the user was
authenticated. Employing a forwarded identification implies
additional reliance on the source and components along the
path.


2.2.2.2 Audit

+ Statement from DoD 5200.28-STD

THE TCB SHALL BE ABLE TO CREATE, MAINTAIN, AND PROTECT FROM
MODIFICATION OR UNAUTHORIZED ACCESS OR DESTRUCTION AN AUDIT
TRAIL OF ACCESSES TO THE OBJECTS IT PROTECTS. THE AUDIT
DATA SHALL BE PROTECTED BY THE TCB SO THAT READ ACCESS TO IT
IS LIMITED TO THOSE WHO ARE AUTHORIZED FOR AUDIT DATA. THE
TCB SHALL BE ABLE TO RECORD THE FOLLOWING TYPES OF EVENTS:
USE OF IDENTIFICATION AND AUTHENTICATION MECHANISMS, INTRO-
DUCTION OF OBJECTS INTO A USER'S ADDRESS SPACE (E.G., FILE
OPEN, PROGRAM INITIATION), DELETION OF OBJECTS, ACTIONS
TAKEN BY COMPUTER OPERATORS AND SYSTEM ADMINISTRATORS AND/OR
SYSTEM SECURITY OFFICERS, AND OTHER SECURITY RELEVANT
EVENTS. FOR EACH RECORDED EVENT, THE AUDIT RECORD SHALL
IDENTIFY: DATE AND TIME OF THE EVENT, USER, TYPE OF EVENT,
AND SUCCESS OR FAILURE OF THE EVENT. FOR
IDENTIFICATION/AUTHENTICATION EVENTS THE ORIGIN OF REQUEST
(E.G., TERMINAL ID) SHALL BE INCLUDED IN THE AUDIT RECORD.
FOR EVENTS THAT INTRODUCE AN OBJECT INTO A USER'S ADDRESS
SPACE AND FOR OBJECT DELETION EVENTS THE AUDIT RECORD SHALL
INCLUDE THE NAME OF THE OBJECT. THE ADP SYSTEM ADMINISTRA-
TOR SHALL BE ABLE TO SELECTIVELY AUDIT THE ACTIONS OF ANY
ONE OR MORE USERS BASED ON INDIVIDUAL IDENTITY.

+ Interpretation

THIS CRITERION APPLIES AS STATED. THE SPONSOR MUST
SELECT WHICH EVENTS ARE AUDITABLE. IF ANY SUCH EVENTS ARE
NOT DISTINGUISHABLE BY THE NTCB ALONE (FOR EXAMPLE THOSE
IDENTIFIED IN PART II), THE AUDIT MECHANISM SHALL PROVIDE AN
INTERFACE, WHICH AN AUTHORIZED SUBJECT CAN INVOKE WITH
PARAMETERS SUFFICIENT TO PRODUCE AN AUDIT RECORD. THESE
AUDIT RECORDS SHALL BE DISTINGUISHABLE FROM THOSE PROVIDED
BY THE NTCB. IN THE CONTEXT OF A NETWORK SYSTEM, "OTHER
SECURITY RELEVANT EVENTS" (DEPENDING ON NETWORK SYSTEM
ARCHITECTURE AND NETWORK SECURITY POLICY) MIGHT BE AS FOL-
LOWS:

1. IDENTIFICATION OF EACH ACCESS EVENT (E.G., ESTAB-
LISHING A CONNECTION OR A CONNECTIONLESS ASSOCIATION
BETWEEN PROCESSES IN TWO HOSTS OF THE NETWORK) AND
ITS PRINCIPAL PARAMETERS (E.G., HOST IDENTIFIERS OF
THE TWO HOSTS INVOLVED IN THE ACCESS EVENT AND USER
IDENTIFIER OR HOST IDENTIFIER OF THE USER OR HOST
THAT IS REQUESTING THE ACCESS EVENT)

2. IDENTIFICATION OF THE STARTING AND ENDING TIMES OF
EACH ACCESS EVENT USING LOCAL TIME OR GLOBAL SYN-
CHRONIZED TIME

3. IDENTIFICATION OF SECURITY-RELEVANT EXCEPTIONAL CON-
DITIONS (E.G., POTENTIAL VIOLATION OF DATA
INTEGRITY, SUCH AS MISROUTED DATAGRAMS) DETECTED
DURING THE TRANSACTIONS BETWEEN TWO HOSTS

4. UTILIZATION OF CRYPTOGRAPHIC VARIABLES

5. CHANGING THE CONFIGURATION OF THE NETWORK (E.G., A
COMPONENT LEAVING THE NETWORK AND REJOINING)

IN ADDITION, IDENTIFICATION INFORMATION SHOULD BE
INCLUDED IN APPROPRIATE AUDIT TRAIL RECORDS, AS NECESSARY,
TO ALLOW ASSOCIATION OF ALL RELATED (E.G., INVOLVING THE
SAME NETWORK EVENT) AUDIT TRAIL RECORDS (E.G., AT DIFFERENT
HOSTS) WITH EACH OTHER. FURTHERMORE, A COMPONENT OF THE
NETWORK SYSTEM MAY PROVIDE THE REQUIRED AUDIT CAPABILITY
(E.G., STORAGE, RETRIEVAL, REDUCTION, ANALYSIS) FOR OTHER
COMPONENTS THAT DO NOT INTERNALLY STORE AUDIT DATA BUT
TRANSMIT THE AUDIT DATA TO SOME DESIGNATED COLLECTION COM-
PONENT. PROVISIONS SHALL BE MADE TO CONTROL THE LOSS OF
AUDIT DATA DUE TO UNAVAILABILITY OF RESOURCES.

IN THE CONTEXT OF A NETWORK SYSTEM, THE "USER'S ADDRESS
SPACE" IS EXTENDED, FOR OBJECT INTRODUCTION AND DELETION
EVENTS, TO INCLUDE ADDRESS SPACES BEING EMPLOYED ON BEHALF
OF A REMOTE USER (OR HOST). HOWEVER, THE FOCUS REMAINS ON
USERS IN CONTRAST TO INTERNAL SUBJECTS AS DISCUSSED IN THE
DAC CRITERION. IN ADDITION, AUDIT INFORMATION MUST BE
STORED IN MACHINE-READABLE FORM.

+ Rationale

FOR REMOTE USERS, THE NETWORK IDENTIFIERS (E.G., INTER-
NET ADDRESS) CAN BE USED AS IDENTIFIERS OF GROUPS OF INDIVI-
DUAL USERS (E.G., "ALL USERS AT HOST A") TO ELIMINATE THE
MAINTENANCE THAT WOULD BE REQUIRED IF INDIVIDUAL IDENTIFICA-
TION OF REMOTE USERS WAS EMPLOYED. IN THIS CLASS (C2), HOW-
EVER, IT MUST BE POSSIBLE TO IDENTIFY (IMMEDIATELY OR AT
SOME LATER TIME) THE INDIVIDUALS REPRESENTED BY A GROUP
IDENTIFIER. IN ALL OTHER RESPECTS, THE INTERPRETATION IS A
STRAIGHTFORWARD EXTENSION OF THE CRITERION INTO THE CONTEXT
OF A NETWORK SYSTEM.


2.2.3 Assurance
_ _ _ _________


2.2.3.1 Operational Assurance


2.2.3.1.1 System Architecture

+ Statement from DoD 5200.28-STD

The TCB shall maintain a domain for its own execution that
protects it from external interference or tampering (e.g.,
by modification of its code or data structures). Resources
controlled by the TCB may be a defined subset of the sub-
jects and objects in the ADP system. THE TCB SHALL ISOLATE
THE RESOURCES TO BE PROTECTED SO THAT THEY ARE SUBJECT TO
THE ACCESS CONTROL AND AUDITING REQUIREMENTS.

+ Interpretation

The system architecture criterion must be met individu-
ally by all NTCB partitions. Implementation of the require-
ment that the NTCB maintain a domain for its own execution
is achieved by having each NTCB partition maintain a domain
for its own execution.

The subset of network resources over which the NTCB has
control are the union of the sets of resources over which
the NTCB partitions have control. Code and data structures
belonging to the NTCB, transferred among NTCB subjects
(i.e., subjects outside the reference monitor but inside the
NTCB) belonging to different NTCB partitions, must be pro-
tected against external interference or tampering. For
example, a cryptographic checksum or physical means may be
employed to protect user authentication data exchanged
between NTCB partitions.

EACH NTCB PARTITION PROVIDES ISOLATION OF RESOURCES
(WITHIN ITS COMPONENT) TO BE PROTECTED IN ACCORD WITH THE
NETWORK SYSTEM ARCHITECTURE AND SECURITY POLICY.

+ Rationale


The requirement for the protection of communications
between NTCB partitions is specifically directed to subjects
that are part of the NTCB partitions. Any requirements for
such protection for the subjects that are outside the NTCB
partitions are addressed in response to the integrity
requirements of the security policy.

ISOLATION OF THE RESOURCES TO BE PROTECTED PROVIDES
ADDITIONAL PROTECTION, COMPARED TO CLASS (C1), THAT MECHAN-
ISMS THAT DEPEND ON THE RESOURCE (E.G., DAC AND USER IDEN-
TIFICATION) WILL OPERATE CORRECTLY.

2.2.3.1.2 System Integrity

+ Statement from DoD 5200.28-STD

Hardware and/or software features shall be provided that can
be used to periodically validate the correct operation of
the on-site hardware and firmware elements of the TCB.

+ Interpretation

Implementation of the requirement is partly achieved by
having hardware and/or software features that can be used to
periodically validate the correct operation of the hardware
and firmware elements of each component's NTCB partition.
Features shall also be provided to validate the identity and
correct operation of a component prior to its incorporation
in the network system and throughout system operation. For
example, a protocol could be designed that enables the com-
ponents of the partitioned NTCB to exchange messages period-
ically and validate each other's correct response. The pro-
tocol shall be able to determine the remote entity's ability
to respond. NTCB partitions shall provide the capability to
report to network administrative personnel the failures
detected in other NTCB partitions.

Intercomponent protocols implemented within a NTCB
shall be designed in such a way as to provide correct opera-
tion in the case of failures of network communications or
individual components. The allocation of discretionary
access control policy in a network may require communication
between trusted subjects that are part of the NTCB parti-
tions in different components. This communication is nor-
mally implemented with a protocol between the subjects as
peer entities. Incorrect access within a component shall
not result from failure of an NTCB partition to communicate
with other components.

+ Rationale

The first paragraph of the interpretation is a
straightforward extension of the requirement into the con-
text of a network system and partitioned NTCB as defined for
these network criteria.

NTCB protocols should be robust enough so that they
permit the system to operate correctly in the case of local-
ized failure. The purpose of this protection is to preserve
the integrity of the NTCB itself. It is not unusual for one
or more components in a network to be inoperative at any
time, so it is important to minimize the effects of such
failures on the rest of the network. Additional integrity
and denial of service issues are addressed in Part II.

2.2.3.2 Life-Cycle