Trusted Network Interpretation
NCSC-TG-005
Library No. S228,526
Version 1
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 Assurance
2.2.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. TESTING SHALL
ALSO INCLUDE A SEARCH FOR OBVIOUS FLAWS THAT WOULD ALLOW
VIOLATION OF RESOURCE ISOLATION, OR THAT WOULD PERMIT UNAU-
THORIZED ACCESS TO THE AUDIT OR AUTHENTICATION DATA. (See
the Security Testing Guidelines.)
+ Interpretation
Testing of a component will require a testbed that
exercises the interfaces and protocols of the COMPONENT
INCLUDING TESTS UNDER EXCEPTIONAL CONDITIONS. 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 partition that
implement the given mechanism. This integrated testing is
additional to any individual component tests involved in the
evaluation of the network system. The sponsor should iden-
tify 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 configura-
tions. A change in configuration within the allowable set
of configurations does not require retesting.
+ 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.2.4 Documentation
_ _ _ _____________
2.2.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.2.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. THE PROCEDURES
FOR EXAMINING AND MAINTAINING THE AUDIT FILES AS WELL AS THE
DETAILED AUDIT RECORD STRUCTURE FOR EACH TYPE OF AUDIT EVENT
SHALL BE GIVEN.
+ 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.2.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.2.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 specifica-
tions will in fact be trusted, that is, it will be evaluat-
able under these interpretations.
3.0 DIVISION B: MANDATORY PROTECTION
The notion of an NTCB that preserves the integrity of sensi-
tivity labels and uses them to enforce a set of mandatory
access control rules is a major requirement in this divi-
sion. Network systems in this division must carry the sen-
sitivity labels with major data structures in the system.
The network system sponsor also provides the security policy
model on which the NTCB is based and furnishes a specifica-
tion of the NTCB. Evidence must be provided to demonstrate
that the reference monitor concept has been implemented.
3.1 CLASS (B1): LABELED SECURITY PROTECTION
_ _ _____ __ _______ ________ __________
CLASS (B1) NETWORK SYSTEMS REQUIRE ALL THE
FEATURES REQUIRED FOR CLASS (C2). IN ADDITION, AN
INFORMAL STATEMENT OF THE SECURITY POLICY MODEL,
DATA LABELING, AND MANDATORY ACCESS CONTROL OVER
SUBJECTS AND STORAGE OBJECTS MUST BE PRESENT. THE
CAPABILITY MUST EXIST FOR ACCURATELY LABELING
EXPORTED INFORMATION. ANY FLAWS IDENTIFIED BY
TESTING MUST BE REMOVED. THE FOLLOWING ARE
MINIMAL REQUIREMENTS FOR NETWORK SYSTEMS ASSIGNED
A CLASS (B1) RATING:
3.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 AND MANDATORY
requirements applicable to this class. The policy may
require data secrecy, or data integrity, or both. THE POL-
ICY IS AN ACCESS CONTROL POLICY HAVING TWO PRIMARY COM-
PONENTS: MANDATORY AND DISCRETIONARY. The policy shall
include a discretionary policy for protecting the informa-
tion being processed based on the authorizations of indivi-
duals, users, or groups of users. This access control pol-
icy statement shall describe the requirements on the network
to prevent or detect "reading or destroying" sensitive
information by unauthorized users or errors. THE MANDATORY
POLICY MUST DEFINE THE SET OF DISTINCT SENSITIVITY LEVELS
THAT IT SUPPORTS. FOR THE CLASS B1 OR ABOVE THE MANDATORY
POLICY SHALL BE BASED ON THE LABELS ASSOCIATED WITH THE
INFORMATION THAT REFLECTS ITS SENSITIVITY WITH RESPECT TO
SECRECY AND/OR INTEGRITY, WHERE APPLICABLE, AND LABELS ASSO-
CIATED WITH USERS TO REFLECT THEIR AUTHORIZATION TO ACCESS
SUCH INFORMATION. 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 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 AND MANDATORY secrecy
policy that is enforced in the network to prevent
unauthorized users from reading the sensitive infor-
mation entrusted to the network.
DATA INTEGRITY POLICY: The network sponsor shall
define the discretionary AND MANDATORY integrity
policy to prevent unauthorized users from modifying,
viz., writing, sensitive information. The defini-
tion of data integrity presented by the network
sponsor refers to the requirement that the informa-
tion has not been subjected to unauthorized modifi-
cation in the network. THE MANDATORY INTEGRITY POL-
ICY ENFORCED BY THE NTCB CANNOT, IN GENERAL, PREVENT
MODIFICATION WHILE INFORMATION IS BEING TRANSMITTED
BETWEEN COMPONENTS. HOWEVER, AN INTEGRITY SENSI-
TIVITY LABEL MAY REFLECT THE CONFIDENCE THAT THE
INFORMATION HAS NOT BEEN SUBJECTED TO TRANSMISSION
ERRORS BECAUSE OF THE PROTECTION AFFORDED DURING
TRANSMISSION. THIS REQUIREMENT IS DISTINCT FROM THE
REQUIREMENT FOR LABEL INTEGRITY.
+ 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.
THE MANDATORY INTEGRITY POLICY (AT CLASS B1 AND ABOVE)
IN SOME ARCHITECTURES MAY BE USEFUL IN SUPPORTING THE LINK-
AGE BETWEEN THE CONNECTION ORIENTED ABSTRACTION INTRODUCED
IN THE INTRODUCTION AND THE INDIVIDUAL COMPONENTS OF THE
NETWORK. FOR EXAMPLE, IN A KEY DISTRIBUTION CENTER FOR
END-TO-END ENCRYPTION, A DISTINCT INTEGRITY CATEGORY MAY BE
ASSIGNED TO ISOLATE THE KEY GENERATION CODE AND DATA FROM
POSSIBLE MODIFICATION BY OTHER SUPPORTING PROCESSES IN THE
SAME COMPONENT, SUCH AS OPERATOR INTERFACES AND AUDIT.
THE MANDATORY INTEGRITY POLICY FOR SOME ARCHITECTURE
MAY DEFINE AN INTEGRITY SENSITIVITY LABEL THAT REFLECTS THE
SPECIFIC REQUIREMENTS FOR ENSURING THAT INFORMATION HAS NOT
BEEN SUBJECT TO RANDOM ERRORS IN EXCESS OF A STATED LIMIT
NOR TO UNAUTHORIZED MESSAGE STREAM MODIFICATION (MSM) -.
THE SPECIFIC METRIC ASSOCIATED WITH AN INTEGRITY SENSITIVITY
LABEL WILL GENERALLY REFLECT THE INTENDED APPLICATIONS OF
THE NETWORK.
3.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, 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.
_________________________
- See Voydock, Victor L. and Stephen T. Kent, "Secu-
rity Mechanisms in High-Level Network Protocols," Com-
___
puting Surveys, Vol. 15, No. 2, June 1983, pp 135-171.
______ _______
+ 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.
THERE ARE TWO FORMS OF DISTRIBUTION FOR THE DAC MECHAN-
ISM: IMPLEMENTING PORTIONS OF THE DAC IN SEPARATE COM-
PONENTS, AND SUPPORTING THE DAC IN SUBJECTS CONTAINED WITHIN
THE NTCB PARTITION IN A COMPONENT. SINCE "THE ADP SYSTEM"
IS UNDERSTOOD TO BE "THE COMPUTER NETWORK" AS A WHOLE, EACH
NETWORK COMPONENT IS RESPONSIBLE FOR ENFORCING SECURITY IN
THE MECHANISMS ALLOCATED TO IT TO ENSURE SECURE IMPLEMENTA-
TION OF THE NETWORK SECURITY POLICY. FOR TRADITIONAL HOST
SYSTEMS IT IS FREQUENTLY EASY TO ALSO ENFORCE THE DAC ALONG
WITH THE MAC WITHIN THE REFERENCE MONITOR, PER SE, ALTHOUGH
A FEW APPROACHES, SUCH AS VIRTUAL MACHINE MONITORS, SUPPORT
DAC OUTSIDE THIS INTERFACE.
IN CONTRAST TO THE UNIVERSALLY RIGID STRUCTURE OF MAN-
DATORY POLICIES (SEE THE MANDATORY ACCESS CONTROL SECTION),
DAC POLICIES TEND TO BE VERY NETWORK AND SYSTEM SPECIFIC,
WITH FEATURES THAT REFLECT THE NATURAL USE OF THE SYSTEM.
FOR NETWORKS IT IS COMMON THAT INDIVIDUAL HOSTS WILL IMPOSE
CONTROLS OVER THEIR LOCAL USERS ON THE BASIS OF NAMED
INDIVIDUALS-MUCH LIKE THE CONTROLS USED WHEN THERE IS NO
NETWORK CONNECTION. HOWEVER, IT IS DIFFICULT TO MANAGE IN A
CENTRALIZED MANNER ALL THE INDIVIDUALS USING A LARGE NET-
WORK. THEREFORE, USERS ON OTHER HOSTS ARE COMMONLY GROUPED
TOGETHER SO THAT THE CONTROLS REQUIRED BY THE NETWORK DAC
POLICY ARE ACTUALLY BASED ON THE IDENTITY OF THE HOSTS OR
OTHER COMPONENTS. A GATEWAY IS AN EXAMPLE OF SUCH A COM-
PONENT.
THE ASSURANCE REQUIREMENTS ARE AT THE VERY HEART OF THE
CONCEPT OF A TRUSTED SYSTEM. IT IS THE ASSURANCE THAT
DETERMINES IF A SYSTEM OR NETWORK IS APPROPRIATE FOR A GIVEN
ENVIRONMENT, AS REFLECTED, FOR EXAMPLE, IN THE ENVIRONMENTS
GUIDELINE-. IN THE CASE OF MONOLITHIC SYSTEMS THAT HAVE DAC
INTEGRAL TO THE REFERENCE MONITOR, THE ASSURANCE REQUIRE-
MENTS FOR DAC ARE INSEPARABLE FROM THOSE OF THE REST OF THE
REFERENCE MONITOR. FOR NETWORKS THERE IS TYPICALLY A MUCH
CLEARER DISTINCTION DUE TO DISTRIBUTED DAC. THE RATIONALE
FOR MAKING THE DISTINCTION IN THIS NETWORK INTERPRETATION IS
THAT IF MAJOR TRUSTED NETWORK COMPONENTS CAN BE MADE SIGNI-
FICANTLY EASIER TO DESIGN AND IMPLEMENT WITHOUT REDUCING THE
ABILITY TO MEET SECURITY POLICY, THEN TRUSTED NETWORKS WILL
BE MORE EASILY AVAILABLE.
3.1.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.
_________________________
- Guidance for Applying the Department of Defense
________ ___ ________ ___ __________ __ _______
Trusted Computer System Evaluation Criteria in Specific
_______ ________ ______ __________ ________ __ ________
Environments, CSC-STD-003-85.
____________
+ 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.
3.1.1.3 Labels
+ Statement from DoD 5200.28-STD
SENSITIVITY LABELS ASSOCIATED WITH EACH SUBJECT AND STORAGE
OBJECT UNDER ITS CONTROL (E.G., PROCESS, FILE, SEGMENT, DEV-
ICE) SHALL BE MAINTAINED BY THE TCB. THESE LABELS SHALL BE
USED AS THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS.
IN ORDER TO IMPORT NON-LABELED DATA, THE TCB SHALL REQUEST
AND RECEIVE FROM AN AUTHORIZED USER THE SENSITIVITY LEVEL OF
THE DATA, AND ALL SUCH ACTIONS SHALL BE AUDITABLE BY THE
TCB.
+ Interpretation
NON-LABELED DATA IMPORTED UNDER THE CONTROL OF THE NTCB
PARTITION WILL BE ASSIGNED A LABEL CONSTRAINED BY THE
SINGLE-LEVEL DEVICE USED TO IMPORT IT. LABELS MAY INCLUDE
SECRECY AND INTEGRITY- COMPONENTS IN ACCORDANCE WITH THE
OVERALL NETWORK SECURITY POLICY DESCRIBED BY THE NETWORK
SPONSOR. WHENEVER THE TERM "LABEL" IS USED THROUGHOUT THIS
INTERPRETATION, IT IS UNDERSTOOD TO INCLUDE BOTH COMPONENTS
AS APPLICABLE. SIMILARLY, THE TERMS "SINGLE-LEVEL" AND
"MULTILEVEL" ARE UNDERSTOOD TO BE BASED ON BOTH THE SECRECY
AND INTEGRITY COMPONENTS OF THE POLICY. THE MANDATORY
INTEGRITY POLICY WILL TYPICALLY HAVE REQUIREMENTS, SUCH AS
THE PROBABILITY OF UNDETECTED MESSAGE STREAM MODIFICATION,
THAT WILL BE REFLECTED IN THE LABEL FOR THE DATA SO PRO-
TECTED. FOR EXAMPLE, WHEN DATA IS IMPORTED ITS INTEGRITY
LABEL MAY BE ASSIGNED BASED ON MECHANISMS, SUCH AS CRYPTOG-
RAPHY, USED TO PROVIDE THE ASSURANCE REQUIRED BY THE POLICY.
THE NTCB SHALL ASSURE THAT SUCH MECHANISM ARE PROTECTED FROM
TAMPERING AND ARE ALWAYS INVOKED WHEN THEY ARE THE BASIS FOR
_________________________
- See, for example, Biba, K.J., "Integrity Considera-
tion for Secure Computer Systems," ESD-TR-76-372, MTR-
3153, The MITRE Corporation, Bedford, MA, April 1977.
A LABEL.
+ Rationale
THE INTERPRETATION IS AN EXTENSION OF THE REQUIREMENT
INTO THE CONTEXT OF A NETWORK SYSTEM AND PARTITIONED NTCB AS
DEFINED FOR THESE NETWORK INTERPRETATIONS. A SINGLE-LEVEL
DEVICE MAY BE REGARDED EITHER AS A SUBJECT OR AN OBJECT. A
MULTILEVEL DEVICE IS REGARDED AS A TRUSTED SUBJECT IN WHICH
THE SECURITY RANGE OF THE SUBJECT IS THE MINIMUM-MAXIMUM
RANGE OF THE DATA EXPECTED TO BE TRANSMITTED OVER THE DEV-
ICE.
THE SENSITIVITY LABELS FOR EITHER SECRECY OR INTEGRITY
OR BOTH MAY REFLECT NON-HIERARCHICAL CATEGORIES OR HIERARCH-
ICAL CLASSIFICATION OR BOTH.
3.1.1.3.1 Label Integrity
+ Statement from DoD 5200.28-STD
SENSITIVITY LABELS SHALL ACCURATELY REPRESENT SENSITIVITY
LEVELS OF THE SPECIFIC SUBJECTS OR OBJECTS WITH WHICH THEY
ARE ASSOCIATED. WHEN EXPORTED BY THE TCB, SENSITIVITY
LABELS SHALL ACCURATELY AND UNAMBIGUOUSLY REPRESENT THE
INTERNAL LABELS AND SHALL BE ASSOCIATED WITH THE INFORMATION
BEING EXPORTED.
+ Interpretation
THE PHRASE "EXPORTED BY THE TCB" IS UNDERSTOOD TO
INCLUDE TRANSMISSION OF INFORMATION FROM AN OBJECT IN ONE
COMPONENT TO AN OBJECT IN ANOTHER COMPONENT. INFORMATION
TRANSFERRED BETWEEN NTCB PARTITIONS IS ADDRESSED IN THE SYS-
TEM INTEGRITY SECTION. THE FORM OF INTERNAL AND EXTERNAL
(EXPORTED) SENSITIVITY LABELS MAY DIFFER, BUT THE MEANING
SHALL BE THE SAME. THE NTCB SHALL, IN ADDITION, ENSURE THAT
CORRECT ASSOCIATION OF SENSITIVITY LABELS WITH THE INFORMA-
TION BEING TRANSPORTED ACROSS THE NETWORK IS PRESERVED.
AS MENTIONED IN THE TRUSTED FACILITY MANUAL SECTION,
ENCRYPTION TRANSFORMS THE REPRESENTATION OF INFORMATION SO
THAT IT IS UNINTELLIGIBLE TO UNAUTHORIZED SUBJECTS.
REFLECTING THIS TRANSFORMATION, THE SENSITIVITY LEVEL OF THE
CIPHERTEXT IS GENERALLY LOWER THAN THE CLEARTEXT. IT FOL-
LOWS THAT CLEARTEXT AND CIPHERTEXT ARE CONTAINED IN DIF-
FERENT OBJECTS, EACH POSSESSING ITS OWN LABEL. THE LABEL OF
THE CLEARTEXT MUST BE PRESERVED AND ASSOCIATED WITH THE
CIPHERTEXT SO THAT IT CAN BE RESTORED WHEN THE CLEARTEXT IS
SUBSEQUENTLY OBTAINED BY DECRYPTING THE CIPHERTEXT. IF THE
CLEARTEXT IS ASSOCIATED WITH A SINGLE-LEVEL DEVICE, THE
LABEL OF THAT CLEARTEXT MAY BE IMPLICIT. THE LABEL MAY ALSO
BE IMPLICIT IN THE KEY.
WHEN INFORMATION IS EXPORTED TO AN ENVIRONMENT WHERE IT
IS SUBJECT TO DELIBERATE OR ACCIDENTAL MODIFICATION, THE TCB
SHALL SUPPORT THE MEANS, SUCH AS CRYPTOGRAPHIC CHECKSUMS, TO
ASSURE THE ACCURACY OF THE LABELS. WHEN THERE IS A MANDA-
TORY INTEGRITY POLICY, THE POLICY WILL DEFINE THE MEANING OF
INTEGRITY LABELS.
+ Rationale
ENCRYPTION ALGORITHMS AND THEIR IMPLEMENTATION ARE OUT-
SIDE THE SCOPE OF THESE INTERPRETATIONS. SUCH ALGORITHMS
MAY BE IMPLEMENTED IN A SEPARATE DEVICE OR MAY BE INCOR-
PORATED IN A SUBJECT OF A LARGER COMPONENT. WITHOUT PREJU-
DICE, EITHER IMPLEMENTATION PACKAGING IS REFERRED TO AS AN
ENCRYPTION MECHANISM HEREIN. IF ENCRYPTION METHODOLOGIES ARE
EMPLOYED IN THIS REGARD, THEY SHALL BE APPROVED BY THE
NATIONAL SECURITY AGENCY (NSA). THE ENCRYPTION PROCESS IS
PART OF THE NETWORK TRUSTED COMPUTER BASE PARTITION IN THE
COMPONENTS IN WHICH IT IS IMPLEMENTED.
THE ENCRYPTION MECHANISM IS NOT NECESSARILY A MUL-
TILEVEL DEVICE OR MULTILEVEL SUBJECT, AS THESE TERMS ARE
USED IN THESE CRITERIA. THE PROCESS OF ENCRYPTION IS MUL-
TILEVEL BY DEFINITION. THE CLEARTEXT AND CIPHERTEXT INTER-
FACES CARRY INFORMATION OF DIFFERENT SENSITIVITY. AN
ENCRYPTION MECHANISM DOES NOT PROCESS DATA IN THE SENSE OF
PERFORMING LOGICAL OR ARITHMETIC OPERATIONS ON THAT DATA
WITH THE INTENT OF PRODUCING NEW DATA. THE CLEARTEXT AND
CIPHERTEXT INTERFACES ON THE ENCRYPTION MECHANISM MUST BE
SEPARATELY IDENTIFIED AS BEING SINGLE-LEVEL OR MULTILEVEL.
IF THE INTERFACE IS SINGLE-LEVEL, THEN THE SENSITIVITY OF
THE DATA IS ESTABLISHED BY A TRUSTED INDIVIDUAL AND IMPLI-
CITLY ASSOCIATED WITH THE INTERFACE; THE EXPORTATION TO
SINGLE-LEVEL DEVICES CRITERION APPLIES.
IF THE INTERFACE IS MULTILEVEL, THEN THE DATA MUST BE
LABELED; THE EXPORTATION TO MULTILEVEL DEVICES CRITERION
APPLIES. THE NETWORK ARCHITECT IS FREE TO SELECT AN ACCEPT-
TABLE MECHANISM FOR ASSOCIATING A LABEL WITH AN OBJECT. WITH
REFERENCE TO ENCRYPTED OBJECTS, THE FOLLOWING EXAMPLES ARE
POSSIBLE:
1. INCLUDE A LABEL FIELD IN THE PROTOCOL DEFINITION OF
THE OBJECT.
2. IMPLICITLY ASSOCIATE THE LABEL WITH THE OBJECT
THROUGH THE ENCRYPTION KEY. THAT IS, THE ENCRYPTION
KEY UNIQUELY IDENTIFIES A SENSITIVITY LEVEL. A SIN-
GLE OR PRIVATE KEY MUST BE PROTECTED AT THE LEVEL OF
THE DATA THAT IT ENCRYPTS.
3.1.1.3.2 Exportation of Labeled Information
+ Statement from DoD 5200.28-STD
THE TCB SHALL DESIGNATE EACH COMMUNICATION CHANNEL AND I/O
DEVICE AS EITHER SINGLE-LEVEL OR MULTILEVEL. ANY CHANGE IN
THIS DESIGNATION SHALL BE DONE MANUALLY AND SHALL BE AUDIT-
ABLE BY THE TCB. THE TCB SHALL MAINTAIN AND BE ABLE TO
AUDIT ANY CHANGE IN THE SENSITIVITY LEVEL OR LEVELS ASSOCI-
ATED WITH A COMMUNICATIONS CHANNEL OR I/O DEVICE.
+ Interpretation
EACH COMMUNICATION CHANNEL AND NETWORK COMPONENT SHALL
BE DESIGNATED AS EITHER SINGLE-LEVEL OR MULTILEVEL. ANY
CHANGE IN THIS DESIGNATION SHALL BE DONE WITH THE COGNIZANCE
AND APPROVAL OF THE ADMINISTRATOR OR SECURITY OFFICER IN
CHARGE OF THE AFFECTED COMPONENTS AND THE ADMINISTRATOR OR
SECURITY OFFICER IN CHARGE OF THE NTCB. THIS CHANGE SHALL
BE AUDITABLE BY THE NETWORK. THE NTCB SHALL MAINTAIN AND BE
ABLE TO AUDIT ANY CHANGE IN THE CURRENT SENSITIVITY LEVEL
ASSOCIATED WITH THE DEVICE CONNECTED TO A SINGLE-LEVEL COM-
MUNICATION CHANNEL OR THE RANGE ASSOCIATED WITH A MULTILEVEL
COMMUNICATION CHANNEL OR COMPONENT. THE NTCB SHALL ALSO BE
ABLE TO AUDIT ANY CHANGE IN THE SET OF SENSITIVITY LEVELS
ASSOCIATED WITH THE INFORMATION WHICH CAN BE TRANSMITTED
OVER A MULTILEVEL COMMUNICATION CHANNEL OR COMPONENT.
+ Rationale
COMMUNICATION CHANNELS AND COMPONENTS IN A NETWORK ARE
ANALOGOUS TO COMMUNICATION CHANNELS AND I/O DEVICES IN
STAND-ALONE SYSTEMS. THEY MUST BE DESIGNATED AS EITHER MUL-
TILEVEL (I.E., ABLE TO DISTINGUISH AND MAINTAIN SEPARATION
AMONG INFORMATION OF VARIOUS SENSITIVITY LEVELS) OR SINGLE-
LEVEL. AS IN THE TCSEC, SINGLE-LEVEL DEVICES MAY ONLY BE
ATTACHED TO SINGLE-LEVEL CHANNELS.
THE LEVEL OR SET OF LEVELS OF INFORMATION THAT CAN BE
SENT TO A COMPONENT OR OVER A COMMUNICATION CHANNEL SHALL
ONLY CHANGE WITH THE KNOWLEDGE AND APPROVAL OF THE SECURITY
OFFICERS (OR SYSTEM ADMINISTRATOR, IF THERE IS NO SECURITY
OFFICER) OF THE NETWORK, AND OF THE AFFECTED COMPONENTS.
THIS REQUIREMENT ENSURES THAT NO SIGNIFICANT SECURITY-
RELEVANT CHANGES ARE MADE WITHOUT THE APPROVAL OF ALL
AFFECTED PARTIES.
3.1.1.3.2.1 Exportation to Multilevel Devices
+ Statement from DoD 5200.28-STD
WHEN THE TCB EXPORTS AN OBJECT TO A MULTILEVEL I/O DEVICE,
THE SENSITIVITY LABEL ASSOCIATED WITH THAT OBJECT SHALL ALSO
BE EXPORTED AND SHALL RESIDE ON THE SAME PHYSICAL MEDIUM AS
THE EXPORTED INFORMATION AND SHALL BE IN THE SAME FORM
(I.E., MACHINE-READABLE OR HUMAN-READABLE FORM). WHEN THE
TCB EXPORTS OR IMPORTS AN OBJECT OVER A MULTILEVEL COMMUNI-
CATIONS CHANNEL, THE PROTOCOL USED ON THAT CHANNEL SHALL
PROVIDE FOR THE UNAMBIGUOUS PAIRING BETWEEN THE SENSITIVITY
LABELS AND THE ASSOCIATED INFORMATION THAT IS SENT OR
RECEIVED.
+ Interpretation
THE COMPONENTS, INCLUDING HOSTS, OF A NETWORK SHALL BE
INTERCONNECTED OVER "MULTILEVEL COMMUNICATION CHANNELS,"
MULTIPLE SINGLE-LEVEL COMMUNICATION CHANNELS, OR BOTH, WHEN-
EVER THE INFORMATION IS TO BE PROTECTED AT MORE THAN A SIN-
GLE SENSITIVITY LEVEL. THE PROTOCOL FOR ASSOCIATING THE
SENSITIVITY LABEL AND THE EXPORTED INFORMATION SHALL PROVIDE
THE ONLY INFORMATION NEEDED TO CORRECTLY ASSOCIATE A SENSI-
TIVITY LEVEL WITH THE EXPORTED INFORMATION TRANSFERRED OVER
THE MULTILEVEL CHANNEL BETWEEN THE NTCB PARTITIONS IN INDI-
VIDUAL COMPONENTS. THIS PROTOCOL DEFINITION MUST SPECIFY THE
REPRESENTATION AND SEMANTICS OF THE SENSITIVITY LABELS
(I.E., THE MACHINE-READABLE LABEL MUST UNIQUELY REPRESENT
THE SENSITIVITY LEVEL).
THE "UNAMBIGUOUS" ASSOCIATION OF THE SENSITIVITY LEVEL
WITH THE COMMUNICATED INFORMATION SHALL MEET THE SAME LEVEL
OF ACCURACY AS THAT REQUIRED FOR ANY OTHER LABEL WITHIN THE
NTCB, AS SPECIFIED IN THE CRITERION FOR LABEL INTEGRITY.
THIS MAY BE PROVIDED BY PROTECTED AND HIGHLY RELIABLE DIRECT
PHYSICAL LAYER CONNECTIONS, OR BY TRADITIONAL CRYPTOGRAPHIC
LINK PROTECTION IN WHICH ANY ERRORS DURING TRANSMISSION CAN
BE READILY DETECTED, OR BY USE OF A SEPARATE CHANNEL.
+ Rationale
THIS PROTOCOL MUST SPECIFY THE REPRESENTATION AND
SEMANTICS OF THE SENSITIVITY LABELS. SEE THE MANDATORY
ACCESS CONTROL POLICIES SECTION IN APPENDIX B. THE MUL-
TILEVEL DEVICE INTERFACE TO (UNTRUSTED) SUBJECTS MAY BE
IMPLEMENTED EITHER BY THE INTERFACE OF THE REFERENCE MONI-
TOR, PER SE, OR BY A MULTILEVEL SUBJECT (E.G., A "TRUSTED
SUBJECT" AS DEFINED IN THE BELL-LAPADULA MODEL) THAT PRO-
VIDES THE LABELS BASED ON THE INTERNAL LABELS OF THE NTCB
PARTITION.
THE CURRENT STATE OF THE ART LIMITS THE SUPPORT FOR
MANDATORY POLICY THAT IS PRACTICAL FOR SECURE NETWORKS.
REFERENCE MONITOR SUPPORT TO ENSURE THE CONTROL OVER ALL THE
OPERATIONS OF EACH SUBJECT IN THE NETWORK MUST BE COMPLETELY
PROVIDED WITHIN THE SINGLE NTCB PARTITION ON WHICH THAT SUB-
JECT INTERFACES TO THE NTCB. THIS MEANS THAT THE ENTIRE
PORTION OF THE "SECURE STATE" REPRESENTED IN THE SECURITY
POLICY MODEL THAT MAY BE CHANGED BY TRANSITIONS INVOKED BY
THIS SUBJECT MUST BE CONTAINED IN THE SAME COMPONENT.
THE SECURE STATE OF AN NTCB PARTITION MAY BE AFFECTED
BY EVENTS EXTERNAL TO THE COMPONENT IN WHICH THE NTCB PARTI-
TION RESIDES (E.G., ARRIVAL OF A MESSAGE). THE EFFECT
OCCURS ASYNCHRONUSLY AFTER BEING INITIATED BY AN EVENT IN
ANOTHER COMPONENT OR PARTITION. FOR EXAMPLE, INDETERMINATE
DELAYS MAY OCCUR BETWEEN THE INITIATION OF A MESSAGE IN ONE
COMPONENT, THE ARRIVAL OF THE MESSAGE IN THE NTCB PARTITION
IN ANOTHER COMPONENT, AND THE CORRESPONDING CHANGE TO THE
SECURE STATE OF THE SECOND COMPONENT. SINCE EACH COMPONENT
IS EXECUTING CONCURRENTLY, TO DO OTHERWISE WOULD REQUIRE
SOME SORT OF NETWORK-WIDE CONTROL TO SYNCHRONIZE STATE TRAN-
SITIONS, SUCH AS A GLOBAL NETWORK-WIDE CLOCK FOR ALL PROCES-
SORS; IN GENERAL, SUCH DESIGNS ARE NOT PRACTICAL AND PROB-
ABLY NOT EVEN DESIRABLE. THEREFORE, THE INTERACTION BETWEEN
NTCB PARTITIONS IS RESTRICTED TO JUST COMMUNICATIONS BETWEEN
PAIRS (AT LEAST LOGICALLY) OF DEVICES-MULTILEVEL DEVICES IF
THE DEVICE(S) CAN SEND/RECEIVE DATA OF MORE THAN A SINGLE
LEVEL. FOR BROADCAST CHANNELS THE PAIRS ARE THE SENDER AND
INTENDED RECEIVER(S). HOWEVER, IF THE BROADCAST CHANNEL
CARRIES MULTIPLE LEVELS OF INFORMATION, ADDITIONAL MECHANISM
(E.G., CRYPTOCHECKSUM MAINTAINED BY THE TCB) MAY BE REQUIRED
TO ENFORCE SEPARATION AND PROPER DELIVERY.
A COMMON REPRESENTATION FOR SENSITIVITY LABELS IS
NEEDED IN THE PROTOCOL USED ON THAT CHANNEL AND UNDERSTOOD
BY BOTH THE SENDER AND RECEIVER WHEN TWO MULTILEVEL DEVICES
(IN THIS CASE, IN TWO DIFFERENT COMPONENTS) ARE INTERCON-
NECTED. EACH DISTINCT SENSITIVITY LEVEL OF THE OVERALL NET-
WORK POLICY MUST BE REPRESENTED UNIQUELY IN THESE LABELS.
WITHIN A MONOLITHIC TCB, THE ACCURACY OF THE SENSI-
TIVITY LABELS IS GENERALLY ASSURED BY SIMPLE TECHNIQUES,
E.G., VERY RELIABLE CONNECTIONS OVER VERY SHORT PHYSICAL
CONNECTIONS, SUCH AS ON A SINGLE PRINTED CIRCUIT BOARD OR
OVER AN INTERNAL BUS. IN MANY NETWORK ENVIRONMENTS THERE IS
A MUCH HIGHER PROBABILITY OF ACCIDENTALLY OR MALICIOUSLY
INTRODUCED ERRORS, AND THESE MUST BE PROTECTED AGAINST.
3.1.1.3.2.2 Exportation to Single-Level Devices
+ Statement from DoD 5200.28-STD
SINGLE-LEVEL I/O DEVICES AND SINGLE-LEVEL COMMUNICATION
CHANNELS ARE NOT REQUIRED TO MAINTAIN THE SENSITIVITY LABELS
OF THE INFORMATION THEY PROCESS. HOWEVER, THE TCB SHALL
INCLUDE A MECHANISM BY WHICH THE TCB AND AN AUTHORIZED USER
RELIABLY COMMUNICATE TO DESIGNATE THE SINGLE SENSITIVITY
LEVEL OF INFORMATION IMPORTED OR EXPORTED VIA SINGLE-LEVEL
COMMUNICATION CHANNELS OR I/O DEVICES.
+ Interpretation
WHENEVER ONE OR BOTH OF TWO DIRECTLY CONNECTED COM-
PONENTS IS NOT TRUSTED TO MAINTAIN THE SEPARATION OF INFOR-
MATION OF DIFFERENT SENSITIVITY LEVELS, OR WHENEVER THE TWO
DIRECTLY CONNECTED COMPONENTS HAVE ONLY A SINGLE SENSITIVITY
LEVEL IN COMMON, THE TWO COMPONENTS OF THE NETWORK SHALL
COMMUNICATE OVER A SINGLE-LEVEL CHANNEL. SINGLE-LEVEL COM-
PONENTS AND SINGLE-LEVEL COMMUNICATION CHANNELS ARE NOT
REQUIRED TO MAINTAIN THE SENSITIVITY LABELS OF THE
INFORMATION THEY PROCESS. HOWEVER, THE NTCB SHALL INCLUDE A
RELIABLE COMMUNICATION MECHANISM BY WHICH THE NTCB AND AN
AUTHORIZED USER OR A SUBJECT WITHIN AN NTCB PARTITION CAN
DESIGNATE THE SINGLE SENSITIVITY LEVEL OF INFORMATION
IMPORTED OR EXPORTED VIA SINGLE-LEVEL COMMUNICATION CHANNELS
OR NETWORK COMPONENTS.
+ Rationale
SINGLE-LEVEL COMMUNICATIONS CHANNELS AND SINGLE-LEVEL
COMPONENTS IN NETWORKS ARE ANALOGOUS TO SINGLE LEVEL CHAN-
NELS AND I/O DEVICES IN STAND-ALONE SYSTEMS IN THAT THEY ARE
NOT TRUSTED TO MAINTAIN THE SEPARATION OF INFORMATION OF
DIFFERENT SENSITIVITY LEVELS. THE LABELS ASSOCIATED WITH
DATA TRANSMITTED OVER THOSE CHANNELS AND BY THOSE COMPONENTS
ARE THEREFORE IMPLICIT; THE NTCB ASSOCIATES LABELS WITH THE
DATA BECAUSE OF THE CHANNEL OR COMPONENT, NOT BECAUSE OF AN
EXPLICIT PART OF THE BIT STREAM. NOTE THAT THE SENSITIVITY
LEVEL OF ENCRYPTED INFORMATION IS THE LEVEL OF THE CIPHER-
TEXT RATHER THAN THE ORIGINAL LEVEL(S) OF THE PLAINTEXT.
3.1.1.3.2.3 Labeling Human-Readable Output
+ Statement from DoD 5200.28-STD
THE ADP SYSTEM ADMINISTRATOR SHALL BE ABLE TO SPECIFY THE
PRINTABLE LABEL NAMES ASSOCIATED WITH EXPORTED SENSITIVITY
LABELS. THE TCB SHALL MARK THE BEGINNING AND END OF ALL
HUMAN-READABLE, PAGED, HARDCOPY OUTPUT (E.G., LINE PRINTER
OUTPUT) WITH HUMAN-READABLE SENSITIVITY LABELS THAT PROP-
ERLY1 REPRESENT THE SENSITIVITY OF THE OUTPUT. THE TCB
SHALL, BY DEFAULT, MARK THE TOP AND BOTTOM OF EACH PAGE OF
HUMAN-READABLE, PAGED, HARDCOPY OUTPUT (E.G., LINE PRINTER
OUTPUT) WITH HUMAN-READABLE SENSITIVITY LABELS THAT PROP-
ERLY1 REPRESENT THE SENSITIVITY OF THE PAGE. THE TCB SHALL,
BY DEFAULT AND IN AN APPROPRIATE MANNER, MARK OTHER FORMS OF
HUMAN READABLE OUTPUT (E.G., MAPS, GRAPHICS) WITH HUMAN-
READABLE SENSITIVITY LABELS THAT PROPERLY1 REPRESENT THE
SENSITIVITY OF THE OUTPUT. ANY OVERRIDE OF THESE MARKINGS
DEFAULTS SHALL BE AUDITABLE BY THE TCB.
+ Interpretation
THIS CRITERION IMPOSES NO REQUIREMENT TO A COMPONENT
THAT PRODUCES NO HUMAN-READABLE OUTPUT. FOR THOSE THAT DO
PRODUCE HUMAN-READABLE OUTPUT, EACH SENSITIVITY LEVEL THAT
_________________________
1 THE HIERARCHICAL CLASSIFICATION COMPONENT IN HUMAN-
READABLE SENSITIVITY LABELS SHALL BE EQUAL TO THE
GREATEST HIERARCHICAL CLASSIFICATION OF ANY OF THE IN-
FORMATION IN THE OUTPUT THAT THE LABELS REFER TO; THE
NON-HIERARCHICAL CATEGORY COMPONENT SHALL INCLUDE ALL
OF THE NON-HIERARCHICAL CATEGORIES OF THE INFORMATION
IN THE OUTPUT THE LABELS REFER TO, BUT NO OTHER NON-
HIERARCHICAL CATEGORIES.
IS DEFINED TO THE NETWORK SHALL HAVE A UNIFORM MEANING
ACROSS ALL COMPONENTS. THE NETWORK ADMINISTRATOR, IN CON-
JUNCTION WITH ANY AFFECTED COMPONENT ADMINISTRATOR, SHALL BE
ABLE TO SPECIFY THE HUMAN-READABLE LABEL THAT IS ASSOCIATED
WITH EACH DEFINED SENSITIVITY LEVEL.
+ Rationale
THE INTERPRETATION IS A STRAIGHTFORWARD EXTENSION OF
THE REQUIREMENT INTO THE CONTEXT OF A NETWORK SYSTEM AND
PARTITIONED NTCB AS DEFINED FOR THESE NETWORK INTERPRETA-
TIONS.
3.1.1.4 Mandatory Access Control
+ Statement from DoD 5200.28-STD
THE TCB SHALL ENFORCE A MANDATORY ACCESS CONTROL POLICY OVER
ALL SUBJECTS AND STORAGE OBJECTS UNDER ITS CONTROL (E.G.,
PROCESSES, FILES, SEGMENTS, DEVICES). THESE SUBJECTS AND
OBJECTS SHALL BE ASSIGNED SENSITIVITY LABELS THAT ARE A COM-
BINATION OF HIERARCHICAL CLASSIFICATION LEVELS AND NON-
HIERARCHICAL CATEGORIES, AND THE LABELS SHALL BE USED AS THE
BASIS FOR MANDATORY ACCESS CONTROL DECISIONS. THE TCB SHALL
BE ABLE TO SUPPORT TWO OR MORE SUCH SENSITIVITY LEVELS.
(SEE THE MANDATORY ACCESS CONTROL INTERPRETATIONS.) THE
FOLLOWING REQUIREMENTS SHALL HOLD FOR ALL ACCESSES BETWEEN
SUBJECTS AND OBJECTS CONTROLLED BY THE TCB: A SUBJECT CAN
READ AN OBJECT ONLY IF THE HIERARCHICAL CLASSIFICATION IN
THE SUBJECT'S SENSITIVITY LEVEL IS GREATER THAN OR EQUAL TO
THE HIERARCHICAL CLASSIFICATION OF THE OBJECT'S SENSITIVITY
LEVEL AND THE NON-HIERARCHICAL CATEGORIES IN THE SUBJECT'S
SENSITIVITY LEVEL INCLUDE ALL THE NON-HIERARCHICAL
CATEGORIES IN THE OBJECT'S SENSITIVITY LEVEL. A SUBJECT CAN
WRITE AN OBJECT ONLY IF THE HIERARCHICAL CLASSIFICATION IN
THE SUBJECT'S SENSITIVITY LEVEL IS LESS THAN OR EQUAL TO THE
HIERARCHICAL CLASSIFICATION OF THE OBJECT'S SENSITIVITY
LEVEL AND THE NON-HIERARCHICAL CATEGORIES IN THE SUBJECT'S
SENSITIVITY LEVEL ARE INCLUDED IN THE NON-HIERARCHICAL
CATEGORIES IN THE OBJECT'S SENSITIVITY LEVEL. IDENTIFICATION
AND AUTHENTICATION DATA SHALL BE USED BY THE TCB TO AUTHEN-
TICATE THE USER'S IDENTITY AND TO ENSURE THAT THE SENSI-
TIVITY LEVEL AND AUTHORIZATION OF SUBJECTS EXTERNAL TO THE
TCB THAT MAY BE CREATED TO ACT ON BEHALF OF THE INDIVIDUAL
USER ARE DOMINATED BY THE CLEARANCE AND AUTHORIZATION OF
THAT USER.
+ Interpretation
EACH PARTITION OF THE NTCB EXERCISES MANDATORY ACCESS
CONTROL POLICY OVER ALL SUBJECTS AND OBJECTS IN ITS COM-
PONENT THAT ARE UNDER ITS CONTROL. IN A NETWORK, THE
RESPONSIBILITY OF AN NTCB PARTITION ENCOMPASSES ALL MANDA-
TORY ACCESS CONTROL FUNCTIONS IN ITS COMPONENT THAT WOULD BE
REQUIRED OF A TCB IN A STAND-ALONE SYSTEM. IN PARTICULAR,
SUBJECTS AND OBJECTS USED FOR COMMUNICATION WITH OTHER COM-
PONENTS ARE UNDER THE CONTROL OF THE NTCB PARTITION. MANDA-
TORY ACCESS CONTROL INCLUDES SECRECY AND INTEGRITY CONTROL
TO THE EXTENT THAT THE NETWORK SPONSOR HAS DESCRIBED IN THE
OVERALL NETWORK SECURITY POLICY.
CONCEPTUAL ENTITIES ASSOCIATED WITH COMMUNICATION
BETWEEN TWO COMPONENTS, SUCH AS SESSIONS, CONNECTIONS AND
VIRTUAL CIRCUITS, MAY BE THOUGHT OF AS HAVING TWO ENDS, ONE
IN EACH COMPONENT, WHERE EACH END IS REPRESENTED BY A LOCAL
OBJECT. COMMUNICATION IS VIEWED AS AN OPERATION THAT COPIES
INFORMATION FROM AN OBJECT AT ONE END OF A COMMUNICATION
PATH TO AN OBJECT AT THE OTHER END. TRANSIENT DATA-CARRYING
ENTITIES, SUCH AS DATAGRAMS AND PACKETS, EXIST EITHER AS
INFORMATION WITHIN OTHER OBJECTS, OR AS A PAIR OF OBJECTS,
ONE AT EACH END OF THE COMMUNICATION PATH.
THE REQUIREMENT FOR "TWO OR MORE" SENSITIVITY LEVELS
CAN BE MET BY EITHER SECRECY OR INTEGRITY LEVELS. WHEN
THERE IS A MANDATORY INTEGRITY POLICY, THE STATED REQUIRE-
MENTS FOR READING AND WRITING ARE GENERALIZED TO: A SUBJECT
CAN READ AN OBJECT ONLY IF THE SUBJECT'S SENSITIVITY LEVEL
DOMINATES THE OBJECT'S SENSITIVITY LEVEL, AND A SUBJECT CAN
WRITE AN OBJECT ONLY IF THE OBJECT'S SENSITIVITY LEVEL DOM-
INATES THE SUBJECT'S SENSITIVITY LEVEL. BASED ON THE
INTEGRITY POLICY, THE NETWORK SPONSOR SHALL DEFINE THE DOMI-
NANCE RELATION FOR THE TOTAL LABEL, FOR EXAMPLE, BY COMBIN-
ING SECRECY AND INTEGRITY LATTICES. -
+ Rationale
AN NTCB PARTITION CAN MAINTAIN ACCESS CONTROL ONLY OVER
SUBJECTS AND OBJECTS IN ITS COMPONENT. ACCESS BY A SUBJECT
IN ONE COMPONENT TO INFORMATION CONTAINED IN AN OBJECT IN
ANOTHER COMPONENT REQUIRES THE CREATION OF A SUBJECT IN THE
REMOTE COMPONENT WHICH ACTS AS A SURROGATE FOR THE FIRST
SUBJECT.
THE MANDATORY ACCESS CONTROLS MUST BE ENFORCED AT THE
INTERFACE OF THE REFERENCE MONITOR (VIZ. THE MECHANISM THAT
CONTROLS PHYSICAL PROCESSING RESOURCES) FOR EACH NTCB PARTI-
TION. THIS MECHANISM CREATES THE ABSTRACTION OF SUBJECTS
AND OBJECTS WHICH IT CONTROLS. SOME OF THESE SUBJECTS OUT-
SIDE THE REFERENCE MONITOR, PER SE, MAY BE DESIGNATED TO
IMPLEMENT PART OF AN NTCB PARTITION'S MANDATORY POLICY,
E.G., BY USING THE ``TRUSTED SUBJECTS" DEFINED IN THE BELL-
_________________________
- See, for example, Grohn, M. J., A Model of a Pro-
_ _____ __ _ ___
tected Data Management System, ESD-TR-76-289, I. P.
______ ____ __________ ______
Sharp Assoc. Ltd., June, 1976; and Denning, D .E.,
Lunt, T. F., Neumann, P. G., Schell, R. R., Heckman, M.
and Shockley, W., Secure Distributed Data Views, Secu-
______ ___________ ____ _____ ____
rity Policy and Interpretation for a Class A1 Multilev-
____ ______ ___ ______________ ___ _ _____ __ ________
el Secure Relational Database System,SRI International,
__ ______ __________ ________ ______
November 1986.
LAPADULA MODEL.
THE PRIOR REQUIREMENTS ON EXPORTATION OF LABELED INFOR-
MATION TO AND FROM I/O DEVICES ENSURE THE CONSISTENCY
BETWEEN THE SENSITIVITY LABELS OF OBJECTS CONNECTED BY A
COMMUNICATION PATH. AS NOTED IN THE INTRODUCTION, THE NET-
WORK ARCHITECTURE MUST RECOGNIZE THE LINKAGE BETWEEN THE
OVERALL MANDATORY NETWORK SECURITY POLICY AND THE CONNECTION
ORIENTED ABSTRACTION. FOR EXAMPLE, INDIVIDUAL DATA-CARRYING
ENTITIES SUCH AS DATAGRAMS CAN HAVE INDIVIDUAL SENSITIVITY
LABELS THAT SUBJECT THEM TO MANDATORY ACCESS CONTROL IN EACH
COMPONENT. THE ABSTRACTION OF A SINGLE-LEVEL CONNECTION IS
REALIZED AND ENFORCED IMPLICITLY BY AN ARCHITECTURE WHILE A
CONNECTION IS REALIZED BY SINGLE-LEVEL SUBJECTS THAT NECES-
SARILY EMPLOY ONLY DATAGRAMS OF THE SAME LEVEL.
THE FUNDAMENTAL TRUSTED SYSTEMS TECHNOLOGY PERMITS THE
DAC MECHANISM TO BE DISTRIBUTED, IN CONTRAST TO THE REQUIRE-
MENTS FOR MANDATORY ACCESS CONTROL. FOR NETWORKS THIS
SEPARATION OF MAC AND DAC MECHANISMS IS THE RULE RATHER THAN
THE EXCEPTION.
THE SET OF TOTAL SENSITIVITY LABELS USED TO REPRESENT
ALL THE SENSITIVITY LEVELS FOR THE MANDATORY ACCESS CONTROL
(COMBINED DATA SECRECY AND DATA INTEGRITY) POLICY ALWAYS
FORMS A PARTIALLY ORDERED SET. WITHOUT LOSS OF GENERALITY,
THIS SET OF LABELS CAN ALWAYS BE EXTENDED TO FORM A LATTICE,
BY INCLUDING ALL THE COMBINATIONS OF NON-HIERARCHICAL
CATEGORIES. AS FOR ANY LATTICE, A DOMINANCE RELATION IS
ALWAYS DEFINED FOR THE TOTAL SENSITIVITY LABELS. FOR ADMIN-
ISTRATIVE REASONS IT MAY BE HELPFUL TO HAVE A MAXIMUM LEVEL
WHICH DOMINATES ALL OTHERS.
3.1.2 Accountability
_ _ _ ______________
3.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 MAINTAIN
AUTHENTICATION DATA THAT INCLUDES INFORMATION FOR VERIFYING
THE IDENTIFY OF INDIVIDUAL USERS (E.G., PASSWORDS) AS WELL
AS INFORMATION FOR DETERMINING THE CLEARANCE AND AUTHORIZA-
TIONS OF INDIVIDUAL USERS. THIS DATA SHALL BE USED BY THE
TCB TO AUTHENTICATE THE USER'S IDENTITY AND TO ENSURE THAT
THE SENSITIVITY LEVEL AND AUTHORIZATION OF SUBJECTS EXTERNAL
TO THE TCB THAT MAY BE CREATED TO ACT ON BEHALF OF THE INDI-
VIDUAL USER ARE DOMINATED BY THE CLEARANCE AND AUTHORIZATION
OF THAT USER. 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
capability 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. IF THE AUTHENTICATED IDENTIFICATION IS USED AS THE
BASIS OF DETERMINING A SENSITIVITY LABEL FOR A SUBJECT, IT
MUST SATISFY THE LABEL INTEGRITY CRITERION.
AN AUTHENTICATED IDENTIFICATION MAY BE FORWARDED
BETWEEN COMPONENTS AND EMPLOYED IN SOME COMPONENT TO IDEN-
TIFY THE SENSITIVITY LEVEL ASSOCIATED WITH A SUBJECT CREATED
TO ACT ON BEHALF OF THE USER SO IDENTIFIED.
3.1.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. THE TCB SHALL ALSO BE ABLE TO AUDIT ANY OVERRIDE OF
HUMAN-READABLE OUTPUT MARKINGS. 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 AND THE OBJECT'S
SENSITIVITY LEVEL. The ADP system administrator shall be
able to selectively audit the actions of any one or more
users based on individual identify AND/OR OBJECT SENSITIVITY
LEVEL.
+ 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.
3.1.3 Assurance
_ _ _ _________
3.1.3.1 Operational Assurance
3.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. THE TCB SHALL MAINTAIN
PROCESS ISOLATION THROUGH THE PROVISION OF DISTINCT ADDRESS
SPACES UNDER ITS CONTROL. 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. SINCE EACH COMPONENT IS ITSELF A DIS-
TINCT DOMAIN IN THE OVERALL NETWORK SYSTEM, THIS ALSO SATIS-
FIES THE REQUIREMENT FOR PROCESS ISOLATION THROUGH DISTINCT
ADDRESS SPACES IN THE SPECIAL CASE WHERE A COMPONENT HAS
ONLY A SINGLE SUBJECT.
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 SO THAT
"SUPPORTING ELEMENTS" (E.G., DAC AND USER IDENTIFICATION)
FOR THE SECURITY MECHANISMS OF THE NETWORK SYSTEM ARE
STRENGTHENED COMPARED TO C2, FROM AN ASSURANCE POINT OF
VIEW, THROUGH THE PROVISION OF DISTINCT ADDRESS SPACES UNDER
CONTROL OF THE NTCB.
AS DISCUSSED IN THE DISCRETIONARY ACCESS CONTROL SEC-
TION, 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. WHEN DISTRIBUTED IN NTCB SUB-
JECTS (I.E., WHEN OUTSIDE THE REFERENCE MONITOR), THE
ASSURANCE REQUIREMENTS FOR THE DESIGN AND IMPLEMENTATION OF
THE DAC SHALL BE THOSE OF CLASS C2 FOR ALL NETWORKS OF CLASS
C2 OR ABOVE.
+ 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.
THE PROVISION OF DISTINCT ADDRESS SPACES UNDER THE CON-
TROL OF THE NTCB PROVIDES THE ABILITY TO SEPARATE SUBJECTS
ACCORDING TO SENSITIVITY LEVEL. THIS REQUIREMENT IS INTRO-
DUCED AT B1 SINCE IT IS AN ABSOLUTE NECESSITY IN ORDER TO
IMPLEMENT MANDATORY ACCESS CONTROLS.
3.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 MANDATORY AND dis-
cretionary access control policy in a network may require
communication between trusted subjects that are part of the
NTCB partitions in different components. This communication
is normally 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.
3.1.3.2 Life-Cycle Assurance
3.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. A
TEAM OF INDIVIDUALS WHO THOROUGHLY UNDERSTAND THE SPECIFIC
IMPLEMENTATION OF THE TCB SHALL SUBJECT ITS DESIGN DOCUMEN-
TATION, SOURCE CODE, AND OBJECT CODE TO THROUGH ANALYSIS AND
TESTING. THEIR OBJECTIVES SHALL BE: TO UNCOVER ALL DESIGN
AND IMPLEMENTATION FLAWS THAT WOULD PERMIT A SUBJECT EXTER-
NAL TO THE TCB TO READ, CHANGE, OR DELETE DATA NORMALLY
DENIED UNDER THE MANDATORY OR DISCRETIONARY SECURITY POLICY
ENFORCED BY THE TCB; AS WELL AS TO ASSURE THAT NO SUBJECT
(WITHOUT AUTHORIZATION TO DO SO) IS ABLE TO CAUSE THE TCB TO
ENTER A STATE SUCH THAT IT IS UNABLE TO RESPOND TO COMMUNI-
CATIONS INITIATED BY OTHER USERS. ALL DISCOVERED FLAWS SHALL
BE REMOVED OR NEUTRALIZED AND THE TCB RETESTED TO DEMON-
STRATE THAT THEY HAVE BEEN ELIMINATED AND THAT NEW FLAWS
HAVE NOT BEEN INTRODUCED. (See the Security Testing Guide-
lines.)
+ Interpretation
Testing of a component will require a testbed that
exercises the interfaces and protocols of the component
including tests under exceptional conditions. 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 partition that
implement the given mechanism. This integrated testing is
additional to any individual component tests involved in the
evaluation of the network system. The sponsor should iden-
tify 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 configura-
tions. A change in configuration within the allowable set
of configurations does not require retesting.
THE TESTING OF EACH COMPONENT WILL INCLUDE THE INTRO-
DUCTION OF SUBJECTS EXTERNAL TO THE NTCB PARTITION FOR THE
COMPONENT THAT WILL ATTEMPT TO READ, CHANGE, OR DELETE DATA
NORMALLY DENIED. IF THE NORMAL INTERFACE TO THE COMPONENT
DOES NOT PROVIDE A MEANS TO CREATE THE SUBJECTS NEEDED TO
CONDUCT SUCH A TEST, THEN THIS PORTION OF THE TESTING SHALL
USE A SPECIAL VERSION OF THE UNTRUSTED SOFTWARE FOR THE COM-
PONENT THAT RESULTS IN SUBJECTS THAT MAKE SUCH ATTEMPTS.
THE RESULTS SHALL BE SAVED FOR TEST ANALYSIS. SUCH SPECIAL
VERSIONS SHALL HAVE AN NTCB PARTITION THAT IS IDENTICAL TO
THAT FOR THE NORMAL CONFIGURATION OF THE COMPONENT UNDER
EVALUATION.
THE TESTING OF THE MANDATORY CONTROLS SHALL INCLUDE
TESTS TO DEMONSTRATE THAT THE LABELS FOR INFORMATION
IMPORTED AND/OR EXPORTED TO/FROM THE COMPONENT ACCURATELY
REPRESENT THE LABELS MAINTAINED BY THE NTCB PARTITION FOR
THE COMPONENT FOR USE AS THE BASIS FOR ITS MANDATORY ACCESS
CONTROL DECISIONS. THE TESTS SHALL INCLUDE EACH TYPE OF
DEVICE, WHETHER SINGLE-LEVEL OR MULTILEVEL, SUPPORTED BY THE
COMPONENT.
+ Rationale
THE PHRASE "NO SUBJECT (WITHOUT AUTHORIZATION TO DO SO)
IS ABLE TO CAUSE THE TCB TO ENTER A STATE SUCH THAT IT IS
UNABLE TO RESPOND TO COMMUNICATIONS INITIATED BY OTHER
USERS" RELATES TO THE SECURITY SERVICES (PART II OF THIS
TNI) FOR THE DENIAL OF SERVICE PROBLEM, AND TO CORRECTNESS
OF THE PROTOCOL IMPLEMENTATIONS.
Testing is AN IMPORTANT method available in this
evaluation division to gain any assurance that the security
mechanisms perform their intended function. A MAJOR PURPOSE
OF TESTING IS TO DEMONSTRATE THE SYSTEM'S RESPONSE TO INPUTS
TO THE NTCB PARTITION FROM UNTRUSTED (AND POSSIBLY MALI-
CIOUS) SUBJECTS.
IN CONTRAST TO GENERAL PURPOSE SYSTEMS THAT ALLOW FOR
THE DYNAMIC CREATION OF NEW PROGRAMS AND THE INTRODUCTIONS
OF NEW PROCESSES (AND HENCE NEW SUBJECTS) WITH USER SPECI-
FIED SECURITY PROPERITIES, MANY NETWORK COMPONENTS HAVE NO
METHOD FOR INTRODUCING NEW PROGRAMS AND/OR PROCESSES DURING
THEIR NORMAL OPERATION. THEREFORE, THE PROGRAMS NECESSARY
FOR THE TESTING MUST BE INTRODUCED AS SPECIAL VERSIONS OF
THE SOFTWARE RATHER THAN AS THE RESULT OF NORMAL INPUTS BY
THE TEST TEAM. HOWEVER, IT MUST BE INSURED THAT THE NTCB
PARTITION USED FOR SUCH TESTS IS IDENTICAL TO THE ONE UNDER
EVALUATION.
SENSITIVITY LABELS SERVE A CRITICAL ROLE IN MAINTAINING
THE SECURITY OF THE MANDATORY ACCESS CONTROLS IN THE NET-
WORK. ESPECIALLY IMPORTANT TO NETWORK SECURITY IS THE ROLE
OF THE LABELS FOR INFORMATION COMMUNICATED BETWEEN COM-
PONENTS - EXPLICIT LABELS FOR MULTILEVEL DEVICES AND IMPLI-
CIT LABELS FOR SINGLE-LEVEL DEVICES. THEREFORE THE TESTING
FOR CORRECT LABELS IS HIGHLIGHTED.
3.1.3.2.2 Design Specification and Verification
+ Statement from DoD 5200.28-STD
AN INFORMAL OR FORMAL MODEL OF THE SECURITY POLICY SUPPORTED
BY THE TCB SHALL BE MAINTAINED OVER THE LIFE CYCLE OF THE
ADP SYSTEM AND DEMONSTRATED TO BE CONSISTENT WITH ITS
AXIOMS.
+ Interpretation
THE OVERALL NETWORK SECURITY POLICY EXPRESSED IN THIS
MODEL WILL PROVIDE THE BASIS FOR THE MANDATORY ACCESS CON-
TROL POLICY EXERCISED BY THE NTCB OVER SUBJECTS AND STORAGE
OBJECTS IN THE ENTIRE NETWORK. THE POLICY WILL ALSO BE THE
BASIS FOR THE DISCRETIONARY ACCESS CONTROL POLICY EXERCISED
BY THE NTCB TO CONTROL ACCESS OF NAMED USERS TO NAMED
OBJECTS. DATA INTEGRITY REQUIREMENTS ADDRESSING THE EFFECTS
OF UNAUTHORIZED MSM NEED NOT BE INCLUDED IN THIS MODEL. THE
OVERALL NETWORK POLICY MUST BE DECOMPOSED INTO POLICY ELE-
MENTS THAT ARE ALLOCATED TO APPROPRIATE COMPONENTS AND USED
AS THE BASIS FOR THE SECURITY POLICY MODEL FOR THOSE COM-
PONENTS.
THE LEVEL OF ABSTRACTION OF THE MODEL, AND THE SET OF
SUBJECTS AND OBJECTS THAT ARE EXPLICITLY REPRESENTED IN THE
MODEL, WILL BE AFFECTED BY THE NTCB PARTITIONING. SUBJECTS
AND OBJECTS MUST BE REPRESENTED EXPLICITLY IN THE MODEL FOR
THE PARTITION IF THERE IS SOME NETWORK COMPONENT WHOSE NTCB
PARTITION EXERCISES ACCESS CONTROL OVER THEM. THE MODEL
SHALL BE STRUCTURED SO THAT THE AXIOMS AND ENTITIES APPLICA-
BLE TO INDIVIDUAL NETWORK COMPONENTS ARE MANIFEST. GLOBAL
NETWORK POLICY ELEMENTS THAT ARE ALLOCATED TO COMPONENTS
SHALL BE REPRESENTED BY THE MODEL FOR THAT COMPONENT.
+ Rationale
THE TREATMENT OF THE MODEL DEPENDS TO A GREAT EXTENT ON
THE DEGREE OF INTEGRATION OF THE COMMUNICATIONS SERVICE INTO
A DISTRIBUTED SYSTEM. IN A CLOSELY COUPLED DISTRIBUTED SYS-
TEM, ONE MIGHT USE A MODEL THAT CLOSELY RESEMBLES ONE
APPROPRIATE FOR A STAND-ALONE COMPUTER SYSTEM.
IN OTHER CASES, THE MODEL OF EACH PARTITION WILL BE
EXPECTED TO SHOW THE ROLE OF THE NTCB PARTITION IN EACH KIND
OF COMPONENT. IT WILL MOST LIKELY CLARIFY THE MODEL,
ALTHOUGH NOT PART OF THE MODEL, TO SHOW ACCESS RESTRICTIONS
IMPLIED BY THE SYSTEM DESIGN; FOR EXAMPLE, SUBJECTS
REPRESENTING PROTOCOL ENTITIES MIGHT HAVE ACCESS ONLY TO
OBJECTS CONTAINING DATA UNITS AT THE SAME LAYER OF PROTOCOL.
THE ALLOCATION OF SUBJECTS AND OBJECTS TO DIFFERENT PROTO-
COL LAYERS IS A PROTOCOL DESIGN CHOICE WHICH NEED NOT BE
REFLECTED IN THE SECURITY POLICY MODEL.
3.1.4 Documentation.
_ _ _ _____________
3.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.
3.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. The procedures
for examining and maintaining the audit files as well as the
detailed audit record structure for each type of audit event
shall be given. THE MANUAL SHALL DESCRIBE THE OPERATOR AND
ADMINISTRATOR FUNCTIONS RELATED TO SECURITY, TO INCLUDE
CHANGING THE SECURITY CHARACTERISTICS OF A USER. IT SHALL
PROVIDE INTERPRETATIONS ON THE CONSISTENT AND EFFECTIVE USE
OF THE PROTECTION FEATURES OF THE SYSTEM, HOW THEY INTERACT,
HOW TO SECURELY GENERATE A NEW TCB, AND FACILITY PROCEDURES,
WARNINGS, AND PRIVILEGES THAT NEED TO BE CONTROLLED IN ORDER
TO OPERATE THE FACILITY IN A SECURE MANNER.
+ 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.
AS MENTIONED IN THE SECTION ON LABEL INTEGRITY, cryp-
tography is one common mechanism employed to protect commun-
ication 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.
3.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.
3.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. AN INFORMAL OR
FORMAL DESCRIPTION OF THE SECURITY POLICY MODEL ENFORCED BY
THE TCB SHALL BE AVAILABLE AND AN EXPLANATION PROVIDED TO
SHOW THAT IT IS SUFFICIENT TO ENFORCE THE SECURITY POLICY.
THE SPECIFIC TCB PROTECTION MECHANISMS SHALL BE IDENTIFIED
AND AN EXPLANATION GIVEN TO SHOW THAT THEY SATISFY THE
MODEL.
+ 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.
AS STATED IN THE INTRODUCTION TO DIVISION B, THE SPON-
SOR MUST DEMONSTRATE THAT THE NTCB EMPLOYS THE REFERENCE
MONITOR CONCEPT. THE SECURITY POLICY MODEL MUST BE A MODEL
FOR A REFERENCE MONITOR.
THE SECURITY POLICY MODEL FOR EACH PARTITION IMPLEMENT-
ING A REFERENCE MONITOR SHALL FULLY REPRESENT THE ACCESS
CONTROL POLICY SUPPORTED BY THE PARTITION, INCLUDING THE
DISCRETIONARY AND MANDATORY SECURITY POLICY FOR SECRECY
AND/OR INTEGRITY. FOR THE MANDATORY POLICY THE SINGLE DOMI-
NANCE RELATION FOR SENSITIVITY LABELS, INCLUDING SECRECY
AND/OR INTEGRITY COMPONENTS, SHALL BE PRECISELY DEFINED.
+ 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 specifica-
tions will in fact be trusted, that is, it will be evaluat-
able under these interpretations.
THE TERM "MODEL" IS USED IN SEVERAL DIFFERENT WAYS IN A
NETWORK CONTEXT, E.G., A "PROTOCOL REFERENCE MODEL," A "FOR-
MAL NETWORK MODEL," ETC. ONLY THE "SECURITY POLICY MODEL" IS
ADDRESSED BY THIS REQUIREMENT AND IS SPECIFICALLY INTENDED
TO MODEL THE INTERFACE, VIZ., "SECURITY PERIMETER," OF THE
REFERENCE MONITOR AND MUST MEET ALL THE REQUIREMENTS DEFINED
IN THE TCSEC. IT MUST BE SHOWN THAT ALL PARTS OF THE TCB
ARE A VALID INTERPRETATION OF THE SECURITY POLICY MODEL,
I.E., THAT THERE IS NO CHANGE TO THE SECURE STATE EXCEPT AS
REPRESENTED BY THE MODEL.
3.2 CLASS (B2): STRUCTURED PROTECTION
_ _ _____ __ __________ __________
IN CLASS (B2) NETWORK SYSTEMS, THE NTCB IS BASED
ON A CLEARLY DEFINED AND DOCUMENTED FORMAL SECU-
RITY POLICY MODEL THAT REQUIRES THE DISCRETIONARY
AND MANDATORY ACCESS CONTROL ENFORCEMENT FOUND IN
CLASS (B1) NETWORK SYSTEMS TO BE EXTENDED TO ALL
SUBJECTS AND OBJECTS IN THE NETWORK SYSTEM. IN
ADDITION, COVERT CHANNELS ARE ADDRESSED. THE NTCB
MUST BE CAREFULLY STRUCTURED INTO PROTECTION-
CRITICAL AND NON-PROTECTION-CRITICAL ELEMENTS.
THE NTCB INTERFACE IS WELL-DEFINED, AND THE NTCB
DESIGN AND IMPLEMENTATION ENABLE IT TO BE SUB-
JECTED TO MORE THOROUGH TESTING AND MORE COMPLETE
REVIEW. AUTHENTICATION MECHANISMS ARE
STRENGTHENED, TRUSTED FACILITY MANAGEMENT IS PRO-
VIDED IN THE FORM OF SUPPORT FOR SYSTEM ADMINIS-
TRATOR AND OPERATOR FUNCTIONS, AND STRINGENT CON-
FIGURATION MANAGEMENT CONTROLS ARE IMPOSED. THE
SYSTEM IS RELATIVELY RESISTANT TO PENETRATION.
THE FOLLOWING ARE MINIMAL REQUIREMENTS FOR SYSTEM
ASSIGNED A CLASS (B2) RATING.
3.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 and mandatory
requirements applicable to this class. The policy may
require data secrecy, or data integrity, or both. The pol-
icy is an access control policy having two primary com-
ponents: mandatory and discretionary. The policy shall
include a discretionary policy for protecting the informa-
tion being processed based on the authorizations of indivi-
duals, users, or groups of users. This access control pol-
icy statement shall describe the requirements on the network
to prevent or detect "reading or destroying" sensitive
information by unauthorized users or errors. The mandatory
policy must define the set of distinct sensitivity levels
that it supports. For the Class B1 or above the mandatory
policy shall be based on the labels associated with the
information that reflects its sensitivity with respect to
secrecy and/or integrity, where applicable, and labels asso-
ciated with users to reflect their authorization to access
such information. 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 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 and mandatory secrecy
policy that is enforced in the network to prevent
unauthorized users from reading the sensitive infor-
mation entrusted to the network.
DATA INTEGRITY POLICY: The network sponsor shall
define the discretionary and mandatory integrity
policy to prevent unauthorized users from modifying,
viz., writing, sensitive information. The defini-
tion of data integrity presented by the network
sponsor refers to the requirement that the informa-
tion has not been subjected to unauthorized modifi-
cation in the network. The mandatory integrity pol-
icy enforced by the NTCB cannot, in general, prevent
modification while information is being transmitted
between components. However, an integrity sensi-
tivity label may reflect the confidence that the
information has not been subjected to transmission
errors because of the protection afforded during
transmission. This requirement is distinct from the
requirement for label integrity.
+ 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.
The mandatory integrity policy (at class B1 and above)
in some architectures may be useful in supporting the link-
age between the connection oriented abstraction introduced
in the Introduction and the individual components of the
network. For example, in a key distribution center for
end-to-end encryption, a distinct integrity category may be
assigned to isolate the key generation code and data from
possible modification by other supporting processes in the
same component, such as operator interfaces and audit.
The mandatory integrity policy for some architecture
may define an integrity sensitivity label that reflects the
specific requirements for ensuring that information has not
been subject to random errors in excess of a stated limit
nor to unauthorized message stream modification (MSM) -.
The specific metric associated with an integrity sensitivity
label will generally reflect the intended applications of
the network.
3.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
_________________________
- See Voydock, Victor L. and Stephen T. Kent, "Secu-
rity Mechanisms in High-Level Network Protocols," Com-
___
puting Surveys, Vol. 15, No. 2, June 1983, pp 135-171.
______ _______
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.
There are two forms of distribution for the DAC mechan-
ism: implementing portions of the DAC in separate com-
ponents, and supporting the DAC in subjects contained within
the NTCB partition in a component. Since "the ADP system"
is understood to be "the computer network" as a whole, each
network component is responsible for enforcing security in
the mechanisms allocated to it to ensure secure implementa-
tion of the network security policy. For traditional host
systems it is frequently easy to also enforce the DAC along
with the MAC within the reference monitor, per se, although
a few approaches, such as virtual machine monitors, support
DAC outside this interface.
In contrast to the universally rigid structure of man-
datory policies (see the Mandatory Access Control section),
DAC policies tend to be very network and system specific,
with features that reflect the natural use of the system.
For networks it is common that individual hosts will impose
controls over their local users on the basis of named
individuals-much like the controls used when there is no
network connection. However, it is difficult to manage in a
centralized manner all the individuals using a large net-
work. Therefore, users on other hosts are commonly grouped
together so that the controls required by the network DAC
policy are actually based on the identity of the hosts or
other components. A gateway is an example of such a com-
ponent.
The assurance requirements are at the very heart of the
concept of a trusted system. It is the assurance that
determines if a system or network is appropriate for a given
environment, as reflected, for example, in the Environments
Guideline-. In the case of monolithic systems that have DAC
integral to the reference monitor, the assurance require-
ments for DAC are inseparable from those of the rest of the
reference monitor. For networks there is typically a much
clearer distinction due to distributed DAC. The rationale
for making the distinction in this network interpretation is
that if major trusted network components can be made signi-
ficantly easier to design and implement without reducing the
ability to meet security policy, then trusted networks will
be more easily available.
3.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.
_________________________
- Guidance for Applying the Department of Defense
________ ___ ________ ___ __________ __ _______
Trusted Computer System Evaluation Criteria in Specific
_______ ________ ______ __________ ________ __ ________
Environments, CSC-STD-003-85.
____________
+ 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.
3.2.1.3 Labels
+ Statement from DoD 5200.28-STD
Sensitivity labels associated with each ADP SYSTEM RESOURCE
(E.G., SUBJECT, STORAGE OBJECT, ROM) THAT IS DIRECTLY OR
INDIRECTLY ACCESSIBLE BY SUBJECTS EXTERNAL TO THE TCB shall
be maintained by the TCB. These labels shall be used as the
basis for mandatory access control decisions. In order to
import non-labeled data, the TCB shall request and receive
from an authorized user the sensitivity level of the data,
and all such actions shall be auditable by the TCB.
+ Interpretation
Non-labeled data imported under the control of the NTCB
partition will be assigned a label constrained by THE DEVICE
LABELS OF the single-level device used to import it. Labels
may include secrecy and integrity- components in accordance
with the overall network security policy described by the
network sponsor. Whenever the term "label" is used
throughout this interpretation, it is understood to include
both components as applicable. Similarly, the terms
"single-level" and "multilevel" are understood to be based
_________________________
- See, for example, Biba, K.J., "Integrity Considera-
tion for Secure Computer Systems," ESD-TR-76-372, MTR-
3153, The MITRE Corporation, Bedford, MA, April 1977.
on both the secrecy and integrity components of the policy.
The mandatory integrity policy will typically have require-
ments, such as the probability of undetected message stream
modification, that will be reflected in the label for the
data so protected. For example, when data is imported its
integrity label may be assigned based on mechanisms, such as
cryptography, used to provide the assurance required by the
policy. The NTCB shall assure that such mechanism are pro-
tected from tampering and are always invoked when they are
the basis for a label.
IF THE SECURITY POLICY INCLUDES AN INTEGRITY POLICY,
ALL ACTIVITIES THAT RESULT IN MESSAGE-STREAM MODIFICATION
DURING TRANSMISSION ARE REGARDED AS UNAUTHORIZED ACCESSES IN
VIOLATION OF THE INTEGRITY POLICY. THE NTCB SHALL HAVE AN
AUTOMATED CAPABILITY FOR TESTING, DETECTING, AND REPORTING
THOSE ERRORS/CORRUPTIONS THAT EXCEED SPECIFIED NETWORK
INTEGRITY POLICY REQUIREMENTS. MESSAGE-STREAM MODIFICATION
(MSM) COUNTERMEASURES SHALL BE IDENTIFIED. A TECHNOLOGY OF
ADEQUATE STRENGTH SHALL BE SELECTED TO RESIST MSM. IF
ENCRYPTION METHODOLOGIES ARE EMPLOYED, THEY SHALL BE
APPROVED BY THE NATIONAL SECURITY AGENCY.
ALL OBJECTS MUST BE LABELED WITHIN EACH COMPONENT OF
THE NETWORK THAT IS TRUSTED TO MAINTAIN SEPARATION OF MULTI-
PLE LEVELS OF INFORMATION. THE LABEL ASSOCIATED WITH ANY
OBJECTS ASSOCIATED WITH SINGLE-LEVEL COMPONENTS WILL BE
IDENTICAL TO THE LEVEL OF THAT COMPONENT. OBJECTS USED TO
STORE NETWORK CONTROL INFORMATION, AND OTHER NETWORK STRUC-
TURES, SUCH AS ROUTING TABLES, MUST BE LABELED TO PREVENT
UNAUTHORIZED ACCESS AND/OR MODIFICATION.
+ Rationale
The interpretation is an extension of the requirement
into the context of a network system and partitioned NTCB as
defined for these network interpretations. A single-level
device may be regarded either as a subject or an object. A
multilevel device is regarded as a trusted subject in which
the security range of the subject is the minimum-maximum
range of the data expected to be transmitted over the dev-
ice.
The sensitivity labels for either secrecy or integrity
or both may reflect non-hierarchical categories or hierarch-
ical classification or both.
FOR A NETWORK IT IS NECESSARY THAT THIS REQUIREMENT BE
APPLIED TO ALL NETWORK SYSTEM RESOURCES AT THE (B2) LEVEL
AND ABOVE.
THE NTCB IS RESPONSIBLE FOR IMPLEMENTING THE NETWORK
INTEGRITY POLICY, WHEN ONE EXISTS. THE NTCB MUST ENFORCE
THAT POLICY BY ENSURING THAT INFORMATION IS ACCURATELY
TRANSMITTED FROM SOURCE TO DESTINATION (REGARDLESS OF THE
NUMBER OF INTERVENING CONNECTING POINTS). THE NTCB MUST BE
ABLE TO COUNTER EQUIPMENT FAILURE, ENVIRONMENTAL DISRUP-
TIONS, AND ACTIONS BY PERSONS AND PROCESSES NOT AUTHORIZED
TO ALTER THE DATA. PROTOCOLS THAT PERFORM CODE OR FORMAT
CONVERSION SHALL PRESERVE THE INTEGRITY OF DATA AND CONTROL
INFORMATION.
THE PROBABILITY OF AN UNDETECTED TRANSMISSION ERROR MAY
BE SPECIFIED AS PART OF THE NETWORK SECURITY POLICY SO THAT
THE ACCEPTABILITY OF THE NETWORK FOR ITS INTENDED APPLICA-
TION MAY BE DETERMINED. THE SPECIFIC METRICS (E.G., PROBA-
BILITY OF UNDETECTED MODIFICATION) SATISFIED BY THE DATA CAN
BE REFLECTED IN THE INTEGRITY SENSITIVITY LABEL ASSOCIATED
WITH THE DATA WHILE IT IS PROCESSED WITHIN A COMPONENT. IT
IS RECOGNIZED THAT DIFFERENT APPLICATIONS AND OPERATIONAL
ENVIRONMENTS (E.G., CRISIS AS COMPARED TO LOGISTIC) WILL
HAVE DIFFERENT INTEGRITY REQUIREMENTS.
THE NETWORK SHALL ALSO HAVE AN AUTOMATED CAPABILITY OF
TESTING FOR, DETECTING, AND REPORTING ERRORS THAT EXCEED A
THRESHOLD CONSISTENT WITH THE OPERATIONAL MODE REQUIREMENTS.
THE EFFECTIVENESS OF INTEGRITY COUNTERMEASURES MUST BE ESTA-
BLISHED WITH THE SAME RIGOR AS THE OTHER SECURITY-RELEVANT
PROPERTIES SUCH AS SECRECY.
CRYPTOGRAPHY IS OFTEN UTILIZED AS A BASIS TO PROVIDE
DATA INTEGRITY ASSURANCE. MECHANISMS, SUCH AS MANIPULATION
DETECTION CODES (MDC)-, MAY BE USED. THE ADEQUACY OF THE
ENCRYPTION OR MDC ALGORITHM, THE CORRECTNESS OF THE PROTOCOL
LOGIC, AND THE ADEQUACY OF IMPLEMENTATION MUST BE ESTA-
BLISHED IN MSM COUNTERMEASURES DESIGN.
3.2.1.3.1 Label Integrity
+ Statement from DoD 5200.28-STD
Sensitivity labels shall accurately represent sensitivity
levels of the specific subjects or objects with which they
are associated. When exported by the TCB, sensitivity
labels shall accurately and unambiguously represent the
internal labels and shall be associated with the information
being exported.
+ Interpretation
The phrase "exported by the TCB" is understood to
include transmission of information from an object in one
component to an object in another component. Information
transferred between NTCB partitions is addressed in the Sys-
tem Integrity Section. The form of internal and external
(exported) sensitivity labels may differ, but the meaning
shall be the same. The NTCB shall, in addition, ensure that
_________________________
- See Jueneman, R. R., "Electronic Document Authenti-
cation," IEEE Network Magazine, April 1987, pp 17-23.
____ _______ ________
correct association of sensitivity labels with the informa-
tion being transported across the network is preserved.
As mentioned in the Trusted Facility Manual Section,
encryption transforms the representation of information so
that it is unintelligible to unauthorized subjects.
Reflecting this transformation, the sensitivity level of the
ciphertext is generally lower than the cleartext. It fol-
lows that cleartext and ciphertext are contained in dif-
ferent objects, each possessing its own label. The label of
the cleartext must be preserved and associated with the
ciphertext so that it can be restored when the cleartext is
subsequently obtained by decrypting the ciphertext. If the
cleartext is associated with a single-level device, the
label of that cleartext may be implicit. The label may also
be implicit in the key.
When information is exported to an environment where it
is subject to deliberate or accidental modification, the TCB
shall support the means, such as cryptographic checksums, to
assure the accuracy of the labels. When there is a manda-
tory integrity policy, the policy will define the meaning of
integrity labels.
+ Rationale
Encryption algorithms and their implementation are out-
side the scope of these interpretations. Such algorithms
may be implemented in a separate device or may be incor-
porated in a subject of a larger component. Without preju-
dice, either implementation packaging is referred to as an
encryption mechanism herein. If encryption methodologies are
employed in this regard, they shall be approved by the
National Security Agency (NSA). The encryption process is
part of the Network Trusted Computer Base partition in the
components in which it is implemented.
The encryption mechanism is not necessarily a mul-
tilevel device or multilevel subject, as these terms are
used in these criteria. The process of encryption is mul-
tilevel by definition. The cleartext and ciphertext inter-
faces carry information of different sensitivity. An
encryption mechanism does not process data in the sense of
performing logical or arithmetic operations on that data
with the intent of producing new data. The cleartext and
ciphertext interfaces on the encryption mechanism must be
separately identified as being single-level or multilevel.
If the interface is single-level, then the sensitivity of
the data is established by a trusted individual and impli-
citly associated with the interface; the Exportation to
Single-Level Devices criterion applies.
If the interface is multilevel, then the data must be
labeled; the Exportation to Multilevel Devices criterion
applies. The network architect is free to select an accept-
able mechanism for associating a label with an object. With
reference to encrypted objects, the following examples are
possible:
1. Include a label field in the protocol definition of
the object.
2. Implicitly associate the label with the object
through the encryption key. That is, the encryption
key uniquely identifies a sensitivity level. A sin-
gle or private key must be protected at the level of
the data that it encrypts.
3.2.1.3.2 Exportation of Labeled Information
+ Statement from DoD 5200.28-STD
The TCB shall designate each communication channel and I/O
device as either single-level or multilevel. Any change in
this designation shall be done manually and shall be audit-
able by the TCB. The TCB shall maintain and be able to
audit any change in the sensitivity level or levels associ-
ated with a communications channel or I/O device.
+ Interpretation
Each communication channel and network component shall
be designated as either single-level or multilevel. Any
change in this designation shall be done with the cognizance
and approval of the administrator or security officer in
charge of the affected components and the administrator or
security officer in charge of the NTCB. This change shall
be auditable by the network. The NTCB shall maintain and be
able to audit any change in the DEVICE LABELS associated
with a single-level communication channel or the range asso-
ciated with a multilevel communication channel or component.
The NTCB shall also be able to audit any change in the set
of sensitivity levels associated with the information which
can be transmitted over a multilevel communication channel
or component.
+ Rationale
Communication channels and components in a network are
analogous to communication channels and I/O devices in
stand-alone systems. They must be designated as either mul-
tilevel (i.e., able to distinguish and maintain separation
among information of various sensitivity levels) or single-
level. As in the TCSEC, single-level devices may only be
attached to single-level channels.
The level or set of levels of information that can be
sent to a component or over a communication channel shall
only change with the knowledge and approval of the security
officers (or system administrator, if there is no security
officer) of the network, and of the affected components.
This requirement ensures that no significant security-
relevant changes are made without the approval of all
affected parties.
3.2.1.3.2.1 Exportation to Multilevel Devices
+ Statement from DoD 5200.28-STD
When the TCB exports an object to a multilevel I/O device,
the sensitivity label associated with that object shall also
be exported and shall reside on the same physical medium as
the exported information and shall be in the same form
(i.e., machine-readable or human-readable form). When the
TCB exports or imports an object over a multilevel communi-
cations channel, the protocol used on that channel shall
provide for the unambiguous pairing between the sensitivity
labels and the associated information that is sent or
received.
+ Interpretation
The components, including hosts, of a network shall be
interconnected over "multilevel communication channels,"
multiple single-level communication channels, or both, when-
ever the information is to be protected at more than a sin-
gle sensitivity level. The protocol for associating the
sensitivity label and the exported information shall provide
the only information needed to correctly associate a sensi-
tivity level with the exported information transferred over
the multilevel channel between the NTCB partitions in indi-
vidual components. This protocol definition must specify the
representation and semantics of the sensitivity labels
(i.e., the machine-readable label must uniquely represent
the sensitivity level).
The "unambiguous" association of the sensitivity level
with the communicated information shall meet the same level
of accuracy as that required for any other label within the
NTCB, as specified in the criterion for Label Integrity.
This may be provided by protected and highly reliable direct
physical layer connections, or by traditional cryptographic
link protection in which any errors during transmission can
be readily detected, or by use of a separate channel. THE
RANGE OF INFORMATION IMPORTED OR EXPORTED MUST BE CON-
STRAINED BY THE ASSOCIATED DEVICE LABELS.
+ Rationale
This protocol must specify the representation and
semantics of the sensitivity labels. See the Mandatory
Access Control Policies section in Appendix B. The mul-
tilevel device interface to (untrusted) subjects may be
implemented either by the interface of the reference moni-
tor, per se, or by a multilevel subject (e.g., a "trusted
subject" as defined in the Bell-LaPadula Model) that pro-
vides the labels based on the internal labels of the NTCB
partition.
The current state of the art limits the support for
mandatory policy that is practical for secure networks.
Reference monitor support to ensure the control over all the
operations of each subject in the network must be completely
provided within the single NTCB partition on which that sub-
ject interfaces to the NTCB. This means that the entire
portion of the "secure state" represented in the FORMAL
security policy model that may be changed by transitions
invoked by this subject must be contained in the same com-
ponent.
The secure state of an NTCB partition may be affected
by events external to the component in which the NTCB parti-
tion resides (e.g., arrival of a message). The effect
occurs asynchronusly after being initiated by an event in
another component or partition. For example, indeterminate
delays may occur between the initiation of a message in one
component, the arrival of the message in the NTCB partition
in another component, and the corresponding change to the
secure state of the second component. Since each component
is executing concurrently, to do otherwise would require
some sort of network-wide control to synchronize state tran-
sitions, such as a global network-wide clock for all proces-
sors; in general, such designs are not practical and prob-
ably not even desirable. Therefore, the interaction between
NTCB partitions is restricted to just communications between
pairs (at least logically) of devices-multilevel devices if
the device(s) can send/receive data of more than a single
level. For broadcast channels the pairs are the sender and
intended receiver(s). However, if the broadcast channel
carries multiple levels of information, additional mechanism
(e.g., cryptochecksum maintained by the TCB) may be required
to enforce separation and proper delivery.
A common representation for sensitivity labels is
needed in the protocol used on that channel and understood
by both the sender and receiver when two multilevel devices
(in this case, in two different components) are intercon-
nected. Each distinct sensitivity level of the overall net-
work policy must be represented uniquely in these labels.
Within a monolithic TCB, the accuracy of the sensi-
tivity labels is generally assured by simple techniques,
e.g., very reliable connections over very short physical
connections, such as on a single printed circuit board or
over an internal bus. In many network environments there is
a much higher probability of accidentally or maliciously
introduced errors, and these must be protected against.
3.2.1.3.2.2 Exportation to Single-Level Devices
+ Statement from DoD 5200.28-STD
Single-level I/O devices and single-level communication
channels are not required to maintain the sensitivity labels
of the information they process. However, the TCB shall
include a mechanism by which the TCB and an authorized user
reliably communicate to designate the single sensitivity
level of information imported or exported via single-level
communication channels or I/O devices.
+ Interpretation
Whenever one or both of two directly connected com-
ponents is not trusted to maintain the separation of infor-
mation of different sensitivity levels, or whenever the two
directly connected components have only a single sensitivity
level in common, the two components of the network shall
communicate over a single-level channel. Single-level com-
ponents and single-level communication channels are not
required to maintain the sensitivity labels of the informa-
tion they process. However, the NTCB shall include a reli-
able communication mechanism by which the NTCB and an
authorized user (VIA A TRUSTED PATH) or a subject within an
NTCB partition can designate the single sensitivity level of
information imported or exported via single-level communica-
tion channels or network components. THE LEVEL OF INFORMA-
TION COMMUNICATED MUST EQUAL THE DEVICE LEVEL.
+ Rationale
Single-level communications channels and single-level
components in networks are analogous to single level chan-
nels and I/O devices in stand-alone systems in that they are
not trusted to maintain the separation of information of
different sensitivity levels. The labels associated with
data transmitted over those channels and by those components
are therefore implicit; the NTCB associates labels with the
data because of the channel or component, not because of an
explicit part of the bit stream. Note that the sensitivity
level of encrypted information is the level of the cipher-
text rather than the original level(s) of the plaintext.
3.2.1.3.2.3 Labeling Human-Readable Output
+ Statement from DoD 5200.28-STD
The ADP system administrator shall be able to specify the
printable label names associated with exported sensitivity
labels. The TCB shall mark the beginning and end of all
human-readable, paged, hardcopy output (e.g., line printer
output) with human-readable sensitivity labels that prop-
erly1 represent the sensitivity of the output. The TCB
shall, by default, mark the top and bottom of each page of
human-readable, paged, hardcopy output (e.g., line printer
output) with human-readable sensitivity labels that prop-
erly1 represent the sensitivity of the page. The TCB shall,
by default and in an appropriate manner, mark other forms of
human readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly1 represent the
sensitivity of the output. Any override of these markings
defaults shall be auditable by the TCB.
_________________________
1 The hierarchical classification component in human-readable
sensitivity labels shall be equal to the greatest hierarchical
classification of any of the information in the output that the
labels refer to; the non-hierarchical category component shall
include all of the non-hierarchical categories of the information
in the output the labels refer to, but to no other non-
hierarchical categories.
+ Interpretation
This criterion imposes no requirement to a component
that produces no human-readable output. For those that do
produce human-readable output, each sensitivity level that
is defined to the network shall have a uniform meaning
across all components. The network administrator, in con-
junction with any affected component administrator, shall be
able to specify the human-readable label that is associated
with each defined sensitivity level.
+ Rationale
The interpretation is a straightforward extension of
the requirement into the context of a network system and
partitioned NTCB as defined for these network interpreta-
tions.
3.2.1.3.3 Subject Sensitivity Labels
+ Statement from DoD 5200.28-STD
THE TCB SHALL IMMEDIATELY NOTIFY A TERMINAL USER OF EACH
CHANGE IN THE SENSITIVITY LEVEL ASSOCIATED WITH THAT USER
DURING AN INTERACTIVE SESSION. A TERMINAL USER SHALL BE
ABLE TO QUERY THE TCB AS DESIRED FOR A DISPLAY OF THE
SUBJECT'S COMPLETE SENSITIVITY LABEL.
+ Interpretation
AN NTCB PARTITION SHALL IMMEDIATELY NOTIFY A TERMINAL
USER ATTACHED TO ITS COMPONENT OF EACH CHANGE IN THE SENSI-
TIVITY LEVEL ASSOCIATED WITH THAT USER.
+ Rationale
THE LOCAL NTCB PARTITION MUST ENSURE THAT THE USER
UNDERSTANDS THE SENSITIVITY LEVEL OF INFORMATION SENT TO AND
FROM A TERMINAL. WHEN A USER HAS A SURROGATE PROCESS IN
ANOTHER COMPONENT, ADJUSTMENTS TO ITS LEVEL MAY OCCUR TO
MAINTAIN COMMUNICATION WITH THE USER. THESE CHANGES MAY
OCCUR ASYNCHRONOUSLY. SUCH ADJUSTMENTS ARE NECESSITATED BY
MANDATORY ACCESS CONTROL AS APPLIED TO THE OBJECTS INVOLVED
IN THE COMMUNICATION PATH.
3.2.1.3.4 Device Labels
+ Statement from DoD 5200.28-STD
THE TCB SHALL SUPPORT THE ASSIGNMENT OF MINIMUM AND MAXIMUM
SENSITIVITY LEVELS TO ALL ATTACHED PHYSICAL DEVICES. THESE
SENSITIVITY LEVELS SHALL BE USED BY THE TCB TO ENFORCE CON-
STRAINTS IMPOSED BY THE PHYSICAL ENVIRONMENTS IN WHICH THE
DEVICES ARE LOCATED.
+ Interpretation
THIS REQUIREMENT APPLIES AS WRITTEN TO EACH NTCB PARTI-
TION THAT IS TRUSTED TO SEPARATE INFORMATION BASED ON SENSI-
TIVITY LEVEL. EACH I/O DEVICE IN A COMPONENT, USED FOR COM-
MUNICATION WITH OTHER NETWORK COMPONENTS, IS ASSIGNED A DEV-
ICE RANGE, CONSISTING OF A SET OF LABELS WITH A MAXIMUM AND
MINIMUM. (A DEVICE RANGE USUALLY CONTAINS, BUT DOES NOT
NECESSARILY CONTAIN, ALL POSSIBLE LABELS "BETWEEN" THE MAX-
IMUM AND MINIMUM, IN THE SENSE OF DOMINATING THE MINIMUM AND
BEING DOMINATED BY THE MAXIMUM.)
THE NTCB ALWAYS PROVIDES AN ACCURATE LABEL FOR INFORMA-
TION EXPORTED THROUGH DEVICES. INFORMATION EXPORTED OR
IMPORTED USING A SINGLE-LEVEL DEVICE IS LABELLED IMPLICITLY
BY THE SENSITIVITY LEVEL OF THE DEVICE. INFORMATION
EXPORTED FROM ONE MULTILEVEL DEVICE AND IMPORTED AT ANOTHER
MUST BE LABELLED THROUGH AN AGREED-UPON PROTOCOL, UNLESS IT
IS LABELLED IMPLICITLY BY USING A COMMUNICATION LINK THAT
ALWAYS CARRIES A SINGLE LEVEL.
INFORMATION EXPORTED AT A GIVEN SENSITIVITY LEVEL CAN
BE SENT ONLY TO AN IMPORTING DEVICE WHOSE DEVICE RANGE CON-
TAINS THAT LEVEL OR A HIGHER LEVEL. IF THE IMPORTING DEVICE
RANGE DOES NOT CONTAIN THE GIVEN LEVEL, THE INFORMATION IS
RELABELLED UPON RECEPTION AT A HIGHER LEVEL WITHIN THE
IMPORTING DEVICE RANGE. RELABELLING SHOULD NOT OCCUR OTHER-
WISE.
+ Rationale
THE PURPOSE OF DEVICE LABELS IS TO REFLECT AND CON-
STRAIN THE SENSITIVITY LEVELS OF INFORMATION AUTHORIZED FOR
THE PHYSICAL ENVIRONMENT IN WHICH THE DEVICES ARE LOCATED.
THE INFORMATION TRANSFER RESTRICTIONS PERMIT ONE-WAY
COMMUNICATION (I.E., NO ACKNOWLEDGEMENTS) FROM ONE DEVICE TO
ANOTHER WHOSE RANGES HAVE NO LEVEL IN COMMON, AS LONG AS
EACH LEVEL IN THE SENDING DEVICE RANGE IS DOMINATED BY SOME
LEVEL IN THE RECEIVING DEVICE RANGE. IT IS NEVER PERMITTED
TO SEND INFORMATION AT A GIVEN LEVEL TO A DEVICE WHOSE RANGE
DOES NOT CONTAIN A DOMINATING LEVEL. (SEE APPENDIX C FOR
SIMILAR INTERCONNECTION RULES FOR THE INTERCONNECTED AIS
VIEW.)
3.2.1.4 Mandatory Access Control
+ Statement from DoD 5200.28-STD
The TCB shall enforce a mandatory access control policy over
all RESOURCES (I.E., SUBJECTS, STORAGE OBJECTS, AND I/O DEV-
ICES) THAT ARE DIRECTLY OR INDIRECTLY ACCESSIBLE BY SUBJECTS
EXTERNAL TO THE TCB. These subjects and objects shall be
assigned sensitivity labels that are a combination of
hierarchical classification levels and non-hierarchical
categories, and the labels shall be used as the basis for
mandatory access control decisions. The TCB shall be able
to support two or more such sensitivity levels. (See the
Mandatory Access Control interpretations.) The following
requirements shall hold for all accesses between ALL SUB-
JECTS EXTERNAL TO THE TCB AND ALL OBJECTS DIRECTLY OR
INDIRECTLY ACCESSIBLE BY THESE SUBJECTS. A subject can
read an object only if the hierarchical classification in
the subject's sensitivity level is greater than or equal to
the hierarchical classification of the object's sensitivity
level and the non-hierarchical categories in the subject's
sensitivity level include all the non-hierarchical
categories in the object's sensitivity level. A subject can
write an object only if the hierarchical classification in
the subject's sensitivity level is less than or equal to the
hierarchical classification of the object's sensitivity
level and the non-hierarchical categories in the subject's
sensitivity level are included in the non-hierarchical
categories in the object's sensitivity level. Identification
and authentication data shall be used by the TCB to authen-
ticate the user's identity and to ensure that the sensi-
tivity level and authorization of subjects external to the
TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of
that user.
+ Interpretation
Each partition of the NTCB exercises mandatory access
control policy over all subjects and objects in its COM-
PONENT. In a network, the responsibility of an NTCB parti-
tion encompasses all mandatory access control functions in
its component that would be required of a TCB in a stand-
alone system. In particular, subjects and objects used for
communication with other components are under the control of
the NTCB partition. Mandatory access control includes
secrecy and integrity control to the extent that the network
sponsor has described in the overall network security pol-
icy.
Conceptual entities associated with communication
between two components, such as sessions, connections and
virtual circuits, may be thought of as having two ends, one
in each component, where each end is represented by a local
object. Communication is viewed as an operation that copies
information from an object at one end of a communication
path to an object at the other end. Transient data-carrying
entities, such as datagrams and packets, exist either as
information within other objects, or as a pair of objects,
one at each end of the communication path.
The requirement for "two or more" sensitivity levels
can be met by either secrecy or integrity levels. When
there is a mandatory integrity policy, the stated require-
ments for reading and writing are generalized to: A subject
can read an object only if the subject's sensitivity level
dominates the object's sensitivity level, and a subject can
write an object only if the object's sensitivity level dom-
inates the subject's sensitivity level. Based on the
integrity policy, the network sponsor shall define the domi-
nance relation for the total label, for example, by combin-
ing secrecy and integrity lattices. -
+ Rationale
An NTCB partition can maintain access control only over
subjects and objects in its component. AT LEVELS B2 AND
ABOVE, THE NTCB PARTITION MUST MAINTAIN ACCESS CONTROL OVER
ALL SUBJECTS AND OBJECTS IN ITS COMPONENT. Access by a sub-
ject in one component to information contained in an object
in another component requires the creation of a subject in
the remote component which acts as a surrogate for the first
subject.
The mandatory access controls must be enforced at the
interface of the reference monitor (viz. the mechanism that
controls physical processing resources) for each NTCB parti-
tion. This mechanism creates the abstraction of subjects
and objects which it controls. Some of these subjects out-
side the reference monitor, per se, may be designated to
implement part of an NTCB partition's mandatory policy,
e.g., by using the ``trusted subjects" defined in the Bell-
LaPadula model.
The prior requirements on exportation of labeled infor-
mation to and from I/O devices ensure the consistency
between the sensitivity labels of objects connected by a
communication path. As noted in the introduction, the net-
work architecture must recognize the linkage between the
overall mandatory network security policy and the connection
oriented abstraction. For example, individual data-carrying
entities such as datagrams can have individual sensitivity
labels that subject them to mandatory access control in each
component. The abstraction of a single-level connection is
realized and enforced implicitly by an architecture while a
connection is realized by single-level subjects that neces-
sarily employ only datagrams of the same level.
The fundamental trusted systems technology permits the
DAC mechanism to be distributed, in contrast to the require-
ments for mandatory access control. For networks this
separation of MAC and DAC mechanisms is the rule rather than
_________________________
- See, for example, Grohn, M. J., A Model of a Pro-
_ _____ __ _ ___
tected Data Management System, ESD-TR-76-289, I. P.
______ ____ __________ ______
Sharp Assoc. Ltd., June, 1976; and Denning, D .E.,
Lunt, T. F., Neumann, P. G., Schell, R. R., Heckman, M.
and Shockley, W., Secure Distributed Data Views, Secu-
______ ___________ ____ _____ ____
rity Policy and Interpretation for a Class A1 Multilev-
____ ______ ___ ______________ ___ _ _____ __ ________
el Secure Relational Database System,SRI International,
__ ______ __________ ________ ______
November 1986.
the exception.
The set of total sensitivity labels used to represent
all the sensitivity levels for the mandatory access control
(combined data secrecy and data integrity) policy always
forms a partially ordered set. Without loss of generality,
this set of labels can always be extended to form a lattice,
by including all the combinations of non-hierarchical
categories. As for any lattice, a dominance relation is
always defined for the total sensitivity labels. For admin-
istrative reasons it may be helpful to have a maximum level
which dominates all others.
3.2.2 Accountability
_ _ _ ______________
3.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 maintain
authentication data that includes information for verifying
the identify of individual users (e.g., passwords) as well
as information for determining the clearance and authoriza-
tions of individual users. This data shall be used by the
TCB to authenticate the user's identity and to ensure that
the sensitivity level and authorization of subjects external
to the TCB that may be created to act on behalf of the indi-
vidual user are dominated by the clearance and authorization
of that user. 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
_________________________
= Department of Defense Password Management Guide-
__________ __ _______ ________ __________ _____
line, CSC-STD-002-85
____
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.
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. If the authenticated identification is used as the
basis of determining a sensitivity label for a subject, it
must satisfy the Label Integrity criterion.
An authenticated identification may be forwarded
between components and employed in some component to iden-
tify the sensitivity level associated with a subject created
to act on behalf of the user so identified.
3.2.2.1.1 Trusted Path
+ Statement from DoD 5200.28-STD
THE TCB SHALL SUPPORT A TRUSTED COMMUNICATION PATH BETWEEN
ITSELF AND USER FOR INITIAL LOGIN AND AUTHENTICATION. COM-
MUNICATIONS VIA THIS PATH SHALL BE INITIATED EXCLUSIVELY BY
A USER.
+ Interpretation
A TRUSTED PATH IS SUPPORTED BETWEEN A USER (I.E.,
HUMAN) AND THE NTCB PARTITION IN THE COMPONENT TO WHICH THE
USER IS DIRECTLY CONNECTED.
+ Rationale
WHEN A USER LOGS INTO A REMOTE COMPONENT, THE USER ID
IS TRANSMITTED SECURELY BETWEEN THE LOCAL AND REMOTE NTCB
PARTITIONS IN ACCORDANCE WITH THE REQUIREMENTS IN IDENTIFI-
CATION AND AUTHENTICATION.
TRUSTED PATH IS NECESSARY IN ORDER TO ASSURE THAT THE
USER IS COMMUNICATING WITH THE NTCB AND ONLY THE NTCB WHEN
SECURITY RELEVANT ACTIVITIES ARE TAKING PLACE (E.G., AUTHEN-
TICATE USER, SET CURRENT SESSION SENSITIVITY LEVEL). HOW-
EVER, TRUSTED PATH DOES NOT ADDRESS COMMUNICATIONS WITHIN
THE NTCB, ONLY COMMUNICATIONS BETWEEN THE USER AND THE NTCB.
IF, THEREFORE, A COMPONENT DOES NOT SUPPORT ANY DIRECT USER
COMMUNICATION THEN THE COMPONENT NEED NOT CONTAIN MECHANISMS
FOR ASSURING DIRECT NTCB TO USER COMMUNICATIONS.
THE REQUIREMENT FOR TRUSTED COMMUNICATION BETWEEN ONE
NTCB PARTITION AND ANOTHER NCTB PARTITION IS ADDRESSED IN
THE SYSTEM ARCHITECTURE SECTION. THESE REQUIREMENTS ARE
SEPARATE AND DISTINCT FROM THE USER TO NTCB COMMUNICATION
REQUIREMENT OF A TRUSTED PATH. HOWEVER, IT IS EXPECTED THAT
THIS TRUSTED COMMUNICATION BETWEEN ONE NTCB PARTITION AND
ANOTHER NTCB PARTITION WILL BE USED IN CONJUNCTION WITH THE
TRUSTED PATH TO IMPLEMENT TRUSTED COMMUNICATION BETWEEN THE
USER AND THE REMOTE NTCB PARTITION.
3.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. The TCB shall also be able to audit any override of
human-readable output markings. 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 and the object's
sensitivity level. The ADP system administrator shall be
able to selectively audit the actions of any one or more
users based on individual identify and/or object sensitivity
level. THE TCB SHALL BE ABLE TO AUDIT THE IDENTIFIED
EVENTS THAT MAY BE USED IN THE EXPLOITATION OF COVERT
STORAGE CHANNELS.
+ 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.
THE CAPABILITY MUST EXIST TO AUDIT THE IDENTIFIED
EVENTS THAT MAY BE USED IN THE EXPLOITATION OF COVERT
STORAGE CHANNELS. TO ACCOMPLISH THIS, EACH NTCB PARTITION
MUST BE ABLE TO AUDIT THOSE EVENTS LOCALLY THAT MAY LEAD TO
THE EXPLOITATION OF A COVERT STORAGE CHANNEL WHICH EXIST
BECAUSE OF THE NETWORK.
+ 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. IDENTIFICATION OF COVERT CHANNEL
EVENTS IS ADDRESSED IN THE COVERT CHANNEL ANALYSIS SECTION.
3.2.3 Assurance
_ _ _ _________
3.2.3.1 Operational Assurance
3.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). THE TCB
SHALL MAINTAIN PROCESS ISOLATION THROUGH THE PROVISION OF
DISTINCT ADDRESS SPACES UNDER ITS CONTROL. THE TCB SHALL BE
INTERNALLY STRUCTURED INTO WELL-DEFINED LARGELY INDEPENDENT
MODULES. IT SHALL MAKE EFFECTIVE USE OF AVAILABLE HARDWARE
TO SEPARATE THOSE ELEMENTS THAT ARE PROTECTION-CRITICAL FROM
THOSE THAT ARE NOT. THE TCB MODULES SHALL BE DESIGNED SUCH
THAT THE PRINCIPLE OF LEAST PRIVILEGE IS ENFORCED. FEATURES
IN HARDWARE, SUCH AS SEGMENTATION, SHALL BE USED TO SUPPORT
LOGICALLY DISTINCT STORAGE OBJECTS WITH SEPARATE ATTRIBUTES
(NAMELY: READABLE, WRITABLE). THE USER INTERFACE TO THE TCB
SHALL BE COMPLETELY DEFINED AND ALL ELEMENTS OF THE TCB
IDENTIFIED.
+ 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. Since each component is itself a dis-
tinct domain in the overall network system, this also satis-
fies the requirement for process isolation through distinct
address spaces in the special case where a component has
only a single subject.
THE NTCB MUST BE INTERNALLY STRUCTURED INTO WELL-
DEFINED LARGELY INDEPENDENT MODULES AND MEET THE HARDWARE
REQUIREMENTS. THIS IS SATISFIED BY HAVING EACH NTCB PARTI-
TION SO STRUCTURED. THE NTCB CONTROLS ALL NETWORK RESOURCES.
THESE RESOURCES 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 protected against external interference or tamper-
ing. For example, a cryptographic checksum or physical
means may be employed to protect user authentication data
exchanged between NTCB partitions.
EACH NTCB PARTITION MUST ENFORCE THE PRINCIPLE OF LEAST
PRIVILEGE WITHIN ITS COMPONENT. ADDITIONALLY, THE NTCB MUST
BE STRUCTURED SO THAT THE PRINCIPLE OF LEAST PRIVILEGE IS
ENFORCED IN THE SYSTEM AS A WHOLE.
Each NTCB partition provides isolation of resources
(within its component) in accord with the network system
architecture and security policy so that "supporting ele-
ments" (e.g., DAC and user identification) for the security
mechanisms of the network system are strengthened compared
to C2, from an assurance point of view, through the provi-
sion of distinct address spaces under control of the NTCB.
As discussed in the Discretionary Access Control sec-
tion, 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. When distributed in NTCB sub-
jects (i.e., when outside the reference monitor), the
assurance requirements for the design and implementation of
the DAC shall be those of class C2 for all networks of class
C2 or above.
+ Rationale
THE REQUIREMENT THAT THE NTCB BE STRUCTURED INTO
MODULES AND MEET THE HARDWARE REQUIREMENTS APPLIES WITHIN
THE NTCB PARTITIONS IN THE VARIOUS COMPONENTS.
THE PRINCIPLE OF LEAST PRIVILEGE REQUIRES THAT EACH
USER OR OTHER INDIVIDUAL WITH ACCESS TO THE SYSTEM BE GIVEN
ONLY THOSE RESOURCES AND AUTHORIZATIONS REQUIRED FOR THE
PERFORMANCE OF THIS JOB. IN ORDER TO ENFORE THIS PRINCIPLE
IN THE SYSTEM IT MUST BE ENFORCED IN EVERY NTCB PARTITION
THAT SUPPORTS USERS OR OTHER INDIVIDUALS. FOR EXAMPLE,
PROHIBITING ACCESS BY ADMINISTRATORS TO OBJECTS OUTSIDE THE
NTCB PARTITION (E.G., GAMES) LESSENS THE OPPORTUNITY OF DAM-
AGE BY A TROJAN HORSE.
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.
The provision of distinct address spaces under the con-
trol of the NTCB provides the ability to separate subjects
according to sensitivity level. This requirement is intro-
duced at B1 since it is an absolute necessity in order to
implement mandatory access controls.
3.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 mandatory and dis-
cretionary access control policy in a network may require
communication between trusted subjects that are part of the
NTCB partitions in different components. This communication
is normally 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.
3.2.3.1.3 Covert Channel Analysis
+ Statement from DoD 5200.28-STD
THE SYSTEM DEVELOPER SHALL CONDUCT A THOROUGH SEARCH FOR
COVERT STORAGE CHANNELS AND MAKE A DETERMINATION (EITHER BY
ACTUAL MEASUREMENT OR BY ENGINEERING ESTIMATION) OF THE MAX-
IMUM BANDWIDTH OF EACH IDENTIFIED CHANNEL. (SEE THE COVERT
CHANNELS GUIDELINE SECTION.)
+ Interpretation
THE REQUIREMENT, INCLUDING THE TCSEC COVERT CHANNEL
GUIDELINE, APPLIES AS WRITTEN. IN A NETWORK, THERE ARE
ADDITIONAL INSTANCES OF COVERT CHANNELS ASSOCIATED WITH COM-
MUNICATION BETWEEN COMPONENTS.
+ Rationale
THE EXPLOITATION OF NETWORK PROTOCOL INFORMATION (E.G.,
HEADERS) CAN RESULT IN COVERT STORAGE CHANNELS. THE TOPIC
HAS BEEN ADDRESSED IN THE LITERATURE.-
_________________________
- See, for example, Girling, C. G., "Covert Channels
in LAN's," IEEE Transactions on Software Engineering,
____ ____________ __ ________ ___________
Vol. SE-13, No. 2, February 1987; and Padlipsky, M. A.,
Snow, D. P., and Karger, P. A., Limitations of End-to-
___________ __ ___ __
End Encryption in Secure Computer Networks, MITRE
___ __________ __ ______ ________ ________
Technical Report, MTR-3592, Vol. I, May 1978 (ESD TR
3.2.3.1.4 Trusted Facility Management
+ Statement from DoD 5200.28-STD
THE TCB SHALL SUPPORT SEPARATE OPERATOR AND ADMINISTRATOR
FUNCTIONS.
+ Interpretation
THIS REQUIREMENT APPLIES AS WRITTEN TO BOTH THE NETWORK
AS A WHOLE AND TO INDIVIDUAL COMPONENTS WHICH SUPPORT SUCH
PERSONNEL.
+ Rationale
IT IS RECOGNIZED THAT BASED ON THE ALLOCATED POLICY
ELEMENTS SOME COMPONENTS MAY OPERATE WITH NO HUMAN INTER-
FACE.
3.2.3.2 Life-Cycle Assurance
3.2.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. A
team of individuals who thoroughly understand the specific
implementation of the TCB shall subject its design documen-
tation, source code, and object code to through analysis and
testing. Their objectives shall be: to uncover all design
and implementation flaws that would permit a subject exter-
nal to the TCB to read, change, or delete data normally
denied under the mandatory or discretionary security policy
enforced by the TCB; as well as to assure that no subject
(without authorization to do so) is able to cause the TCB to
enter a state such that it is unable to respond to communi-
cations initiated by other users. THE TCB SHALL BE FOUND
RELATIVELY RESISTANT TO PENETRATION. All discovered flaws
shall be removed or neutralized and the TCB retested to
demonstrate that they have been eliminated and that new
flaws have not been introduced. TESTING SHALL DEMONSTRATE
THAT THE TCB IMPLEMENTATION IS CONSISTENT WITH THE DESCRIP-
TIVE TOP-LEVEL SPECIFICATION. (See the Security Testing
Guidelines.)
+ Interpretation
Testing of a component will require a testbed that
exercises the interfaces and protocols of the component
including tests under exceptional conditions. 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 partition that
implement the given mechanism. This integrated testing is
additional to any individual component tests involved in the
evaluation of the network system. The sponsor should iden-
tify 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 configura-
tions. A change in configuration within the allowable set
of configurations does not require retesting.
The testing of each component will include the intro-
duction of subjects external to the NTCB partition for the
component that will attempt to read, change, or delete data
normally denied. If the normal interface to the component
does not provide a means to create the subjects needed to
conduct such a test, then this portion of the testing shall
use a special version of the untrusted software for the com-
ponent that results in subjects that make such attempts.
The results shall be saved for test analysis. Such special
versions shall have an NTCB partition that is identical to
that for the normal configuration of the component under
evaluation.
The testing of the mandatory controls shall include
tests to demonstrate that the labels for information
imported and/or exported to/from the component accurately
represent the labels maintained by the NTCB partition for
the component for use as the basis for its mandatory access
control decisions. The tests shall include each type of
device, whether single-level or multilevel, supported by the
component.
THE NTCB MUST BE FOUND RELATIVELY RESISTANT TO PENETRA-
TION. THIS APPLIES TO THE NTCB AS A WHOLE, AND TO EACH NTCB
PARTITION IN A COMPONENT OF THIS CLASS.
+ Rationale
The phrase "no subject (without authorization to do so)
is able to cause the TCB to enter a state such that it is
unable to respond to communications initiated by other
users" relates to the security services (Part II of this
TNI) for the Denial of Service problem, and to correctness
of the protocol implementations.
Testing is an important method available in this
evaluation division to gain any assurance that the security
mechanisms perform their intended function. A major purpose
of testing is to demonstrate the system's response to inputs
to the NTCB partition from untrusted (and possibly mali-
cious) subjects.
In contrast to general purpose systems that allow for
the dynamic creation of new programs and the introductions
of new processes (and hence new subjects) with user speci-
fied security properities, many network components have no
method for introducing new programs and/or processes during
their normal operation. Therefore, the programs necessary
for the testing must be introduced as special versions of
the software rather than as the result of normal inputs by
the test team. However, it must be insured that the NTCB
partition used for such tests is identical to the one under
evaluation.
Sensitivity labels serve a critical role in maintaining
the security of the mandatory access controls in the net-
work. Especially important to network security is the role
of the labels for information communicated between com-
ponents - explicit labels for multilevel devices and impli-
cit labels for single-level devices. Therefore the testing
for correct labels is highlighted.
THE REQUIREMENT FOR TESTING TO DEMONSTRATE CONSISTENCY
BETWEEN THE NTCB IMPLEMENTATION AND THE DTLS IS A STRAIGHT-
FORWARD EXTENSION OF THE TCSEC REQUIREMENT INTO THE CONTEXT
OF A NETWORK SYSTEM.
3.2.3.2.2 Design Specification and Verification
+ Statement from DoD 5200.28-STD
A FORMAL model of the security policy supported by the TCB
shall be maintained over the life cycle of the ADP system
THAT IS PROVEN and demonstrated to be consistent with its
axioms. A DESCRIPTIVE TOP-LEVEL SPECIFICATION (DTLS) OF THE
TCB SHALL BE MAINTAINED THAT COMPLETELY AND ACCURATELY
DESCRIBES THE TCB IN TERMS OF EXCEPTIONS, ERROR MESSAGES,
AND EFFECTS. IT SHALL BE SHOWN TO BE AN ACCURATE DESCRIP-
TION OF THE TCB INTERFACE.
+ Interpretation
The overall network security policy expressed in this
model will provide the basis for the mandatory access con-
trol policy exercised by the NTCB over subjects and storage
objects in the entire network. The policy will also be the
basis for the discretionary access control policy exercised
by the NTCB to control access of named users to named
objects. Data integrity requirements addressing the effects
of unauthorized MSM need not be included in this model. The
overall network policy must be decomposed into policy ele-
ments that are allocated to appropriate components and used
as the basis for the security policy model for those com-
ponents.
The level of abstraction of the model, and the set of
subjects and objects that are explicitly represented in the
model, will be affected by the NTCB partitioning. Subjects
and objects must be represented explicitly in the model for
the partition if there is some network component whose NTCB
partition exercises access control over them. The model
shall be structured so that the axioms and entities
applicable to individual network components are manifest.
Global network policy elements that are allocated to com-
ponents shall be represented by the model for that com-
ponent.
THE REQUIREMENTS FOR A NETWORK DTLS ARE GIVEN IN THE
DESIGN DOCUMENTATION SECTION.
+ Rationale
The treatment of the model depends to a great extent on
the degree of integration of the communications service into
a distributed system. In a closely coupled distributed sys-
tem, one might use a model that closely resembles one
appropriate for a stand-alone computer system.
In other cases, the model of each partition will be
expected to show the role of the NTCB partition in each kind
of component. It will most likely clarify the model,
although not part of the model, to show access restrictions
implied by the system design; for example, subjects
representing protocol entities might have access only to
objects containing data units at the same layer of protocol.
The allocation of subjects and objects to different proto-
col layers is a protocol design choice which need not be
reflected in the security policy model.
3.2.3.2.3 Configuration Management
+ Statement from DoD 5200.28-STD
DURING DEVELOPMENT AND MAINTENANCE OF THE TCB, A CONFIGURA-
TION MANAGEMENT SYSTEM SHALL BE IN PLACE THAT MAINTAINS CON-
TROL OF CHANGES TO THE DESCRIPTIVE TOP-LEVEL SPECIFICATION,
OTHER DESIGN DATA, IMPLEMENTATION DOCUMENTATION, SOURCE
CODE, THE RUNNING VERSION OF THE OBJECT CODE, AND TEST FIX-
TURES AND DOCUMENTATION. THE CONFIGURATION MANAGEMENT SYS-
TEM SHALL ASSURE A CONSISTENT MAPPING AMONG ALL DOCUMENTA-
TION AND CODE ASSOCIATED WITH THE CURRENT VERSION OF THE
TCB. TOOLS SHALL BE PROVIDED FOR GENERATION OF A NEW VER-
SION OF THE TCB FROM SOURCE CODE. ALSO AVAILABLE SHALL BE
TOOLS FOR COMPARING A NEWLY GENERATED VERSION WITH THE PRE-
VIOUS TCB VERSION IN ORDER TO ASCERTAIN THAT ONLY THE
INTENDED CHANGES HAVE BEEN MADE IN THE CODE THAT WILL ACTU-
ALLY BE USED AS THE NEW VERSION OF THE TCB.
+ Interpretation
THE REQUIREMENT APPLIES AS WRITTEN, WITH THE FOLLOWING
EXTENSIONS:
1. A CONFIGURATION MANAGEMENT SYSTEM MUST BE IN PLACE
FOR EACH NTCB PARTITION.
2. A CONFIGURATION MANAGEMENT PLAN MUST EXIST FOR THE
ENTIRE SYSTEM. IF THE CONFIGURATION MANAGEMENT SYS-
TEM IS MADE UP OF THE CONGLOMERATION OF THE CONFI-
GURATION MANAGEMENT SYSTEMS OF THE VARIOUS NTCB PAR-
TITIONS, THEN THE CONFIGURATION MANAGEMENT PLAN MUST
ADDRESS THE ISSUE OF HOW CONFIGURATION CONTROL IS
APPLIED TO THE SYSTEM AS A WHOLE.
+ Rationale
EACH NTCB PARTITION MUST HAVE A CONFIGURATION MANAGE-
MENT SYSTEM IN PLACE, OR ELSE THERE WILL BE NO WAY FOR THE
NTCB AS A WHOLE TO HAVE AN EFFECTIVE CONFIGURATION MANAGE-
MENT SYSTEM. THE OTHER EXTENSIONS ARE MERELY REFLECTIONS OF
THE WAY THAT NETWORKS OPERATE IN PRACTICE.
3.2.4 Documentation.
_ _ _ _____________
3.2.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.
3.2.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. The procedures
for examining and maintaining the audit files as well as the
detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and
administrator functions related to security, to include
changing the security characteristics of a user. It shall
provide interpretations on the consistent and effective use
of the protection features of the system, how they interact,
how to securely generate a new TCB, and facility procedures,
warnings, and privileges that need to be controlled in order
to operate the facility in a secure manner. THE TCB MODULES
THAT CONTAIN THE REFERENCE VALIDATION MECHANISM SHALL BE
IDENTIFIED. THE PROCEDURES FOR SECURE GENERATION OF A NEW
TCB FROM SOURCE AFTER MODIFICATION OF ANY MODULES IN THE TCB
SHALL BE DESCRIBED.
+ 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).
6. INCREMENTAL UPDATES; THAT IS, IT MUST EXPLICITLY
INDICATE WHICH COMPONENTS OF THE NETWORK MAY CHANGE
WITHOUT OTHERS ALSO CHANGING.
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).
THE COMPONENTS OF THE NETWORK THAT FORM THE NTCB MUST
BE IDENTIFIED. FURTHERMORE, THE MODULES WITHIN AN NTCB PAR-
TITION THAT CONTAIN THE REFERENCE VALIDATION MECHANISM (IF
ANY) WITHIN THAT PARTITION MUST BE IDENTIFIED.
THE PROCEDURES FOR THE SECURE GENERATION OF A NEW VER-
SION (OR COPY) OF EACH NTCB PARTITION FROM SOURCE MUST BE
DESCRIBED. THE PROCEDURES AND REQUIREMENTS FOR THE SECURE
GENERATION OF THE NTCB NECESSITATED BY CHANGES IN THE NET-
WORK CONFIGURATION SHALL BE DESCRIBED.
+ 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.
As mentioned in the section on Label Integrity, cryp-
tography is one common mechanism employed to protect commun-
ication 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.
THE REQUIREMENTS FOR DESCRIPTIONS OF NTCB GENERATION
AND IDENTIFICATION OF MODULES AND COMPONENTS THAT FORM THE
NTCB ARE STRAIGHTFORWARD EXTENSIONS OF THE TCSEC REQUIRE-
MENTS INTO THE NETWORK CONTEXT. IN THOSE CASES WHERE THE
VENDOR DOES NOT PROVIDE SOURCE CODE, AN ACCEPTABLE PROCEDURE
SHALL BE TO REQUEST THE VENDOR TO PERFORM THE SECURE GENERA-
TION.
3.2.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. IT SHALL INCLUDE
RESULTS OF TESTING THE EFFECTIVENESS OF THE METHODS USED TO
REDUCE COVERT CHANNEL BANDWIDTHS.
+ 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.
THE BANDWIDTHS OF COVERT CHANNELS ARE USED TO DETERMINE
THE SUITABILITY OF A NETWORK SYSTEM FOR A GIVEN ENVIRONMENT.
THE EFFECTIVENESS OF THE METHODS USED TO REDUCE THESE
BANDWIDTHS MUST THEREFORE BE ACCURATELY DETERMINED.
3.2.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.
THE interfaces between THE TCB modules shall be described.
A FORMAL description of the security policy model enforced
by the TCB shall be available and an explanation provided to
show that it is sufficient to enforce the security policy.
The specific TCB protection mechanisms shall be identified
and an explanation given to show that they satisfy the
model. THE DESCRIPTIVE TOP-LEVEL SPECIFICATION (DTLS) SHALL
BE SHOWN TO BE AN ACCURATE DESCRIPTION OF THE TCB INTERFACE.
DOCUMENTATION SHALL DESCRIBE HOW THE TCB IMPLEMENTS THE
REFERENCE MONITOR CONCEPT AND GIVE AN EXPLANATION WHY IT IS
TAMPER RESISTANT, CANNOT BE BYPASSED, AND IS CORRECTLY
IMPLEMENTED. DOCUMENTATION SHALL DESCRIBE HOW THE TCB IS
STRUCTURED TO FACILITATE TESTING AND TO ENFORCE LEAST
PRIVILEGE. THIS DOCUMENTATION SHALL ALSO PRESENT THE
RESULTS OF THE COVERT CHANNEL ANALYSIS AND THE TRADEOFFS
INVOLVED IN RESTRICTING THE CHANNELS. ALL AUDITABLE EVENTS
THAT MAY BE USED IN THE EXPLOITATION OF KNOWN COVERT STORAGE
CHANNELS SHALL BE IDENTIFIED. THE BANDWIDTHS OF KNOWN
COVERT STORAGE CHANNELS, THE USE OF WHICH IS NOT DETECTABLE
BY THE AUDITING MECHANISMS, SHALL BE PROVIDED. (SEE THE
COVERT CHANNEL GUIDELINE SECTION.)
+ 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.
THE DOCUMENTATION INCLUDES BOTH A SYSTEM DESCRIPTION
AND A SET OF COMPONENT DTLS'S. THE SYSTEM DESCRIPTION
ADDRESSES THE NETWORK SECURITY ARCHITECTURE AND DESIGN BY
SPECIFYING THE TYPES OF COMPONENTS IN THE NETWORK, WHICH
ONES ARE TRUSTED, AND IN WHAT WAY THEY MUST COOPERATE TO
SUPPORT NETWORK SECURITY OBJECTIVES. A COMPONENT DTLS SHALL
BE PROVIDED FOR EACH TRUSTED NETWORK COMPONENT, I.E., EACH
COMPONENT CONTAINING AN NTCB PARTITION. EACH COMPONENT DTLS
SHALL DESCRIBE THE INTERFACE TO THE NTCB PARTITION OF ITS
COMPONENT. APPENDIX A ADDRESSES COMPONENT EVALUATION ISSUES.
As stated in the introduction to Division B, the spon-
sor must demonstrate that the NTCB employs the reference
monitor concept. The security policy model must be a model
for a reference monitor.
The security policy model for each partition implement-
ing a reference monitor shall fully represent the access
control policy supported by the partition, including the
discretionary and mandatory security policy for secrecy
and/or integrity. For the mandatory policy the single domi-
nance relation for sensitivity labels, including secrecy
and/or integrity components, shall be precisely defined.
+ 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 specifica-
tions will in fact be trusted, that is, it will be evaluat-
able under these interpretations.
The term "model" is used in several different ways in a
network context, e.g., a "protocol reference model," a "for-
mal network model," etc. Only the "security policy model" is
addressed by this requirement and is specifically intended
to model the interface, viz., "security perimeter," of the
reference monitor and must meet all the requirements defined
in the TCSEC. It must be shown that all parts of the TCB
are a valid interpretation of the security policy model,
i.e., that there is no change to the secure state except as
represented by the model.
3.3 CLASS (B3): SECURITY DOMAINS
_ _ _____ __ ________ _______
THE CLASS (B3) NTCB MUST SATISFY THE REFERENCE
MONITOR REQUIREMENTS THAT IT MEDIATE ALL ACCESSES
OF SUBJECTS TO OBJECTS, BE TAMPERPROOF, AND BE
SMALL ENOUGH TO BE SUBJECTED TO ANALYSIS AND
TESTS. TO THIS END, THE NTCB IS STRUCTURED TO
EXCLUDE CODE NOT ESSENTIAL TO SECURITY POLICY
ENFORCEMENT, WITH SIGNIFICANT SYSTEM ENGINEERING
DURING NTCB DESIGN AND IMPLEMENTATION DIRECTED
TOWARD MINIMIZING ITS COMPLEXITY. A SECURITY
ADMINISTRATOR IS SUPPORTED, AUDIT MECHANISMS ARE
EXPANDED TO SIGNAL SECURITY-RELEVANT EVENTS, AND
SYSTEM RECOVERY PROCEDURES ARE REQUIRED. THE SYS-
TEM IS HIGHLY RESISTANT TO PENETRATION. THE FOL-
LOWING ARE MINIMAL REQUIREMENTS FOR SYSTEMS
ASSIGNED A CLASS (B3) RATING:
3.3.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 and mandatory
requirements applicable to this class. The policy may
require data secrecy, or data integrity, or both. The pol-
icy is an access control policy having two primary com-
ponents: mandatory and discretionary. The policy shall
include a discretionary policy for protecting the informa-
tion being processed based on the authorizations of indivi-
duals, users, or groups of users. This access control pol-
icy statement shall describe the requirements on the network
to prevent or detect "reading or destroying" sensitive
information by unauthorized users or errors. The mandatory
policy must define the set of distinct sensitivity levels
that it supports. For the Class B1 or above the mandatory
policy shall be based on the labels associated with the
information that reflects its sensitivity with respect to
secrecy and/or integrity, where applicable, and labels asso-
ciated with users to reflect their authorization to access
such information. 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 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 and mandatory secrecy
policy that is enforced in the network to prevent
unauthorized users from reading the sensitive infor-
mation entrusted to the network.
DATA INTEGRITY POLICY: The network sponsor shall
define the discretionary and mandatory integrity
policy to prevent unauthorized users from modifying,
viz., writing, sensitive information. The defini-
tion of data integrity presented by the network
sponsor refers to the requirement that the informa-
tion has not been subjected to unauthorized modifi-
cation in the network. The mandatory integrity pol-
icy enforced by the NTCB cannot, in general, prevent
modification while information is being transmitted
between components. However, an integrity sensi-
tivity label may reflect the confidence that the
information has not been subjected to transmission
errors because of the protection afforded during
transmission. This requirement is distinct from the
requirement for label integrity.
+ 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.
The mandatory integrity policy (at class B1 and above)
in some architectures may be useful in supporting the link-
age between the connection oriented abstraction introduced
in the Introduction and the individual components of the
network. For example, in a key distribution center for
end-to-end encryption, a distinct integrity category may be
assigned to isolate the key generation code and data from
possible modification by other supporting processes in the
same component, such as operator interfaces and audit.
The mandatory integrity policy for some architecture
may define an integrity sensitivity label that reflects the
specific requirements for ensuring that information has not
been subject to random errors in excess of a stated limit
nor to unauthorized message stream modification (MSM) -.
The specific metric associated with an integrity sensitivity
label will generally reflect the intended applications of
the network.
3.3.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., ACCESS CONTROL LISTS)
shall allow users to specify and control sharing of those
OBJECTS and shall provide controls to limit propagation of
access rights. The discretionary access control mechanism
shall, either by explicit user action or by default, provide
that objects are protected from unauthorized access. These
access controls shall be capable of SPECIFYING, FOR EACH
_________________________
- See Voydock, Victor L. and Stephen T. Kent, "Secu-
rity Mechanisms in High-Level Network Protocols," Com-
___
puting Surveys, Vol. 15, No. 2, June 1983, pp 135-171.
______ _______
NAMED OBJECT, A LIST OF NAMED INDIVIDUALS AND A LIST OF
GROUPS OF NAMED INDIVIDUALS WITH THEIR RESPECTIVE MODES OF
ACCESS TO THAT OBJECT. FURTHERMORE, FOR EACH SUCH NAMED
OBJECT, IT SHALL BE POSSIBLE TO SPECIFY A LIST OF NAMED
INDIVIDUALS AND A LIST OF GROUPS OF NAMED INDIVIDUALS FOR
WHICH NO ACCESS TO THE OBJECT IS GIVEN. Access permission
to an object by users not already possessing access permis-
sion 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.
There are two forms of distribution for the DAC mechan-
ism: implementing portions of the DAC in separate com-
ponents, and supporting the DAC in subjects contained within
the NTCB partition in a component. Since "the ADP system"
is understood to be "the computer network" as a whole, each
network component is responsible for enforcing security in
the mechanisms allocated to it to ensure secure implementa-
tion of the network security policy. For traditional host
systems it is frequently easy to also enforce the DAC along
with the MAC within the reference monitor, per se, although
a few approaches, such as virtual machine monitors, support
DAC outside this interface.
In contrast to the universally rigid structure of man-
datory policies (see the Mandatory Access Control section),
DAC policies tend to be very network and system specific,
with features that reflect the natural use of the system.
For networks it is common that individual hosts will impose
controls over their local users on the basis of named
individuals-much like the controls used when there is no
network connection. However, it is difficult to manage in a
centralized manner all the individuals using a large net-
work. Therefore, users on other hosts are commonly grouped
together so that the controls required by the network DAC
policy are actually based on the identity of the hosts or
other components. A gateway is an example of such a com-
ponent.
The assurance requirements are at the very heart of the
concept of a trusted system. It is the assurance that
determines if a system or network is appropriate for a given
environment, as reflected, for example, in the Environments
Guideline-. In the case of monolithic systems that have DAC
integral to the reference monitor, the assurance require-
ments for DAC are inseparable from those of the rest of the
reference monitor. For networks there is typically a much
clearer distinction due to distributed DAC. The rationale
for making the distinction in this network interpretation is
that if major trusted network components can be made signi-
ficantly easier to design and implement without reducing the
ability to meet security policy, then trusted networks will
be more easily available.
3.3.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
_________________________
- Guidance for Applying the Department of Defense
________ ___ ________ ___ __________ __ _______
Trusted Computer System Evaluation Criteria in Specific
_______ ________ ______ __________ ________ __ ________
Environments, CSC-STD-003-85.
____________
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.
3.3.1.3 Labels
+ Statement from DoD 5200.28-STD
Sensitivity labels associated with each ADP system resource
(e.g., subject, storage object, ROM) that is directly or
indirectly accessible by subjects external to the TCB shall
be maintained by the TCB. These labels shall be used as the
basis for mandatory access control decisions. In order to
import non-labeled data, the TCB shall request and receive
from an authorized user the sensitivity level of the data,
and all such actions shall be auditable by the TCB.
+ Interpretation
Non-labeled data imported under the control of the NTCB
partition will be assigned a label constrained by the device
labels of the single-level device used to import it. Labels
may include secrecy and integrity- components in accordance
with the overall network security policy described by the
network sponsor. Whenever the term "label" is used
throughout this interpretation, it is understood to include
both components as applicable. Similarly, the terms
"single-level" and "multilevel" are understood to be based
on both the secrecy and integrity components of the policy.
The mandatory integrity policy will typically have require-
ments, such as the probability of undetected message stream
modification, that will be reflected in the label for the
_________________________
- See, for example, Biba, K.J., "Integrity Considera-
tion for Secure Computer Systems," ESD-TR-76-372, MTR-
3153, The MITRE Corporation, Bedford, MA, April 1977.
data so protected. For example, when data is imported its
integrity label may be assigned based on mechanisms, such as
cryptography, used to provide the assurance required by the
policy. The NTCB shall assure that such mechanism are pro-
tected from tampering and are always invoked when they are
the basis for a label.
If the security policy includes an integrity policy,
all activities that result in message-stream modification
during transmission are regarded as unauthorized accesses in
violation of the integrity policy. The NTCB shall have an
automated capability for testing, detecting, and reporting
those errors/corruptions that exceed specified network
integrity policy requirements. Message-stream modification
(MSM) countermeasures shall be identified. A technology of
adequate strength shall be selected to resist MSM. If
encryption methodologies are employed, they shall be
approved by the National Security Agency.
All objects must be labeled within each component of
the network that is trusted to maintain separation of multi-
ple levels of information. The label associated with any
objects associated with single-level components will be
identical to the level of that component. Objects used to
store network control information, and other network struc-
tures, such as routing tables, must be labeled to prevent
unauthorized access and/or modification.
+ Rationale
The interpretation is an extension of the requirement
into the context of a network system and partitioned NTCB as
defined for these network interpretations. A single-level
device may be regarded either as a subject or an object. A
multilevel device is regarded as a trusted subject in which
the security range of the subject is the minimum-maximum
range of the data expected to be transmitted over the dev-
ice.
The sensitivity labels for either secrecy or integrity
or both may reflect non-hierarchical categories or hierarch-
ical classification or both.
For a network it is necessary that this requirement be
applied to all network system resources at the (B2) level
and above.
The NTCB is responsible for implementing the network
integrity policy, when one exists. The NTCB must enforce
that policy by ensuring that information is accurately
transmitted from source to destination (regardless of the
number of intervening connecting points). The NTCB must be
able to counter equipment failure, environmental disrup-
tions, and actions by persons and processes not authorized
to alter the data. Protocols that perform code or format
conversion shall preserve the integrity of data and control
information.
The probability of an undetected transmission error may
be specified as part of the network security policy so that
the acceptability of the network for its intended applica-
tion may be determined. The specific metrics (e.g., proba-
bility of undetected modification) satisfied by the data can
be reflected in the integrity sensitivity label associated
with the data while it is processed within a component. It
is recognized that different applications and operational
environments (e.g., crisis as compared to logistic) will
have different integrity requirements.
The network shall also have an automated capability of
testing for, detecting, and reporting errors that exceed a
threshold consistent with the operational mode requirements.
The effectiveness of integrity countermeasures must be esta-
blished with the same rigor as the other security-relevant
properties such as secrecy.
Cryptography is often utilized as a basis to provide
data integrity assurance. Mechanisms, such as Manipulation
Detection Codes (MDC)-, may be used. The adequacy of the
encryption or MDC algorithm, the correctness of the protocol
logic, and the adequacy of implementation must be esta-
blished in MSM countermeasures design.
3.3.1.3.1 Label Integrity
+ Statement from DoD 5200.28-STD
Sensitivity labels shall accurately represent sensitivity
levels of the specific subjects or objects with which they
are associated. When exported by the TCB, sensitivity
labels shall accurately and unambiguously represent the
internal labels and shall be associated with the information
being exported.
+ Interpretation
The phrase "exported by the TCB" is understood to
include transmission of information from an object in one
component to an object in another component. Information
transferred between NTCB partitions is addressed in the Sys-
tem Integrity Section. The form of internal and external
(exported) sensitivity labels may differ, but the meaning
shall be the same. The NTCB shall, in addition, ensure that
correct association of sensitivity labels with the informa-
tion being transported across the network is preserved.
_________________________
- See Jueneman, R. R., "Electronic Document Authenti-
cation," IEEE Network Magazine, April 1987, pp 17-23.
____ _______ ________
As mentioned in the Trusted Facility Manual Section,
encryption transforms the representation of information so
that it is unintelligible to unauthorized subjects.
Reflecting this transformation, the sensitivity level of the
ciphertext is generally lower than the cleartext. It fol-
lows that cleartext and ciphertext are contained in dif-
ferent objects, each possessing its own label. The label of
the cleartext must be preserved and associated with the
ciphertext so that it can be restored when the cleartext is
subsequently obtained by decrypting the ciphertext. If the
cleartext is associated with a single-level device, the
label of that cleartext may be implicit. The label may also
be implicit in the key.
When information is exported to an environment where it
is subject to deliberate or accidental modification, the TCB
shall support the means, such as cryptographic checksums, to
assure the accuracy of the labels. When there is a manda-
tory integrity policy, the policy will define the meaning of
integrity labels.
+ Rationale
Encryption algorithms and their implementation are out-
side the scope of these interpretations. Such algorithms
may be implemented in a separate device or may be incor-
porated in a subject of a larger component. Without preju-
dice, either implementation packaging is referred to as an
encryption mechanism herein. If encryption methodologies are
employed in this regard, they shall be approved by the
National Security Agency (NSA). The encryption process is
part of the Network Trusted Computer Base partition in the
components in which it is implemented.
The encryption mechanism is not necessarily a mul-
tilevel device or multilevel subject, as these terms are
used in these criteria. The process of encryption is mul-
tilevel by definition. The cleartext and ciphertext inter-
faces carry information of different sensitivity. An
encryption mechanism does not process data in the sense of
performing logical or arithmetic operations on that data
with the intent of producing new data. The cleartext and
ciphertext interfaces on the encryption mechanism must be
separately identified as being single-level or multilevel.
If the interface is single-level, then the sensitivity of
the data is established by a trusted individual and impli-
citly associated with the interface; the Exportation to
Single-Level Devices criterion applies.
If the interface is multilevel, then the data must be
labeled; the Exportation to Multilevel Devices criterion
applies. The network architect is free to select an accept-
able mechanism for associating a label with an object. With
reference to encrypted objects, the following examples are
possible:
1. Include a label field in the protocol definition of
the object.
2. Implicitly associate the label with the object
through the encryption key. That is, the encryption
key uniquely identifies a sensitivity level. A sin-
gle or private key must be protected at the level of
the data that it encrypts.
3.3.1.3.2 Exportation of Labeled Information
+ Statement from DoD 5200.28-STD
The TCB shall designate each communication channel and I/O
device as either single-level or multilevel. Any change in
this designation shall be done manually and shall be audit-
able by the TCB. The TCB shall maintain and be able to
audit any change in the sensitivity level or levels associ-
ated with a communications channel or I/O device.
+ Interpretation
Each communication channel and network component shall
be designated as either single-level or multilevel. Any
change in this designation shall be done with the cognizance
and approval of the administrator or security officer in
charge of the affected components and the administrator or
security officer in charge of the NTCB. This change shall
be auditable by the network. The NTCB shall maintain and be
able to audit any change in the device labels associated
with a single-level communication channel or the range asso-
ciated with a multilevel communication channel or component.
The NTCB shall also be able to audit any change in the set
of sensitivity levels associated with the information which
can be transmitted over a multilevel communication channel
or component.
+ Rationale
Communication channels and components in a network are
analogous to communication channels and I/O devices in
stand-alone systems. They must be designated as either mul-
tilevel (i.e., able to distinguish and maintain separation
among information of various sensitivity levels) or single-
level. As in the TCSEC, single-level devices may only be
attached to single-level channels.
The level or set of levels of information that can be
sent to a component or over a communication channel shall
only change with the knowledge and approval of the security
officers (or system administrator, if there is no security
officer) of the network, and of the affected components.
This requirement ensures that no significant security-
relevant changes are made without the approval of all
affected parties.
3.3.1.3.2.1 Exportation to Multilevel Devices
+ Statement from DoD 5200.28-STD
When the TCB exports an object to a multilevel I/O device,
the sensitivity label associated with that object shall also
be exported and shall reside on the same physical medium as
the exported information and shall be in the same form
(i.e., machine-readable or human-readable form). When the
TCB exports or imports an object over a multilevel communi-
cations channel, the protocol used on that channel shall
provide for the unambiguous pairing between the sensitivity
labels and the associated information that is sent or
received.
+ Interpretation
The components, including hosts, of a network shall be
interconnected over "multilevel communication channels,"
multiple single-level communication channels, or both, when-
ever the information is to be protected at more than a sin-
gle sensitivity level. The protocol for associating the
sensitivity label and the exported information shall provide
the only information needed to correctly associate a sensi-
tivity level with the exported information transferred over
the multilevel channel between the NTCB partitions in indi-
vidual components. This protocol definition must specify the
representation and semantics of the sensitivity labels
(i.e., the machine-readable label must uniquely represent
the sensitivity level).
The "unambiguous" association of the sensitivity level
with the communicated information shall meet the same level
of accuracy as that required for any other label within the
NTCB, as specified in the criterion for Label Integrity.
This may be provided by protected and highly reliable direct
physical layer connections, or by traditional cryptographic
link protection in which any errors during transmission can
be readily detected, or by use of a separate channel. The
range of information imported or exported must be con-
strained by the associated device labels.
+ Rationale
This protocol must specify the representation and
semantics of the sensitivity labels. See the Mandatory
Access Control Policies section in Appendix B. The mul-
tilevel device interface to (untrusted) subjects may be
implemented either by the interface of the reference moni-
tor, per se, or by a multilevel subject (e.g., a "trusted
subject" as defined in the Bell-LaPadula Model) that pro-
vides the labels based on the internal labels of the NTCB
partition.
The current state of the art limits the support for
mandatory policy that is practical for secure networks.
Reference monitor support to ensure the control over all the
operations of each subject in the network must be completely
provided within the single NTCB partition on which that sub-
ject interfaces to the NTCB. This means that the entire
portion of the "secure state" represented in the formal
security policy model that may be changed by transitions
invoked by this subject must be contained in the same com-
ponent.
The secure state of an NTCB partition may be affected
by events external to the component in which the NTCB parti-
tion resides (e.g., arrival of a message). The effect
occurs asynchronusly after being initiated by an event in
another component or partition. For example, indeterminate
delays may occur between the initiation of a message in one
component, the arrival of the message in the NTCB partition
in another component, and the corresponding change to the
secure state of the second component. Since each component
is executing concurrently, to do otherwise would require
some sort of network-wide control to synchronize state tran-
sitions, such as a global network-wide clock for all proces-
sors; in general, such designs are not practical and prob-
ably not even desirable. Therefore, the interaction between
NTCB partitions is restricted to just communications between
pairs (at least logically) of devices-multilevel devices if
the device(s) can send/receive data of more than a single
level. For broadcast channels the pairs are the sender and
intended receiver(s). However, if the broadcast channel
carries multiple levels of information, additional mechanism
(e.g., cryptochecksum maintained by the TCB) may be required
to enforce separation and proper delivery.
A common representation for sensitivity labels is
needed in the protocol used on that channel and understood
by both the sender and receiver when two multilevel devices
(in this case, in two different components) are intercon-
nected. Each distinct sensitivity level of the overall net-
work policy must be represented uniquely in these labels.
Within a monolithic TCB, the accuracy of the sensi-
tivity labels is generally assured by simple techniques,
e.g., very reliable connections over very short physical
connections, such as on a single printed circuit board or
over an internal bus. In many network environments there is
a much higher probability of accidentally or maliciously
introduced errors, and these must be protected against.
3.3.1.3.2.2 Exportation to Single-Level Devices
+ Statement from DoD 5200.28-STD
Single-level I/O devices and single-level communication
channels are not required to maintain the sensitivity labels
of the information they process. However, the TCB shall
include a mechanism by which the TCB and an authorized user
reliably communicate to designate the single sensitivity
level of information imported or exported via single-level
communication channels or I/O devices.
+ Interpretation
Whenever one or both of two directly connected com-
ponents is not trusted to maintain the separation of infor-
mation of different sensitivity levels, or whenever the two
directly connected components have only a single sensitivity
level in common, the two components of the network shall
communicate over a single-level channel. Single-level com-
ponents and single-level communication channels are not
required to maintain the sensitivity labels of the informa-
tion they process. However, the NTCB shall include a reli-
able communication mechanism by which the NTCB and an
authorized user (via a trusted path) or a subject within an
NTCB partition can designate the single sensitivity level of
information imported or exported via single-level communica-
tion channels or network components. The level of informa-
tion communicated must equal the device level.
+ Rationale
Single-level communications channels and single-level
components in networks are analogous to single level chan-
nels and I/O devices in stand-alone systems in that they are
not trusted to maintain the separation of information of
different sensitivity levels. The labels associated with
data transmitted over those channels and by those components
are therefore implicit; the NTCB associates labels with the
data because of the channel or component, not because of an
explicit part of the bit stream. Note that the sensitivity
level of encrypted information is the level of the cipher-
text rather than the original level(s) of the plaintext.
3.3.1.3.2.3 Labeling Human-Readable Output
+ Statement from DoD 5200.28-STD
The ADP system administrator shall be able to specify the
printable label names associated with exported sensitivity
labels. The TCB shall mark the beginning and end of all
human-readable, paged, hardcopy output (e.g., line printer
output) with human-readable sensitivity labels that prop-
erly1 represent the sensitivity of the output. The TCB
shall, by default, mark the top and bottom of each page of
human-readable, paged, hardcopy output (e.g., line printer
output) with human-readable sensitivity labels that prop-
erly1 represent the sensitivity of the page. The TCB shall,
by default and in an appropriate manner, mark other forms of
human readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly1 represent the
sensitivity of the output. Any override of these markings
defaults shall be auditable by the TCB.
_________________________
1 The hierarchical classification component in human-
readable sensitivity labels shall be equal to the greatest
hierarchical classification of any of the information in the
output that the labels refer to; the non-hierarchical category
component shall include all of the non-hierarchical categories of
the information in the output the labels refer to, but no other
non-hierarchical categories.
+ Interpretation
This criterion imposes no requirement to a component
that produces no human-readable output. For those that do
produce human-readable output, each sensitivity level that
is defined to the network shall have a uniform meaning
across all components. The network administrator, in con-
junction with any affected component administrator, shall be
able to specify the human-readable label that is associated
with each defined sensitivity level.
+ Rationale
The interpretation is a straightforward extension of
the requirement into the context of a network system and
partitioned NTCB as defined for these network interpreta-
tions.
3.3.1.3.3 Subject Sensitivity Labels
+ Statement from DoD 5200.28-STD
The TCB shall immediately notify a terminal user of each
change in the sensitivity level associated with that user
during an interactive session. A terminal user shall be
able to query the TCB as desired for a display of the
subject's complete sensitivity label.
+ Interpretation
An NTCB partition shall immediately notify a terminal
user attached to its component of each change in the sensi-
tivity level associated with that user.
+ Rationale
The local NTCB partition must ensure that the user
understands the sensitivity level of information sent to and
from a terminal. When a user has a surrogate process in
another component, adjustments to its level may occur to
maintain communication with the user. These changes may
occur asynchronously. Such adjustments are necessitated by
mandatory access control as applied to the objects involved
in the communication path.
3.3.1.3.4 Device Labels
+ Statement from DoD 5200.28-STD
The TCB shall support the assignment of minimum and maximum
sensitivity levels to all attached physical devices. These
sensitivity levels shall be used by the TCB to enforce con-
straints imposed by the physical environments in which the
devices are located.
+ Interpretation
This requirement applies as written to each NTCB parti-
tion that is trusted to separate information based on sensi-
tivity level. Each I/O device in a component, used for com-
munication with other network components, is assigned a dev-
ice range, consisting of a set of labels with a maximum and
minimum. (A device range usually contains, but does not
necessarily contain, all possible labels "between" the max-
imum and minimum, in the sense of dominating the minimum and
being dominated by the maximum.)
The NTCB always provides an accurate label for informa-
tion exported through devices. Information exported or
imported using a single-level device is labelled implicitly
by the sensitivity level of the device. Information
exported from one multilevel device and imported at another
must be labelled through an agreed-upon protocol, unless it
is labelled implicitly by using a communication link that
always carries a single level.
Information exported at a given sensitivity level can
be sent only to an importing device whose device range con-
tains that level or a higher level. If the importing device
range does not contain the given level, the information is
relabelled upon reception at a higher level within the
importing device range. Relabelling should not occur other-
wise.
+ Rationale
The purpose of device labels is to reflect and con-
strain the sensitivity levels of information authorized for
the physical environment in which the devices are located.
The information transfer restrictions permit one-way
communication (i.e., no acknowledgements) from one device to
another whose ranges have no level in common, as long as
each level in the sending device range is dominated by some
level in the receiving device range. It is never permitted
to send information at a given level to a device whose range
does not contain a dominating level. (See Appendix C for
similar interconnection rules for the interconnected AIS
view.)
3.3.1.4 Mandatory Access Control
+ Statement from DoD 5200.28-STD
The TCB shall enforce a mandatory access control policy over
all resources (i.e., subjects, storage objects, and I/O dev-
ices) that are directly or indirectly accessible by subjects
external to the TCB. These subjects and objects shall be
assigned sensitivity labels that are a combination of
hierarchical classification levels and non-hierarchical
categories, and the labels shall be used as the basis for
mandatory access control decisions. The TCB shall be able
to support two or more such sensitivity levels. (See the
Mandatory Access Control interpretations.) The following
requirements shall hold for all accesses between all sub-
jects external to the TCB and all objects directly or
indirectly accessible by these subjects. A subject can
read an object only if the hierarchical classification in
the subject's sensitivity level is greater than or equal to
the hierarchical classification of the object's sensitivity
level and the non-hierarchical categories in the subject's
sensitivity level include all the non-hierarchical
categories in the object's sensitivity level. A subject can
write an object only if the hierarchical classification in
the subject's sensitivity level is less than or equal to the
hierarchical classification of the object's sensitivity
level and the non-hierarchical categories in the subject's
sensitivity level are included in the non-hierarchical
categories in the object's sensitivity level. Identification
and authentication data shall be used by the TCB to authen-
ticate the user's identity and to ensure that the sensi-
tivity level and authorization of subjects external to the
TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of
that user.
+ Interpretation
Each partition of the NTCB exercises mandatory access
control policy over all subjects and objects in its com-
ponent. In a network, the responsibility of an NTCB parti-
tion encompasses all mandatory access control functions in
its component that would be required of a TCB in a stand-
alone system. In particular, subjects and objects used for
communication with other components are under the control of
the NTCB partition. Mandatory access control includes
secrecy and integrity control to the extent that the network
sponsor has described in the overall network security pol-
icy.
Conceptual entities associated with communication
between two components, such as sessions, connections and
virtual circuits, may be thought of as having two ends, one
in each component, where each end is represented by a local
object. Communication is viewed as an operation that copies
information from an object at one end of a communication
path to an object at the other end. Transient data-carrying
entities, such as datagrams and packets, exist either as
information within other objects, or as a pair of objects,
one at each end of the communication path.
The requirement for "two or more" sensitivity levels
can be met by either secrecy or integrity levels. When
there is a mandatory integrity policy, the stated require-
ments for reading and writing are generalized to: A subject
can read an object only if the subject's sensitivity level
dominates the object's sensitivity level, and a subject can
write an object only if the object's sensitivity level dom-
inates the subject's sensitivity level. Based on the
integrity policy, the network sponsor shall define the domi-
nance relation for the total label, for example, by combin-
ing secrecy and integrity lattices. -
+ Rationale
An NTCB partition can maintain access control only over
subjects and objects in its component. At levels B2 and
above, the NTCB partition must maintain access control over
all subjects and objects in its component. Access by a sub-
ject in one component to information contained in an object
in another component requires the creation of a subject in
the remote component which acts as a surrogate for the first
subject.
The mandatory access controls must be enforced at the
interface of the reference monitor (viz. the mechanism that
controls physical processing resources) for each NTCB parti-
tion. This mechanism creates the abstraction of subjects
and objects which it controls. Some of these subjects out-
side the reference monitor, per se, may be designated to
implement part of an NTCB partition's mandatory policy,
e.g., by using the ``trusted subjects" defined in the Bell-
LaPadula model.
The prior requirements on exportation of labeled infor-
mation to and from I/O devices ensure the consistency
between the sensitivity labels of objects connected by a
communication path. As noted in the introduction, the net-
work architecture must recognize the linkage between the
overall mandatory network security policy and the connection
oriented abstraction. For example, individual data-carrying
entities such as datagrams can have individual sensitivity
labels that subject them to mandatory access control in each
component. The abstraction of a single-level connection is
realized and enforced implicitly by an architecture while a
connection is realized by single-level subjects that neces-
sarily employ only datagrams of the same level.
The fundamental trusted systems technology permits the
DAC mechanism to be distributed, in contrast to the require-
ments for mandatory access control. For networks this
separation of MAC and DAC mechanisms is the rule rather than
_________________________
- See, for example, Grohn, M. J., A Model of a Pro-
_ _____ __ _ ___
tected Data Management System, ESD-TR-76-289, I. P.
______ ____ __________ ______
Sharp Assoc. Ltd., June, 1976; and Denning, D .E.,
Lunt, T. F., Neumann, P. G., Schell, R. R., Heckman, M.
and Shockley, W., Secure Distributed Data Views, Secu-
______ ___________ ____ _____ ____
rity Policy and Interpretation for a Class A1 Multilev-
____ ______ ___ ______________ ___ _ _____ __ ________
el Secure Relational Database System,SRI International,
__ ______ __________ ________ ______
November 1986.
the exception.
The set of total sensitivity labels used to represent
all the sensitivity levels for the mandatory access control
(combined data secrecy and data integrity) policy always
forms a partially ordered set. Without loss of generality,
this set of labels can always be extended to form a lattice,
by including all the combinations of non-hierarchical
categories. As for any lattice, a dominance relation is
always defined for the total sensitivity labels. For admin-
istrative reasons it may be helpful to have a maximum level
which dominates all others.
3.3.2 Accountability
_ _ _ ______________
3.3.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 maintain
authentication data that includes information for verifying
the identify of individual users (e.g., passwords) as well
as information for determining the clearance and authoriza-
tions of individual users. This data shall be used by the
TCB to authenticate the user's identity and to ensure that
the sensitivity level and authorization of subjects external
to the TCB that may be created to act on behalf of the indi-
vidual user are dominated by the clearance and authorization
of that user. 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
_________________________
= Department of Defense Password Management Guide-
__________ __ _______ ________ __________ _____
line, CSC-STD-002-85
____
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.
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. If the authenticated identification is used as the
basis of determining a sensitivity label for a subject, it
must satisfy the Label Integrity criterion.
An authenticated identification may be forwarded
between components and employed in some component to iden-
tify the sensitivity level associated with a subject created
to act on behalf of the user so identified.
3.3.2.1.1 Trusted Path
+ Statement from DoD 5200.28-STD
The TCB shall support a trusted communication path between
itself and USERS FOR USE WHEN A POSITIVE TCB-TO-USER CONNEC-
TION IS REQUIRED (E.G., LOGIN, CHANGE SUBJECT SENSITIVITY
LEVEL). Communications via this TRUSTED path shall be
ACTIVATED exclusively by a USER OR THE TCB AND SHALL BE
LOGICALLY AND UNMISTAKABLY DISTINGUISHABLE FROM OTHER PATHS.
+ Interpretation
A trusted path is supported between a user (i.e.,
human) and the NTCB partition in the component to which the
user is directly connected.
+ Rationale
When a user logs into a remote component, the user id
is transmitted securely between the local and remote NTCB
partitions in accordance with the requirements in Identifi-
cation and Authentication.
Trusted Path is necessary in order to assure that the
user is communicating with the NTCB and only the NTCB when
security relevant activities are taking place (e.g., authen-
ticate user, set current session sensitivity level). How-
ever, Trusted Path does not address communications within
the NTCB, only communications between the user and the NTCB.
If, therefore, a component does not support any direct user
communication then the component need not contain mechanisms
for assuring direct NTCB to user communications.
The requirement for trusted communication between one
NTCB partition and another NCTB partition is addressed in
the System Architecture section. These requirements are
separate and distinct from the user to NTCB communication
requirement of a trusted path. However, it is expected that
this trusted communication between one NTCB partition and
another NTCB partition will be used in conjunction with the
trusted path to implement trusted communication between the
user and the remote NTCB partition.
3.3.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,
introduction 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. The TCB shall also be able to audit any override of
human-readable output markings. 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 and the object's
sensitivity level. The ADP system administrator shall be
able to selectively audit the actions of any one or more
users based on individual identify and/or object sensitivity
level. The TCB shall be able to audit the identified
events that may be used in the exploitation of covert
storage channels. THE TCB SHALL CONTAIN A MECHANISM THAT
IS ABLE TO MONITOR THE OCCURRENCE OR ACCUMULATION OF SECU-
RITY AUDITABLE EVENTS THAT MAY INDICATE AN IMMINENT VIOLA-
TION OF SECURITY POLICY. THIS MECHANISM SHALL BE ABLE TO
IMMEDIATELY NOTIFY THE SECURITY ADMINISTRATOR WHEN THRES-
HOLDS ARE EXCEEDED AND, IF THE OCCURRENCE OR ACCUMULATION OF
THESE SECURITY RELEVANT EVENTS CONTINUES, THE SYSTEM SHALL
TAKE THE LEAST DISRUPTIVE ACTION TO TERMINATE THE EVENT.
+ 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.
The capability must exist to audit the identified
events that may be used in the exploitation of covert
storage channels. To accomplish this, each NTCB partition
must be able to audit those events locally that may lead to
the exploitation of a covert storage channel which exist
because of the network.
THE SPONSOR SHALL IDENTIFY THE SPECIFIC AUDITABLE
EVENTS THAT MAY INDICATE AN IMMINENT VIOLATION OF SECURITY
POLICY. THE COMPONENT WHICH DETECTS THE OCCURRENCE OR ACCU-
MULATION OF SUCH EVENTS MUST BE ABLE TO NOTIFY AN APPROPRI-
ATE ADMINISTRATOR WHEN THRESHOLDS ARE EXCEEDED, AND TO INI-
TIATE ACTIONS WHICH WILL RESULT IN TERMINATION OF THE EVENT
IF THE ACCUMULATION CONTINUES. FOR EXAMPLE, WHEN THE THRES-
HOLD OF UNSUCCESSFUL LOGIN ATTEMPTS WITHIN A PERIOD OF TIME
IS EXCEEDED, LOGIN SHALL BE INHIBITED FOR A SPECIFIC TIME
PERIOD.
+ 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. Identification of covert channel
events is addressed in the Covert Channel Analysis section.
BECAUSE OF CONCURRENCY AND SYNCHRONIZATION PROBLEMS, IT
MAY NOT BE POSSIBLE TO DETECT IN REAL TIME THE ACCUMULATION
OF SECURITY AUDITABLE EVENTS THAT ARE OCCURRING IN DIFFERENT
NTCB PARTITIONS. HOWEVER, EACH NTCB PARTITION THAT HAS BEEN
ALLOCATED AUDIT RESPONSIBILITY MUST HAVE THE CAPABILITY TO
DETECT THE LOCAL ACCUMULATION OF EVENTS, TO NOTIFY THE PAR-
TITION SECURITY ADMINISTRATOR AND/OR THE NETWORK SECURITY
ADMINISTRATOR, AND TO INITIATE ACTIONS WHICH WILL RESULT IN
TERMINATION OF THE EVENT LOCALLY.
3.3.3 Assurance
_ _ _ _________
3.3.3.1 Operational Assurance
3.3.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). The TCB
shall maintain process isolation through the provision of
distinct address spaces under its control. The TCB shall be
internally structured into well-defined largely independent
modules. It shall make effective use of available hardware
to separate those elements that are protection-critical from
those that are not. The TCB modules shall be designed such
that the principle of least privilege is enforced. Features
in hardware, such as segmentation, shall be used to support
logically distinct storage objects with separate attributes
(namely: readable, writable). The user interface to the TCB
shall be completely defined and all elements of the TCB
identified. THE TCB SHALL BE DESIGNED AND STRUCTURED TO
USE A COMPLETE, CONCEPTUALLY SIMPLE PROTECTION MECHANISM
WITH PRECISELY DEFINED SEMANTICS. THIS MECHANISM SHALL PLAY
A CENTRAL ROLE IN ENFORCING THE INTERNAL STRUCTURING OF THE
TCB AND THE SYSTEM. THE TCB SHALL INCORPORATE SIGNIFICANT
USE OF LAYERING, ABSTRACTION AND DATA HIDING. SIGNIFICANT
SYSTEM ENGINEERING SHALL BE DIRECTED TOWARD MINIMIZING THE
COMPLEXITY OF THE TCB AND EXCLUDING FROM THE TCB MODULES
THAT ARE NOT PROTECTION-CRITICAL.
+ 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. Since each component is itself a dis-
tinct domain in the overall network system, this also satis-
fies the requirement for process isolation through distinct
address spaces in the special case where a component has
only a single subject.
The NTCB must be internally structured into well-
defined largely independent modules and meet the hardware
requirements. This is satisfied by having each NTCB parti-
tion so structured. The NTCB controls all network resources.
These resources 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 protected against external interference or tamper-
ing. For example, a cryptographic checksum or physical
means may be employed to protect user authentication data
exchanged between NTCB partitions.
Each NTCB partition must enforce the principle of least
privilege within its component. Additionally, the NTCB must
be structured so that the principle of least privilege is
enforced in the system as a whole.
THE NTCB MUST BE DESIGNED AND STRUCTURED ACCORDING TO
THE NETWORK SECURITY ARCHITECTURE TO USE A COMPLETE, CONCEP-
TUALLY SIMPLE PROTECTION MECHANISM. FURTHERMORE, EACH NTCB
PARTITION MUST ALSO BE SO DESIGNED AND STRUCTURED.
SIGNIFICANT SYSTEM ENGINEERING SHOULD BE DIRECTED
TOWARD MINIMIZING THE COMPLEXITY OF EACH NTCB PARTITION, AND
OF THE NTCB. CARE SHALL BE TAKEN TO EXCLUDE MODULES (AND
COMPONENTS) THAT ARE NOT PROTECTION-CRITICAL FROM THE NTCB.
IT IS RECOGNIZED THAT SOME MODULES AND/OR COMPONENTS
MAY NEED TO BE INCLUDED IN THE NTCB AND MUST MEET THE NTCB
REQUIREMENTS EVEN THOUGH THEY MAY NOT APPEAR TO BE DIRECTLY
PROTECTION-CRITICAL. THE CORRECT OPERATION OF THESE
MODULES/COMPONENTS IS NECESSARY FOR THE CORRECT OPERATION OF
THE PROTECTION-CRITICAL MODULES AND COMPONENTS. HOWEVER,
THE NUMBER AND SIZE OF THESE MODULES/COMPONENTS SHOULD BE
KEPT TO A MINIMUM.
Each NTCB partition provides isolation of resources
(within its component) in accord with the network system
architecture and security policy so that "supporting ele-
ments" (e.g., DAC and user identification) for the security
mechanisms of the network system are strengthened compared
to C2, from an assurance point of view, through the provi-
sion of distinct address spaces under control of the NTCB.
As discussed in the Discretionary Access Control sec-
tion, 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. When distributed in NTCB sub-
jects (i.e., when outside the reference monitor), the
assurance requirements for the design and implementation of
the DAC shall be those of class C2 for all networks of class
C2 or above.
+ Rationale
The requirement that the NTCB be structured into
modules and meet the hardware requirements applies within
the NTCB partitions in the various components.
The principle of least privilege requires that each
user or other individual with access to the system be given
only those resources and authorizations required for the
performance of this job. In order to enfore this principle
in the system it must be enforced in every NTCB partition
that supports users or other individuals. For example,
prohibiting access by administrators to objects outside the
NTCB partition (e.g., games) lessens the opportunity of dam-
age by a Trojan Horse.
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.
THERE ARE CERTAIN PARTS OF A NETWORK (MODULES AND/OR
COMPONENTS) THAT MAY NOT APPEAR TO BE DIRECTLY PROTECTION-
CRITICAL IN THAT THEY ARE NOT INVOLVED IN ACCESS CONTROL
DECISIONS, DO NOT DIRECTLY AUDIT, AND ARE NOT INVOLVED IN
THE IDENTIFICATION/AUTHENTICATION PROCESS. HOWEVER, THE
SECURITY OF THE NETWORK MUST DEPEND ON THE CORRECT OPERATION
OF THESE MODULES AND/OR COMPONENTS. AN EXAMPLE OF THIS IS A
SINGLE LEVEL PACKET SWITCH. ALTHOUGH IT MAY NOT NORMALLY BE
INVOLVED DIRECTLY IN ENFORCING THE DISCRETIONARY SECURITY
POLICY, THIS SWITCH MAY BE TRUSTED NOT TO MIX DATA FROM DIF-
FERENT MESSAGE STREAMS. IF THE SWITCH DOES NOT OPERATE
CORRECTLY, DATA COULD GET MIXED, AND UNAUTHORIZED ACCESS
COULD RESULT. THEREFORE, THESE MODULES/COMPONENTS MUST BE
INCLUDED IN THE NTCB AND MUST MEET THE NTCB REQUIREMENTS
APPLICABLE TO THE POLICY ELEMENT(S) FOR WHICH THEY ARE
RESPONSIBLE.
3.3.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 mandatory and dis-
cretionary access control policy in a network may require
communication between trusted subjects that are part of the
NTCB partitions in different components. This communication
is normally 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.
IT SHOULD BE CLEAR THAT SOME INTEGRITY AND DENIAL OF
SERVICE FEATURES CAN RESIDE OUTSIDE THE NTCB. OTHERWISE ALL
SOFTWARE IN A NETWORK WOULD BE IN THE NTCB. EVERY PIECE OF
SOFTWARE THAT HAS AN OPPORTUNITY TO WRITE TO SOME DATA OR
PROTOCOL FIELD IS "TRUSTED" TO PRESERVE INTEGRITY OR NOT
CAUSE DENIAL OF SERVICE TO SOME EXTENT. FOR EXAMPLE, IT IS
NECESSARY TO "TRUST" TELNET TO CORRECTLY TRANSLATE USER
DATA, AND TO EVENTUALLY TRANSMIT PACKETS. FTP ALSO HAS TO
BE "TRUSTED" TO NOT INAPPROPRIATELY MODIFY FILES, AND TO
ATTEMPT TO COMPLETE THE FILE TRANSFER. THESE PROTOCOLS CAN
BE DESIGNED, HOWEVER TO EXIST OUTSIDE THE NTCB (FROM A PRO-
TECTION PERSPECTIVE). IT IS BENEFICIAL TO DO THIS TYPE OF
SECURITY ENGINEERING SO THAT THE AMOUNT OF CODE THAT MUST BE
TRUSTED TO NOT DISCLOSE DATA IS MINIMIZED. PUTTING EVERY-
THING INSIDE THE NTCB CONTRADICTS THE REQUIREMENT TO PERFORM
"SIGNIFICANT SYSTEM ENGINEERING ... DIRECTED TOWARD ...
EXCLUDING FROM THE TCB MODULES THAT ARE NOT PROTECTION CRIT-
ICAL," WHICH REMOVES THE PRIMARY DIFFERENCE BETWEEN B2 AND
B3. IF EVERYTHING HAS TO BE IN THE TCB TO ENSURE DATA
INTEGRITY AND PROTECTION AGAINST DENIAL OF SERVICE, THERE
WILL BE CONSIDERABLY LESS ASSURANCE THAT DISCLOSURE PROTEC-
TION IS MAXIMIZED.
3.3.3.1.3 Covert Channel Analysis
+ Statement from DoD 5200.28-STD
The system developer shall conduct a thorough search for
COVERT CHANNELS and make a determination (either by actual
measurement or by engineering estimation) of the maximum
bandwidth of each identified channel. (See the Covert Chan-
nels Guideline section.)
+ Interpretation
The requirement, including the TCSEC Covert Channel
Guideline, applies as written. In a network, there are
additional instances of covert channels associated with com-
munication between components.
+ Rationale
The exploitation of network protocol information (e.g.,
headers) can result in covert storage channels. EXPLOITATION
OF FREQUENCY OF TRANSMISSION CAN RESULT IN COVERT TIMING
CHANNELS. The topic has been addressed in the literature.-
3.3.3.1.4 Trusted Facility Management
+ Statement from DoD 5200.28-STD
The TCB shall support separate operator and administrator
functions. THE FUNCTIONS PERFORMED IN THE ROLE OF A SECU-
RITY ADMINISTRATOR SHALL BE IDENTIFIED. THE ADP SYSTEM
ADMINISTRATIVE PERSONNEL SHALL ONLY BE ABLE TO PERFORM SECU-
RITY ADMINISTRATOR FUNCTIONS AFTER TAKING A DISTINCT AUDIT-
ABLE ACTION TO ASSUME THE SECURITY ADMINISTRATOR ROLE ON THE
ADP SYSTEM. NON-SECURITY FUNCTIONS THAT CAN BE PERFORMED IN
THE SECURITY ADMINISTRATION ROLE SHALL BE LIMITED STRICTLY
TO THOSE ESSENTIAL TO PERFORMING THE SECURITY ROLE EFFEC-
TIVELY.
_________________________
- See, for example, Girling, C. G., "Covert Channels
in LAN's," IEEE Transactions on Software Engineering,
____ ____________ __ ________ ___________
Vol. SE-13, No. 2, February 1987; and Padlipsky, M. A.,
Snow, D. P., and Karger, P. A., Limitations of End-to-
___________ __ ___ __
End Encryption in Secure Computer Networks, MITRE
___ __________ __ ______ ________ ________
Technical Report, MTR-3592, Vol. I, May 1978 (ESD TR
78-158, DTIC AD A059221).
+ Interpretation
This requirement applies as written to both the network
as a whole and to individual components which support such
personnel.
+ Rationale
It is recognized that based on the allocated policy
elements some components may operate with no human inter-
face.
3.3.3.1.5 Trusted Recovery
+ Statement from DoD 5200.28-STD
PROCEDURES AND/OR MECHANISMS SHALL BE PROVIDED TO ASSURE
THAT, AFTER AN ADP SYSTEM FAILURE OR OTHER DISCONTINUITY,
RECOVERY WITHOUT A PROTECTION COMPROMISE IS OBTAINED.
+ Interpretation
THE RECOVERY PROCESS MUST BE ACCOMPLISHED WITHOUT A
PROTECTION COMPROMISE AFTER THE FAILURE OR OTHER DISCON-
TINUITY OF ANY NTCB PARTITION. IT MUST ALSO BE ACCOMPLISHED
AFTER A FAILURE OF THE ENTIRE NTCB.
+ Rationale
THIS IS A STRAIGHT-FORWARD EXTENSION OF THE REQUIREMENT
INTO THE NETWORK CONTEXT, AND TAKES INTO ACCOUNT THAT IT IS
POSSIBLE FOR PARTS OF THE SYSTEM TO FAIL WHILE OTHER PARTS
CONTINUE TO OPERATE NORMALLY. THIS MAY BE A SECURITY-
RELEVANT EVENT; IF SO IT MUST BE AUDITED.
3.3.3.2 Life-Cycle Assurance
3.3.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. A
team of individuals who thoroughly understand the specific
implementation of the TCB shall subject its design documen-
tation, source code, and object code to through analysis and
testing. Their objectives shall be: to uncover all design
and implementation flaws that would permit a subject exter-
nal to the TCB to read, change, or delete data normally
denied under the mandatory or discretionary security policy
enforced by the TCB; as well as to assure that no subject
(without authorization to do so) is able to cause the TCB to
enter a state such that it is unable to respond to
communications initiated by other users. The TCB shall be
FOUND RESISTANT to penetration. All discovered flaws shall
be removed or neutralized and the TCB retested to demon-
strate that they have been eliminated and that new flaws
have not been introduced. Testing shall demonstrate that the
TCB implementation is consistent with the descriptive top-
level specification. NO DESIGN FLAWS AND NO MORE THAN A FEW
CORRECTABLE IMPLEMENTATION FLAWS MAY BE FOUND DURING TESTING
AND THERE SHALL BE REASONABLE CONFIDENCE THAT FEW REMAIN.
(See the Security Testing Guidelines.)
+ Interpretation
Testing of a component will require a testbed that
exercises the interfaces and protocols of the component
including tests under exceptional conditions. 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 partition that
implement the given mechanism. This integrated testing is
additional to any individual component tests involved in the
evaluation of the network system. The sponsor should iden-
tify 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 configura-
tions. A change in configuration within the allowable set
of configurations does not require retesting.
The testing of each component will include the intro-
duction of subjects external to the NTCB partition for the
component that will attempt to read, change, or delete data
normally denied. If the normal interface to the component
does not provide a means to create the subjects needed to
conduct such a test, then this portion of the testing shall
use a special version of the untrusted software for the com-
ponent that results in subjects that make such attempts.
The results shall be saved for test analysis. Such special
versions shall have an NTCB partition that is identical to
that for the normal configuration of the component under
evaluation.
The testing of the mandatory controls shall include
tests to demonstrate that the labels for information
imported and/or exported to/from the component accurately
represent the labels maintained by the NTCB partition for
the component for use as the basis for its mandatory access
control decisions. The tests shall include each type of
device, whether single-level or multilevel, supported by the
component.
The NTCB must be FOUND RESISTANT to penetration. This
applies to the NTCB as a whole, and to each NTCB partition
in a component of this class.
+ Rationale
The phrase "no subject (without authorization to do so)
is able to cause the TCB to enter a state such that it is
unable to respond to communications initiated by other
users" relates to the security services (Part II of this
TNI) for the Denial of Service problem, and to correctness
of the protocol implementations.
Testing is an important method available in this
evaluation division to gain any assurance that the security
mechanisms perform their intended function. A major purpose
of testing is to demonstrate the system's response to inputs
to the NTCB partition from untrusted (and possibly mali-
cious) subjects.
In contrast to general purpose systems that allow for
the dynamic creation of new programs and the introductions
of new processes (and hence new subjects) with user speci-
fied security properities, many network components have no
method for introducing new programs and/or processes during
their normal operation. Therefore, the programs necessary
for the testing must be introduced as special versions of
the software rather than as the result of normal inputs by
the test team. However, it must be insured that the NTCB
partition used for such tests is identical to the one under
evaluation.
Sensitivity labels serve a critical role in maintaining
the security of the mandatory access controls in the net-
work. Especially important to network security is the role
of the labels for information communicated between com-
ponents - explicit labels for multilevel devices and impli-
cit labels for single-level devices. Therefore the testing
for correct labels is highlighted.
The requirement for testing to demonstrate consistency
between the NTCB implementation and the DTLS is a straight-
forward extension of the TCSEC requirement into the context
of a network system.
3.3.3.2.2 Design Specification and Verification
+ Statement from DoD 5200.28-STD
A formal model of the security policy supported by the TCB
shall be maintained over the life cycle of the ADP system
that is proven and demonstrated to be consistent with its
axioms. A descriptive top-level specification (DTLS) of the
TCB shall be maintained that completely and accurately
describes the TCB in terms of exceptions, error messages,
and effects. It shall be shown to be an accurate descrip-
tion of the TCB interface. A CONVINCING ARGUMENT SHALL BE
GIVEN THAT THE DTLS IS CONSISTENT WITH THE MODEL.
+ Interpretation
The overall network security policy expressed in this
model will provide the basis for the mandatory access con-
trol policy exercised by the NTCB over subjects and storage
objects in the entire network. The policy will also be the
basis for the discretionary access control policy exercised
by the NTCB to control access of named users to named
objects. Data integrity requirements addressing the effects
of unauthorized MSM need not be included in this model. The
overall network policy must be decomposed into policy ele-
ments that are allocated to appropriate components and used
as the basis for the security policy model for those com-
ponents.
The level of abstraction of the model, and the set of
subjects and objects that are explicitly represented in the
model, will be affected by the NTCB partitioning. Subjects
and objects must be represented explicitly in the model for
the partition if there is some network component whose NTCB
partition exercises access control over them. The model
shall be structured so that the axioms and entities applica-
ble to individual network components are manifest. Global
network policy elements that are allocated to components
shall be represented by the model for that component.
The requirements for a network DTLS are given in the
Design Documentation section.
+ Rationale
The treatment of the model depends to a great extent on
the degree of integration of the communications service into
a distributed system. In a closely coupled distributed sys-
tem, one might use a model that closely resembles one
appropriate for a stand-alone computer system.
In ALL cases, the model of each partition will be
expected to show the role of the NTCB partition in each kind
of component. It will most likely clarify the model,
although not part of the model, to show access restrictions
implied by the system design; for example, subjects
representing protocol entities might have access only to
objects containing data units at the same layer of protocol.
The allocation of subjects and objects to different proto-
col layers is a protocol design choice which need not be
reflected in the security policy model.
3.3.3.2.3 Configuration Management
+ Statement from DoD 5200.28-STD
During development and maintenance of the TCB, a configura-
tion management system shall be in place that maintains con-
trol of changes to the descriptive top-level specification,
other design data, implementation documentation, source
code, the running version of the object code, and test fix-
tures and documentation. The configuration management sys-
tem shall assure a consistent mapping among all documenta-
tion and code associated with the current version of the
TCB. Tools shall be provided for generation of a new ver-
sion of the TCB from source code. Also available shall be
tools for comparing a newly generated version with the pre-
vious TCB version in order to ascertain that only the
intended changes have been made in the code that will actu-
ally be used as the new version of the TCB.
+ Interpretation
The requirement applies as written, with the following
extensions:
1. A configuration management system must be in place
for each NTCB partition.
2. A configuration management plan must exist for the
entire system. If the configuration management sys-
tem is made up of the conglomeration of the confi-
guration management systems of the various NTCB par-
titions, then the configuration management plan must
address the issue of how configuration control is
applied to the system as a whole.
+ Rationale
Each NTCB partition must have a configuration manage-
ment system in place, or else there will be no way for the
NTCB as a whole to have an effective configuration manage-
ment system. The other extensions are merely reflections of
the way that networks operate in practice.
3.3.4 Documentation.
_ _ _ _____________
3.3.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.
3.3.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. The procedures
for examining and maintaining the audit files as well as the
detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and
administrator functions related to security, to include
changing the security characteristics of a user. It shall
provide interpretations on the consistent and effective use
of the protection features of the system, how they interact,
how to securely generate a new TCB, and facility procedures,
warnings, and privileges that need to be controlled in order
to operate the facility in a secure manner. The TCB modules
that contain the reference validation mechanism shall be
identified. The procedures for secure generation of a new
TCB from source after modification of any modules in the TCB
shall be described. IT SHALL INCLUDE THE PROCEDURES TO
ENSURE THAT THE SYSTEM IS INITIALLY STARTED IN A SECURE
MANNER. PROCEDURES SHALL ALSO BE INCLUDED TO RESUME SECURE
SYSTEM OPERATION AFTER ANY LAPSE IN SYSTEM OPERATION.
+ 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).
6. Incremental updates; that is, it must explicitly
indicate which components of the network may change
without others also changing.
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).
The components of the network that form the NTCB must
be identified. Furthermore, the modules within an NTCB par-
tition that contain the reference validation mechanism (if
any) within that partition must be identified.
The procedures for the secure generation of a new ver-
sion (or copy) of each NTCB partition from source must be
described. The procedures and requirements for the secure
generation of the NTCB necessitated by changes in the net-
work configuration shall be described.
PROCEDURES FOR STARTING EACH NTCB PARTITION IN A SECURE
STATE SHALL BE SPECIFIED. PROCEDURES MUST ALSO BE INCLUDED
TO RESUME SECURE OPERATION OF EACH NTCB PARTITION AND/OR THE
NTCB AFTER ANY LAPSE IN SYSTEM OR SUBSYSTEM OPERATION.
+ 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.
As mentioned in the section on Label Integrity, cryp-
tography is one common mechanism employed to protect commun-
ication 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.
The requirements for descriptions of NTCB generation
and identification of modules and components that form the
NTCB are straightforward extensions of the TCSEC require-
ments into the network context. In those cases where the
vendor does not provide source code, an acceptable procedure
shall be to request the vendor to perform the secure genera-
tion.
GIVEN THE NATURE OF NETWORK SYSTEMS (E.G., VARIOUS COM-
PONENTS TEND TO BE DOWN AT DIFFERENT TIMES, AND THE NETWORK
SYSTEM MUST CONTINUE OPERATION WITHOUT THAT COMPONENT), IT
IS IMPERATIVE TO KNOW BOTH HOW TO SECURELY START UP AN NTCB
PARTITION, AND HOW TO RESUME OPERATION SECURELY. IT IS ALSO
NECESSARY TO KNOW HOW TO RESUME SECURE OPERATION OF THE NTCB
AFTER ANY PARTITION HAS BEEN DOWN.
3.3.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. It shall include
results of testing the effectiveness of the methods used to
reduce covert channel bandwidths.
+ 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.
The bandwidths of covert channels are used to determine
the suitability of a network system for a given environment.
The effectiveness of the methods used to reduce these
bandwidths must therefore be accurately determined.
3.3.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.
The interfaces between the TCB modules shall be described.
A formal description of the security policy model enforced
by the TCB shall be available and an explanation provided to
show that it is sufficient to enforce the security policy.
The specific TCB protection mechanisms shall be identified
and an explanation given to show that they satisfy the
model. The descriptive top-level specification (DTLS) shall
be shown to be an accurate description of the TCB interface.
Documentation shall describe how the TCB implements the
reference monitor concept and give an explanation why it is
tamper resistant, cannot be bypassed, and is correctly
implemented. THE TCB IMPLEMENTATION (I.E., IN HARDWARE,
FIRMWARE, AND SOFTWARE) SHALL BE INFORMALLY SHOWN TO BE CON-
SISTENT WITH THE DTLS. THE ELEMENTS OF THE DTLS SHALL BE
SHOWN, USING INFORMAL TECHNIQUES, TO CORRESPOND TO THE ELE-
MENTS OF THE TCB. Documentation shall describe how the TCB
is structured to facilitate testing and to enforce least
privilege. This documentation shall also present the
results of the covert channel analysis and the tradeoffs
involved in restricting the channels. All auditable events
that may be used in the exploitation of known covert storage
channels shall be identified. The bandwidths of known
covert storage channels, the use of which is not detectable
by the auditing mechanisms, shall be provided. (See the
Covert Channel Guideline section.)
+ 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.
The documentation includes both a system description
and a set of component DTLS's. The system description
addresses the network security architecture and design by
specifying the types of components in the network, which
ones are trusted, and in what way they must cooperate to
support network security objectives. A component DTLS shall
be provided for each trusted network component, i.e., each
component containing an NTCB partition. Each component DTLS
shall describe the interface to the NTCB partition of its
component. BOTH THE SYSTEM DESCRIPTION AND EACH COMPONENT
DTLS SHALL BE SHOWN CONSISTENT WITH THOSE ASSERTIONS IN THE
MODEL THAT APPLY TO IT. Appendix A addresses component
evaluation issues.
TO SHOW THE CORRESPONDENCE BETWEEN THE DTLS AND THE
NTCB IMPLEMENTATION, IT SUFFICES TO SHOW CORRESPONDENCE
BETWEEN EACH COMPONENT DTLS AND THE NTCB PARTITION IN THAT
COMPONENT.
As stated in the introduction to Division B, the spon-
sor must demonstrate that the NTCB employs the reference
monitor concept. The security policy model must be a model
for a reference monitor.
The security policy model for each partition implement-
ing a reference monitor shall fully represent the access
control policy supported by the partition, including the
discretionary and mandatory security policy for secrecy
and/or integrity. For the mandatory policy the single domi-
nance relation for sensitivity labels, including secrecy
and/or integrity components, shall be precisely defined.
+ 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 specifica-
tions will in fact be trusted, that is, it will be evaluat-
able under these interpretations.
The term "model" is used in several different ways in a
network context, e.g., a "protocol reference model," a "for-
mal network model," etc. Only the "security policy model" is
addressed by this requirement and is specifically intended
to model the interface, viz., "security perimeter," of the
reference monitor and must meet all the requirements defined
in the TCSEC. It must be shown that all parts of the TCB
are a valid interpretation of the security policy model,
i.e., that there is no change to the secure state except as
represented by the model.
4.0 DIVISION A: VERIFIED PROTECTION
_ _ ________ _ ________ __________
This division is characterized by the use of formal security
methods to assure that the mandatory and discretionary secu-
rity controls employed in the network system can effectively
protect classified or other sensitive information stored or
processed by the system. Extensive documentation is re-
quired to demonstrate that the NTCB meets the security re-
quirements in all aspects of design, development and imple-
mentation.
4.1 CLASS (A1): VERIFIED DESIGN
_ _ _____ __ ________ ______
SYSTEMS IN CLASS (A1) ARE FUNCTIONALLY EQUIVALENT
TO THOSE IN CLASS (B3) IN THAT NO ADDITIONAL
ARCHITECTURAL FEATURES OR POLICY REQUIREMENTS ARE
ADDED. THE DISTINGUISHING FEATURE OF SYSTEMS IN
THIS CLASS IS THE ANALYSIS DERIVED FROM FORMAL
DESIGN SPECIFICATION AND VERIFICATION TECHNIQUES
AND THE RESULTING HIGH DEGREE OF ASSURANCE THAT
THE NTCB IS CORRECTLY IMPLEMENTED. THIS ASSURANCE
IS DEVELOPMENTAL IN NATURE, STARTING WITH A FORMAL
MODEL OF THE SECURITY POLICY AND A FORMAL TOP-
LEVEL SPECIFICATION (FTLS) OF THE DESIGN.
INDEPENDENT OF THE PARTICULAR SPECIFICATION
LANGUAGE OR VERIFICATION SYSTEM USED, THERE ARE
FIVE IMPORTANT CRITERIA FOR CLASS (A1) DESIGN
VERIFICATION:
+ A FORMAL MODEL OF THE SECURITY POLICY MUST BE
CLEARLY IDENTIFIED AND DOCUMENTED, INCLUDING A
MATHEMATICAL PROOF THAT THE MODEL IS CONSISTENT
WITH ITS AXIOMS AND IS SUFFICIENT TO SUPPORT THE
SECURITY POLICY.
+ AN FTLS MUST BE PRODUCED THAT INCLUDES ABSTRACT
DEFINITIONS OF THE FUNCTIONS THE NTCB PERFORMS
AND OF THE HARDWARE AND/OR FIRMWARE MECHANISMS
THAT ARE USED TO SUPPORT SEPARATE EXECUTION
DOMAINS.
+ THE FTLS OF THE NTCB MUST BE SHOWN TO BE CON-
SISTENT WITH THE MODEL BY FORMAL TECHNIQUES WHERE
POSSIBLE (I.E., WHERE VERIFICATION TOOLS EXIST)
AND INFORMAL ONES OTHERWISE.
+ THE NTCB IMPLEMENTATION (I.E., IN HARDWARE,
FIRMWARE, AND SOFTWARE) MUST BE INFORMALLY SHOWN
TO BE CONSISTENT WITH THE FTLS. THE ELEMENTS OF
THE FTLS MUST BE SHOWN, USING INFORMAL TECH-
NIQUES, TO CORRESPOND TO THE ELEMENTS OF THE
NTCB. THE FTLS MUST EXPRESS THE UNIFIED PROTEC-
TION MECHANISM REQUIRED TO SATISFY THE SECURITY
POLICY, AND IT IS THE ELEMENTS OF THIS PROTECTION
MECHANISM THAT ARE MAPPED TO THE ELEMENTS OF THE
NTCB.
+ FORMAL ANALYSIS TECHNIQUES MUST BE USED TO IDEN-
TIFY AND ANALYZE COVERT CHANNELS. INFORMAL TECH-
NIQUES MAY BE USED TO IDENTIFY COVERT TIMING
CHANNELS. THE CONTINUED EXISTENCE OF IDENTIFIED
COVERT CHANNELS IN THE SYSTEM MUST BE JUSTIFIED.
IN KEEPING WITH THE EXTENSIVE DESIGN AND DEVELOP-
MENT ANALYSIS OF THE NTCB REQUIRED OF SYSTEMS IN
CLASS (A1), MORE STRINGENT CONFIGURATION MANAGE-
MENT IS REQUIRED AND PROCEDURES ARE ESTABLISHED
FOR SECURELY DISTRIBUTING THE SYSTEM TO SITES. A
SYSTEM SECURITY ADMINISTRATOR IS SUPPORTED.
THE FOLLOWING ARE MINIMAL REQUIREMENTS FOR SYSTEM
ASSIGNED A CLASS (A1) RATING:
4.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 and mandatory
requirements applicable to this class. The policy may
require data secrecy, or data integrity, or both. The pol-
icy is an access control policy having two primary com-
ponents: mandatory and discretionary. The policy shall
include a discretionary policy for protecting the informa-
tion being processed based on the authorizations of indivi-
duals, users, or groups of users. This access control pol-
icy statement shall describe the requirements on the network
to prevent or detect "reading or destroying" sensitive
information by unauthorized users or errors. The mandatory
policy must define the set of distinct sensitivity levels
that it supports. For the Class B1 or above the mandatory
policy shall be based on the labels associated with the
information that reflects its sensitivity with respect to
secrecy and/or integrity, where applicable, and labels asso-
ciated with users to reflect their authorization to access
such information. 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 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 and mandatory secrecy
policy that is enforced in the network to prevent
unauthorized users from reading the sensitive infor-
mation entrusted to the network.
DATA INTEGRITY POLICY: The network sponsor shall
define the discretionary and mandatory integrity
policy to prevent unauthorized users from modifying,
viz., writing, sensitive information. The defini-
tion of data integrity presented by the network
sponsor refers to the requirement that the informa-
tion has not been subjected to unauthorized modifi-
cation in the network. The mandatory integrity pol-
icy enforced by the NTCB cannot, in general, prevent
modification while information is being transmitted
between components. However, an integrity sensi-
tivity label may reflect the confidence that the
information has not been subjected to transmission
errors because of the protection afforded during
transmission. This requirement is distinct from the
requirement for label integrity.
+ 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.
The mandatory integrity policy (at class B1 and above)
in some architectures may be useful in supporting the link-
age between the connection oriented abstraction introduced
in the Introduction and the individual components of the
network. For example, in a key distribution center for
end-to-end encryption, a distinct integrity category may be
assigned to isolate the key generation code and data from
possible modification by other supporting processes in the
same component, such as operator interfaces and audit.
The mandatory integrity policy for some architecture
may define an integrity sensitivity label that reflects the
specific requirements for ensuring that information has not
been subject to random errors in excess of a stated limit
nor to unauthorized message stream modification (MSM) -.
The specific metric associated with an integrity sensitivity
label will generally reflect the intended applications of
the network.
4.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., access control lists)
shall allow users to specify and control sharing of those
objects and shall provide controls to limit propagation of
access rights. The discretionary access control mechanism
shall, either by explicit user action or by default, provide
that objects are protected from unauthorized access. These
access controls shall be capable of specifying, for each
named object, a list of named individuals and a list of
groups of named individuals with their respective modes of
access to that object. Furthermore, for each such named
object, it shall be possible to specify a list of named
individuals and a list of groups of named individuals for
which no access to the object is given. Access permission
to an object by users not already possessing access
_________________________
- See Voydock, Victor L. and Stephen T. Kent, "Secu-
rity Mechanisms in High-Level Network Protocols," Com-
___
puting Surveys, Vol. 15, No. 2, June 1983, pp 135-171.
______ _______
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.
There are two forms of distribution for the DAC mechan-
ism: implementing portions of the DAC in separate com-
ponents, and supporting the DAC in subjects contained within
the NTCB partition in a component. Since "the ADP system"
is understood to be "the computer network" as a whole, each
network component is responsible for enforcing security in
the mechanisms allocated to it to ensure secure implementa-
tion of the network security policy. For traditional host
systems it is frequently easy to also enforce the DAC along
with the MAC within the reference monitor, per se, although
a few approaches, such as virtual machine monitors, support
DAC outside this interface.
In contrast to the universally rigid structure of man-
datory policies (see the Mandatory Access Control section),
DAC policies tend to be very network and system specific,
with features that reflect the natural use of the system.
For networks it is common that individual hosts will impose
controls over their local users on the basis of named
individuals-much like the controls used when there is no
network connection. However, it is difficult to manage in a
centralized manner all the individuals using a large net-
work. Therefore, users on other hosts are commonly grouped
together so that the controls required by the network DAC
policy are actually based on the identity of the hosts or
other components. A gateway is an example of such a com-
ponent.
The assurance requirements are at the very heart of the
concept of a trusted system. It is the assurance that
determines if a system or network is appropriate for a given
environment, as reflected, for example, in the Environments
Guideline-. In the case of monolithic systems that have DAC
integral to the reference monitor, the assurance require-
ments for DAC are inseparable from those of the rest of the
reference monitor. For networks there is typically a much
clearer distinction due to distributed DAC. The rationale
for making the distinction in this network interpretation is
that if major trusted network components can be made signi-
ficantly easier to design and implement without reducing the
ability to meet security policy, then trusted networks will
be more easily available.
4.1.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.
_________________________
- Guidance for Applying the Department of Defense
________ ___ ________ ___ __________ __ _______
Trusted Computer System Evaluation Criteria in Specific
_______ ________ ______ __________ ________ __ ________
Environments, CSC-STD-003-85.
____________
+ 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.
4.1.1.3 Labels
+ Statement from DoD 5200.28-STD
Sensitivity labels associated with each ADP system resource
(e.g., subject, storage object, ROM) that is directly or
indirectly accessible by subjects external to the TCB shall
be maintained by the TCB. These labels shall be used as the
basis for mandatory access control decisions. In order to
import non-labeled data, the TCB shall request and receive
from an authorized user the sensitivity level of the data,
and all such actions shall be auditable by the TCB.
+ Interpretation
Non-labeled data imported under the control of the NTCB
partition will be assigned a label constrained by the device
labels of the single-level device used to import it. Labels
may include secrecy and integrity- components in accordance
with the overall network security policy described by the
network sponsor. Whenever the term "label" is used
throughout this interpretation, it is understood to include
both components as applicable. Similarly, the terms
"single-level" and "multilevel" are understood to be based
on both the secrecy and integrity components of the policy.
The mandatory integrity policy will typically have require-
ments, such as the probability of undetected message stream
modification, that will be reflected in the label for the
data so protected. For example, when data is imported its
integrity label may be assigned based on mechanisms, such as
cryptography, used to provide the assurance required by the
policy. The NTCB shall assure that such mechanism are pro-
tected from tampering and are always invoked when they are
_________________________
- See, for example, Biba, K.J., "Integrity Considera-
tion for Secure Computer Systems," ESD-TR-76-372, MTR-
3153, The MITRE Corporation, Bedford, MA, April 1977.
the basis for a label.
If the security policy includes an integrity policy,
all activities that result in message-stream modification
during transmission are regarded as unauthorized accesses in
violation of the integrity policy. The NTCB shall have an
automated capability for testing, detecting, and reporting
those errors/corruptions that exceed specified network
integrity policy requirements. Message-stream modification
(MSM) countermeasures shall be identified. A technology of
adequate strength shall be selected to resist MSM. If
encryption methodologies are employed, they shall be
approved by the National Security Agency.
All objects must be labeled within each component of
the network that is trusted to maintain separation of multi-
ple levels of information. The label associated with any
objects associated with single-level components will be
identical to the level of that component. Objects used to
store network control information, and other network struc-
tures, such as routing tables, must be labeled to prevent
unauthorized access and/or modification.
+ Rationale
The interpretation is an extension of the requirement
into the context of a network system and partitioned NTCB as
defined for these network interpretations. A single-level
device may be regarded either as a subject or an object. A
multilevel device is regarded as a trusted subject in which
the security range of the subject is the minimum-maximum
range of the data expected to be transmitted over the dev-
ice.
The sensitivity labels for either secrecy or integrity
or both may reflect non-hierarchical categories or hierarch-
ical classification or both.
For a network it is necessary that this requirement be
applied to all network system resources at the (B2) level
and above.
The NTCB is responsible for implementing the network
integrity policy, when one exists. The NTCB must enforce
that policy by ensuring that information is accurately
transmitted from source to destination (regardless of the
number of intervening connecting points). The NTCB must be
able to counter equipment failure, environmental disrup-
tions, and actions by persons and processes not authorized
to alter the data. Protocols that perform code or format
conversion shall preserve the integrity of data and control
information.
The probability of an undetected transmission error may
be specified as part of the network security policy so that
the acceptability of the network for its intended
application may be determined. The specific metrics (e.g.,
probability of undetected modification) satisfied by the
data can be reflected in the integrity sensitivity label
associated with the data while it is processed within a com-
ponent. It is recognized that different applications and
operational environments (e.g., crisis as compared to logis-
tic) will have different integrity requirements.
The network shall also have an automated capability of
testing for, detecting, and reporting errors that exceed a
threshold consistent with the operational mode requirements.
The effectiveness of integrity countermeasures must be esta-
blished with the same rigor as the other security-relevant
properties such as secrecy.
Cryptography is often utilized as a basis to provide
data integrity assurance. Mechanisms, such as Manipulation
Detection Codes (MDC)-, may be used. The adequacy of the
encryption or MDC algorithm, the correctness of the protocol
logic, and the adequacy of implementation must be esta-
blished in MSM countermeasures design.
4.1.1.3.1 Label Integrity
+ Statement from DoD 5200.28-STD
Sensitivity labels shall accurately represent sensitivity
levels of the specific subjects or objects with which they
are associated. When exported by the TCB, sensitivity
labels shall accurately and unambiguously represent the
internal labels and shall be associated with the information
being exported.
+ Interpretation
The phrase "exported by the TCB" is understood to
include transmission of information from an object in one
component to an object in another component. Information
transferred between NTCB partitions is addressed in the Sys-
tem Integrity Section. The form of internal and external
(exported) sensitivity labels may differ, but the meaning
shall be the same. The NTCB shall, in addition, ensure that
correct association of sensitivity labels with the informa-
tion being transported across the network is preserved.
As mentioned in the Trusted Facility Manual Section,
encryption transforms the representation of information so
that it is unintelligible to unauthorized subjects.
Reflecting this transformation, the sensitivity level of the
ciphertext is generally lower than the cleartext. It fol-
lows that cleartext and ciphertext are contained in
_________________________
- See Jueneman, R. R., "Electronic Document Authenti-
cation," IEEE Network Magazine, April 1987, pp 17-23.
____ _______ ________
different objects, each possessing its own label. The label
of the cleartext must be preserved and associated with the
ciphertext so that it can be restored when the cleartext is
subsequently obtained by decrypting the ciphertext. If the
cleartext is associated with a single-level device, the
label of that cleartext may be implicit. The label may also
be implicit in the key.
When information is exported to an environment where it
is subject to deliberate or accidental modification, the TCB
shall support the means, such as cryptographic checksums, to
assure the accuracy of the labels. When there is a manda-
tory integrity policy, the policy will define the meaning of
integrity labels.
+ Rationale
Encryption algorithms and their implementation are out-
side the scope of these interpretations. Such algorithms
may be implemented in a separate device or may be incor-
porated in a subject of a larger component. Without preju-
dice, either implementation packaging is referred to as an
encryption mechanism herein. If encryption methodologies are
employed in this regard, they shall be approved by the
National Security Agency (NSA). The encryption process is
part of the Network Trusted Computer Base partition in the
components in which it is implemented.
The encryption mechanism is not necessarily a mul-
tilevel device or multilevel subject, as these terms are
used in these criteria. The process of encryption is mul-
tilevel by definition. The cleartext and ciphertext inter-
faces carry information of different sensitivity. An
encryption mechanism does not process data in the sense of
performing logical or arithmetic operations on that data
with the intent of producing new data. The cleartext and
ciphertext interfaces on the encryption mechanism must be
separately identified as being single-level or multilevel.
If the interface is single-level, then the sensitivity of
the data is established by a trusted individual and impli-
citly associated with the interface; the Exportation to
Single-Level Devices criterion applies.
If the interface is multilevel, then the data must be
labeled; the Exportation to Multilevel Devices criterion
applies. The network architect is free to select an accept-
able mechanism for associating a label with an object. With
reference to encrypted objects, the following examples are
possible:
1. Include a label field in the protocol definition of
the object.
2. Implicitly associate the label with the object
through the encryption key. That is, the encryption
key uniquely identifies a sensitivity level. A sin-
gle or private key must be protected at the level of
the data that it encrypts.
4.1.1.3.2 Exportation of Labeled Information
+ Statement from DoD 5200.28-STD
The TCB shall designate each communication channel and I/O
device as either single-level or multilevel. Any change in
this designation shall be done manually and shall be audit-
able by the TCB. The TCB shall maintain and be able to
audit any change in the sensitivity level or levels associ-
ated with a communications channel or I/O device.
+ Interpretation
Each communication channel and network component shall
be designated as either single-level or multilevel. Any
change in this designation shall be done with the cognizance
and approval of the administrator or security officer in
charge of the affected components and the administrator or
security officer in charge of the NTCB. This change shall
be auditable by the network. The NTCB shall maintain and be
able to audit any change in the device labels associated
with a single-level communication channel or the range asso-
ciated with a multilevel communication channel or component.
The NTCB shall also be able to audit any change in the set
of sensitivity levels associated with the information which
can be transmitted over a multilevel communication channel
or component.
+ Rationale
Communication channels and components in a network are
analogous to communication channels and I/O devices in
stand-alone systems. They must be designated as either mul-
tilevel (i.e., able to distinguish and maintain separation
among information of various sensitivity levels) or single-
level. As in the TCSEC, single-level devices may only be
attached to single-level channels.
The level or set of levels of information that can be
sent to a component or over a communication channel shall
only change with the knowledge and approval of the security
officers (or system administrator, if there is no security
officer) of the network, and of the affected components.
This requirement ensures that no significant security-
relevant changes are made without the approval of all
affected parties.
4.1.1.3.2.1 Exportation to Multilevel Devices
+ Statement from DoD 5200.28-STD
When the TCB exports an object to a multilevel I/O device,
the sensitivity label associated with that object shall also
be exported and shall reside on the same physical medium as
the exported information and shall be in the same form
(i.e., machine-readable or human-readable form). When the
TCB exports or imports an object over a multilevel communi-
cations channel, the protocol used on that channel shall
provide for the unambiguous pairing between the sensitivity
labels and the associated information that is sent or
received.
+ Interpretation
The components, including hosts, of a network shall be
interconnected over "multilevel communication channels,"
multiple single-level communication channels, or both, when-
ever the information is to be protected at more than a sin-
gle sensitivity level. The protocol for associating the
sensitivity label and the exported information shall provide
the only information needed to correctly associate a sensi-
tivity level with the exported information transferred over
the multilevel channel between the NTCB partitions in indi-
vidual components. This protocol definition must specify the
representation and semantics of the sensitivity labels
(i.e., the machine-readable label must uniquely represent
the sensitivity level).
The "unambiguous" association of the sensitivity level
with the communicated information shall meet the same level
of accuracy as that required for any other label within the
NTCB, as specified in the criterion for Label Integrity.
This may be provided by protected and highly reliable direct
physical layer connections, or by traditional cryptographic
link protection in which any errors during transmission can
be readily detected, or by use of a separate channel. The
range of information imported or exported must be con-
strained by the associated device labels.
+ Rationale
This protocol must specify the representation and
semantics of the sensitivity labels. See the Mandatory
Access Control Policies section in Appendix B. The mul-
tilevel device interface to (untrusted) subjects may be
implemented either by the interface of the reference moni-
tor, per se, or by a multilevel subject (e.g., a "trusted
subject" as defined in the Bell-LaPadula Model) that pro-
vides the labels based on the internal labels of the NTCB
partition.
The current state of the art limits the support for
mandatory policy that is practical for secure networks.
Reference monitor support to ensure the control over all the
operations of each subject in the network must be completely
provided within the single NTCB partition on which that sub-
ject interfaces to the NTCB. This means that the entire
portion of the "secure state" represented in the formal
security policy model that may be changed by transitions
invoked by this subject must be contained in the same
component.
The secure state of an NTCB partition may be affected
by events external to the component in which the NTCB parti-
tion resides (e.g., arrival of a message). The effect
occurs asynchronusly after being initiated by an event in
another component or partition. For example, indeterminate
delays may occur between the initiation of a message in one
component, the arrival of the message in the NTCB partition
in another component, and the corresponding change to the
secure state of the second component. Since each component
is executing concurrently, to do otherwise would require
some sort of network-wide control to synchronize state tran-
sitions, such as a global network-wide clock for all proces-
sors; in general, such designs are not practical and prob-
ably not even desirable. Therefore, the interaction between
NTCB partitions is restricted to just communications between
pairs (at least logically) of devices-multilevel devices if
the device(s) can send/receive data of more than a single
level. For broadcast channels the pairs are the sender and
intended receiver(s). However, if the broadcast channel
carries multiple levels of information, additional mechanism
(e.g., cryptochecksum maintained by the TCB) may be required
to enforce separation and proper delivery.
A common representation for sensitivity labels is
needed in the protocol used on that channel and understood
by both the sender and receiver when two multilevel devices
(in this case, in two different components) are intercon-
nected. Each distinct sensitivity level of the overall net-
work policy must be represented uniquely in these labels.
Within a monolithic TCB, the accuracy of the sensi-
tivity labels is generally assured by simple techniques,
e.g., very reliable connections over very short physical
connections, such as on a single printed circuit board or
over an internal bus. In many network environments there is
a much higher probability of accidentally or maliciously
introduced errors, and these must be protected against.
4.1.1.3.2.2 Exportation to Single-Level Devices
+ Statement from DoD 5200.28-STD
Single-level I/O devices and single-level communication
channels are not required to maintain the sensitivity labels
of the information they process. However, the TCB shall
include a mechanism by which the TCB and an authorized user
reliably communicate to designate the single sensitivity
level of information imported or exported via single-level
communication channels or I/O devices.
+ Interpretation
Whenever one or both of two directly connected com-
ponents is not trusted to maintain the separation of
information of different sensitivity levels, or whenever the
two directly connected components have only a single sensi-
tivity level in common, the two components of the network
shall communicate over a single-level channel. Single-level
components and single-level communication channels are not
required to maintain the sensitivity labels of the informa-
tion they process. However, the NTCB shall include a reli-
able communication mechanism by which the NTCB and an
authorized user (via a trusted path) or a subject within an
NTCB partition can designate the single sensitivity level of
information imported or exported via single-level communica-
tion channels or network components. The level of informa-
tion communicated must equal the device level.
+ Rationale
Single-level communications channels and single-level
components in networks are analogous to single level chan-
nels and I/O devices in stand-alone systems in that they are
not trusted to maintain the separation of information of
different sensitivity levels. The labels associated with
data transmitted over those channels and by those components
are therefore implicit; the NTCB associates labels with the
data because of the channel or component, not because of an
explicit part of the bit stream. Note that the sensitivity
level of encrypted information is the level of the cipher-
text rather than the original level(s) of the plaintext.
4.1.1.3.2.3 Labeling Human-Readable Output
+ Statement from DoD 5200.28-STD
The ADP system administrator shall be able to specify the
printable label names associated with exported sensitivity
labels. The TCB shall mark the beginning and end of all
human-readable, paged, hardcopy output (e.g., line printer
output) with human-readable sensitivity labels that prop-
erly1 represent the sensitivity of the output. The TCB
shall, by default, mark the top and bottom of each page of
human-readable, paged, hardcopy output (e.g., line printer
output) with human-readable sensitivity labels that prop-
erly1 represent the sensitivity of the page. The TCB shall,
by default and in an appropriate manner, mark other forms of
human readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly1 represent the
sensitivity of the output. Any override of these markings
defaults shall be auditable by the TCB.
_________________________
1 The hierarchical classification component in human-
readable sensitivity labels shall be equal to the
greatest hierarchical classification of any of the in-
formation in the output that the labels refer to; the
non-hierarchical category component shall include all
of the non-hierarchical categories of the information
in the output the labels refer to, but no other non-
hierarchical categories.
+ Interpretation
This criterion imposes no requirement to a component
that produces no human-readable output. For those that do
produce human-readable output, each sensitivity level that
is defined to the network shall have a uniform meaning
across all components. The network administrator, in con-
junction with any affected component administrator, shall be
able to specify the human-readable label that is associated
with each defined sensitivity level.
+ Rationale
The interpretation is a straightforward extension of
the requirement into the context of a network system and
partitioned NTCB as defined for these network interpreta-
tions.
4.1.1.3.3 Subject Sensitivity Labels
+ Statement from DoD 5200.28-STD
The TCB shall immediately notify a terminal user of each
change in the sensitivity level associated with that user
during an interactive session. A terminal user shall be
able to query the TCB as desired for a display of the
subject's complete sensitivity label.
+ Interpretation
An NTCB partition shall immediately notify a terminal
user attached to its component of each change in the sensi-
tivity level associated with that user.
+ Rationale
The local NTCB partition must ensure that the user
understands the sensitivity level of information sent to and
from a terminal. When a user has a surrogate process in
another component, adjustments to its level may occur to
maintain communication with the user. These changes may
occur asynchronously. Such adjustments are necessitated by
mandatory access control as applied to the objects involved
in the communication path.
4.1.1.3.4 Device Labels
+ Statement from DoD 5200.28-STD
The TCB shall support the assignment of minimum and maximum
sensitivity levels to all attached physical devices. These
sensitivity levels shall be used by the TCB to enforce con-
straints imposed by the physical environments in which the
devices are located.
+ Interpretation
This requirement applies as written to each NTCB parti-
tion that is trusted to separate information based on sensi-
tivity level. Each I/O device in a component, used for com-
munication with other network components, is assigned a dev-
ice range, consisting of a set of labels with a maximum and
minimum. (A device range usually contains, but does not
necessarily contain, all possible labels "between" the max-
imum and minimum, in the sense of dominating the minimum and
being dominated by the maximum.)
The NTCB always provides an accurate label for informa-
tion exported through devices. Information exported or
imported using a single-level device is labelled implicitly
by the sensitivity level of the device. Information
exported from one multilevel device and imported at another
must be labelled through an agreed-upon protocol, unless it
is labelled implicitly by using a communication link that
always carries a single level.
Information exported at a given sensitivity level can
be sent only to an importing device whose device range con-
tains that level or a higher level. If the importing device
range does not contain the given level, the information is
relabelled upon reception at a higher level within the
importing device range. Relabelling should not occur other-
wise.
+ Rationale
The purpose of device labels is to reflect and con-
strain the sensitivity levels of information authorized for
the physical environment in which the devices are located.
The information transfer restrictions permit one-way
communication (i.e., no acknowledgements) from one device to
another whose ranges have no level in common, as long as
each level in the sending device range is dominated by some
level in the receiving device range. It is never permitted
to send information at a given level to a device whose range
does not contain a dominating level. (See Appendix C for
similar interconnection rules for the interconnected AIS
view.)
4.1.1.4 Mandatory Access Control
+ Statement from DoD 5200.28-STD
The TCB shall enforce a mandatory access control policy over
all resources (i.e., subjects, storage objects, and I/O dev-
ices) that are directly or indirectly accessible by subjects
external to the TCB. These subjects and objects shall be
assigned sensitivity labels that are a combination of
hierarchical classification levels and non-hierarchical
categories, and the labels shall be used as the basis for
mandatory access control decisions. The TCB shall be able
to support two or more such sensitivity levels. (See the
Mandatory Access Control interpretations.) The following
requirements shall hold for all accesses between all sub-
jects external to the TCB and all objects directly or
indirectly accessible by these subjects. A subject can
read an object only if the hierarchical classification in
the subject's sensitivity level is greater than or equal to
the hierarchical classification of the object's sensitivity
level and the non-hierarchical categories in the subject's
sensitivity level include all the non-hierarchical
categories in the object's sensitivity level. A subject can
write an object only if the hierarchical classification in
the subject's sensitivity level is less than or equal to the
hierarchical classification of the object's sensitivity
level and the non-hierarchical categories in the subject's
sensitivity level are included in the non-hierarchical
categories in the object's sensitivity level. Identification
and authentication data shall be used by the TCB to authen-
ticate the user's identity and to ensure that the sensi-
tivity level and authorization of subjects external to the
TCB that may be created to act on behalf of the individual
user are dominated by the clearance and authorization of
that user.
+ Interpretation
Each partition of the NTCB exercises mandatory access
control policy over all subjects and objects in its com-
ponent. In a network, the responsibility of an NTCB parti-
tion encompasses all mandatory access control functions in
its component that would be required of a TCB in a stand-
alone system. In particular, subjects and objects used for
communication with other components are under the control of
the NTCB partition. Mandatory access control includes
secrecy and integrity control to the extent that the network
sponsor has described in the overall network security pol-
icy.
Conceptual entities associated with communication
between two components, such as sessions, connections and
virtual circuits, may be thought of as having two ends, one
in each component, where each end is represented by a local
object. Communication is viewed as an operation that copies
information from an object at one end of a communication
path to an object at the other end. Transient data-carrying
entities, such as datagrams and packets, exist either as
information within other objects, or as a pair of objects,
one at each end of the communication path.
The requirement for "two or more" sensitivity levels
can be met by either secrecy or integrity levels. When
there is a mandatory integrity policy, the stated require-
ments for reading and writing are generalized to: A subject
can read an object only if the subject's sensitivity level
dominates the object's sensitivity level, and a subject can
write an object only if the object's sensitivity level dom-
inates the subject's sensitivity level. Based on the
integrity policy, the network sponsor shall define the domi-
nance relation for the total label, for example, by combin-
ing secrecy and integrity lattices. -
+ Rationale
An NTCB partition can maintain access control only over
subjects and objects in its component. At levels B2 and
above, the NTCB partition must maintain access control over
all subjects and objects in its component. Access by a sub-
ject in one component to information contained in an object
in another component requires the creation of a subject in
the remote component which acts as a surrogate for the first
subject.
The mandatory access controls must be enforced at the
interface of the reference monitor (viz. the mechanism that
controls physical processing resources) for each NTCB parti-
tion. This mechanism creates the abstraction of subjects
and objects which it controls. Some of these subjects out-
side the reference monitor, per se, may be designated to
implement part of an NTCB partition's mandatory policy,
e.g., by using the ``trusted subjects" defined in the Bell-
LaPadula model.
The prior requirements on exportation of labeled infor-
mation to and from I/O devices ensure the consistency
between the sensitivity labels of objects connected by a
communication path. As noted in the introduction, the net-
work architecture must recognize the linkage between the
overall mandatory network security policy and the connection
oriented abstraction. For example, individual data-carrying
entities such as datagrams can have individual sensitivity
labels that subject them to mandatory access control in each
component. The abstraction of a single-level connection is
realized and enforced implicitly by an architecture while a
connection is realized by single-level subjects that neces-
sarily employ only datagrams of the same level.
The fundamental trusted systems technology permits the
DAC mechanism to be distributed, in contrast to the require-
ments for mandatory access control. For networks this
separation of MAC and DAC mechanisms is the rule rather than
_________________________
- See, for example, Grohn, M. J., A Model of a Pro-
_ _____ __ _ ___
tected Data Management System, ESD-TR-76-289, I. P.
______ ____ __________ ______
Sharp Assoc. Ltd., June, 1976; and Denning, D .E.,
Lunt, T. F., Neumann, P. G., Schell, R. R., Heckman, M.
and Shockley, W., Secure Distributed Data Views, Secu-
______ ___________ ____ _____ ____
rity Policy and Interpretation for a Class A1 Multilev-
____ ______ ___ ______________ ___ _ _____ __ ________
el Secure Relational Database System,SRI International,
__ ______ __________ ________ ______
November 1986.
the exception.
The set of total sensitivity labels used to represent
all the sensitivity levels for the mandatory access control
(combined data secrecy and data integrity) policy always
forms a partially ordered set. Without loss of generality,
this set of labels can always be extended to form a lattice,
by including all the combinations of non-hierarchical
categories. As for any lattice, a dominance relation is
always defined for the total sensitivity labels. For admin-
istrative reasons it may be helpful to have a maximum level
which dominates all others.
4.1.2 Accountability
_ _ _ ______________
4.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 maintain
authentication data that includes information for verifying
the identify of individual users (e.g., passwords) as well
as information for determining the clearance and authoriza-
tions of individual users. This data shall be used by the
TCB to authenticate the user's identity and to ensure that
the sensitivity level and authorization of subjects external
to the TCB that may be created to act on behalf of the indi-
vidual user are dominated by the clearance and authorization
of that user. 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
_________________________
= Department of Defense Password Management Guide-
__________ __ _______ ________ __________ _____
line, CSC-STD-002-85
____
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.
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. If the authenticated identification is used as the
basis of determining a sensitivity label for a subject, it
must satisfy the Label Integrity criterion.
An authenticated identification may be forwarded
between components and employed in some component to iden-
tify the sensitivity level associated with a subject created
to act on behalf of the user so identified.
4.1.2.1.1 Trusted Path
+ Statement from DoD 5200.28-STD
The TCB shall support a trusted communication path between
itself and users for use when a positive TCB-to-user connec-
tion is required (e.g., login, change subject sensitivity
level). Communications via this trusted path shall be
activated exclusively by a user or the TCB and shall be
logically and unmistakably distinguishable from other paths.
+ Interpretation
A trusted path is supported between a user (i.e.,
human) and the NTCB partition in the component to which the
user is directly connected.
+ Rationale
When a user logs into a remote component, the user id
is transmitted securely between the local and remote NTCB
partitions in accordance with the requirements in Identifi-
cation and Authentication.
Trusted Path is necessary in order to assure that the
user is communicating with the NTCB and only the NTCB when
security relevant activities are taking place (e.g., authen-
ticate user, set current session sensitivity level). How-
ever, Trusted Path does not address communications within
the NTCB, only communications between the user and the NTCB.
If, therefore, a component does not support any direct user
communication then the component need not contain mechanisms
for assuring direct NTCB to user communications.
The requirement for trusted communication between one
NTCB partition and another NCTB partition is addressed in
the System Architecture section. These requirements are
separate and distinct from the user to NTCB communication
requirement of a trusted path. However, it is expected that
this trusted communication between one NTCB partition and
another NTCB partition will be used in conjunction with the
trusted path to implement trusted communication between the
user and the remote NTCB partition.
4.1.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,
introduction 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. The TCB shall also be able to audit any override of
human-readable output markings. 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 and the object's
sensitivity level. The ADP system administrator shall be
able to selectively audit the actions of any one or more
users based on individual identify and/or object sensitivity
level. The TCB shall be able to audit the identified
events that may be used in the exploitation of covert
storage channels. The TCB shall contain a mechanism that
is able to monitor the occurrence or accumulation of secu-
rity auditable events that may indicate an imminent viola-
tion of security policy. This mechanism shall be able to
immediately notify the security administrator when thres-
holds are exceeded and, if the occurrence or accumulation of
these security relevant events continues, the system shall
take the least disruptive action to terminate the event.
+ 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.
The capability must exist to audit the identified
events that may be used in the exploitation of covert
storage channels. To accomplish this, each NTCB partition
must be able to audit those events locally that may lead to
the exploitation of a covert storage channel which exist
because of the network.
The sponsor shall identify the specific auditable
events that may indicate an imminent violation of security
policy. The component which detects the occurrence or accu-
mulation of such events must be able to notify an appropri-
ate administrator when thresholds are exceeded, and to ini-
tiate actions which will result in termination of the event
if the accumulation continues. For example, when the thres-
hold of unsuccessful login attempts within a period of time
is exceeded, login shall be inhibited for a specific time
period.
+ 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. Identification of covert channel
events is addressed in the Covert Channel Analysis section.
Because of concurrency and synchronization problems, it
may not be possible to detect in real time the accumulation
of security auditable events that are occurring in different
NTCB partitions. However, each NTCB partition that has been
allocated audit responsibility must have the capability to
detect the local accumulation of events, to notify the par-
tition security administrator and/or the network security
administrator, and to initiate actions which will result in
termination of the event locally.
4.1.3 Assurance
_ _ _ _________
4.1.3.1 Operational Assurance
4.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). The TCB
shall maintain process isolation through the provision of
distinct address spaces under its control. The TCB shall be
internally structured into well-defined largely independent
modules. It shall make effective use of available hardware
to separate those elements that are protection-critical from
those that are not. The TCB modules shall be designed such
that the principle of least privilege is enforced. Features
in hardware, such as segmentation, shall be used to support
logically distinct storage objects with separate attributes
(namely: readable, writable). The user interface to the TCB
shall be completely defined and all elements of the TCB
identified. The TCB shall be designed and structured to
use a complete, conceptually simple protection mechanism
with precisely defined semantics. This mechanism shall play
a central role in enforcing the internal structuring of the
TCB and the system. The TCB shall incorporate significant
use of layering, abstraction and data hiding. Significant
system engineering shall be directed toward minimizing the
complexity of the TCB and excluding from the TCB modules
that are not protection-critical.
+ 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. Since each component is itself a dis-
tinct domain in the overall network system, this also satis-
fies the requirement for process isolation through distinct
address spaces in the special case where a component has
only a single subject.
The NTCB must be internally structured into well-
defined largely independent modules and meet the hardware
requirements. This is satisfied by having each NTCB parti-
tion so structured. The NTCB controls all network resources.
These resources 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 protected against external interference or tamper-
ing. For example, a cryptographic checksum or physical
means may be employed to protect user authentication data
exchanged between NTCB partitions.
Each NTCB partition must enforce the principle of least
privilege within its component. Additionally, the NTCB must
be structured so that the principle of least privilege is
enforced in the system as a whole.
The NTCB must be designed and structured according to
the network security architecture to use a complete, concep-
tually simple protection mechanism. Furthermore, each NTCB
partition must also be so designed and structured.
Significant system engineering should be directed
toward minimizing the complexity of each NTCB partition, and
of the NTCB. Care shall be taken to exclude modules (and
components) that are not protection-critical from the NTCB.
It is recognized that some modules and/or components
may need to be included in the NTCB and must meet the NTCB
requirements even though they may not appear to be directly
protection-critical. The correct operation of these
modules/components is necessary for the correct operation of
the protection-critical modules and components. However,
the number and size of these modules/components should be
kept to a minimum.
Each NTCB partition provides isolation of resources
(within its component) in accord with the network system
architecture and security policy so that "supporting ele-
ments" (e.g., DAC and user identification) for the security
mechanisms of the network system are strengthened compared
to C2, from an assurance point of view, through the provi-
sion of distinct address spaces under control of the NTCB.
As discussed in the Discretionary Access Control sec-
tion, 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. When distributed in NTCB sub-
jects (i.e., when outside the reference monitor), the
assurance requirements for the design and implementation of
the DAC shall be those of class C2 for all networks of class
C2 or above.
+ Rationale
The requirement that the NTCB be structured into
modules and meet the hardware requirements applies within
the NTCB partitions in the various components.
The principle of least privilege requires that each
user or other individual with access to the system be given
only those resources and authorizations required for the
performance of this job. In order to enfore this principle
in the system it must be enforced in every NTCB partition
that supports users or other individuals. For example,
prohibiting access by administrators to objects outside the
NTCB partition (e.g., games) lessens the opportunity of dam-
age by a Trojan Horse.
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.
There are certain parts of a network (modules and/or
components) that may not appear to be directly protection-
critical in that they are not involved in access control
decisions, do not directly audit, and are not involved in
the identification/authentication process. However, the
security of the network must depend on the correct operation
of these modules and/or components. An example of this is a
single level packet switch. Although it may not normally be
involved directly in enforcing the discretionary security
policy, this switch may be trusted not to mix data from dif-
ferent message streams. If the switch does not operate
correctly, data could get mixed, and unauthorized access
could result. Therefore, these modules/components must be
included in the NTCB and must meet the NTCB requirements
applicable to the policy element(s) for which they are
responsible.
4.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 mandatory and dis-
cretionary access control policy in a network may require
communication between trusted subjects that are part of the
NTCB partitions in different components. This communication
is normally 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.
It should be clear that some integrity and denial of
service features can reside outside the NTCB. Otherwise all
software in a network would be in the NTCB. Every piece of
software that has an opportunity to write to some data or
protocol field is "trusted" to preserve integrity or not
cause denial of service to some extent. For example, it is
necessary to "trust" TELNET to correctly translate user
data, and to eventually transmit packets. FTP also has to
be "trusted" to not inappropriately modify files, and to
attempt to complete the file transfer. These protocols can
be designed, however to exist outside the NTCB (from a pro-
tection perspective). It is beneficial to do this type of
security engineering so that the amount of code that must be
trusted to not disclose data is minimized. Putting every-
thing inside the NTCB contradicts the requirement to perform
"significant system engineering ... directed toward ...
excluding from the TCB modules that are not protection crit-
ical," which removes the primary difference between B2 and
B3. If everything has to be in the TCB to ensure data
integrity and protection against denial of service, there
will be considerably less assurance that disclosure protec-
tion is maximized.
4.1.3.1.3 Covert Channel Analysis
+ Statement from DoD 5200.28-STD
The system developer shall conduct a thorough search for
covert channels and make a determination (either by actual
measurement or by engineering estimation) of the maximum
bandwidth of each identified channel. (See the Covert Chan-
nels Guideline section.) FORMAL METHODS SHALL BE USED IN THE
ANALYSIS.
+ Interpretation
The requirement, including the TCSEC Covert Channel
Guideline, applies as written. In a network, there are
additional instances of covert channels associated with com-
munication between components. THE FORMAL METHODS SHALL BE
USED IN THE ANALYSIS OF EACH INDIVIDUAL COMPONENT DESIGN AND
IMPLEMENTATION.
+ Rationale
The exploitation of network protocol information (e.g.,
headers) can result in covert storage channels. Exploitation
of frequency of transmission can result in covert timing
channels. The topic has been addressed in the literature.-
4.1.3.1.4 Trusted Facility Management
+ Statement from DoD 5200.28-STD
The TCB shall support separate operator and administrator
functions. The functions performed in the role of a secu-
rity administrator shall be identified. The ADP system
administrative personnel shall only be able to perform secu-
rity administrator functions after taking a distinct audit-
able action to assume the security administrator role on the
ADP system. Non-security functions that can be performed in
the security administration role shall be limited strictly
_________________________
- See, for example, Girling, C. G., "Covert Channels
in LAN's," IEEE Transactions on Software Engineering,
____ ____________ __ ________ ___________
Vol. SE-13, No. 2, February 1987; and Padlipsky, M. A.,
Snow, D. P., and Karger, P. A., Limitations of End-to-
___________ __ ___ __
End Encryption in Secure Computer Networks, MITRE
___ __________ __ ______ ________ ________
Technical Report, MTR-3592, Vol. I, May 1978 (ESD TR
78-158, DTIC AD A059221).
to those essential to performing the security role effec-
tively.
+ Interpretation
This requirement applies as written to both the network
as a whole and to individual components which support such
personnel.
+ Rationale
It is recognized that based on the allocated policy
elements some components may operate with no human inter-
face.
4.1.3.1.5 Trusted Recovery
+ Statement from DoD 5200.28-STD
Procedures and/or mechanisms shall be provided to assure
that, after an ADP system failure or other discontinuity,
recovery without a protection compromise is obtained.
+ Interpretation
The recovery process must be accomplished without a
protection compromise after the failure or other discon-
tinuity of any NTCB partition. It must also be accomplished
after a failure of the entire NTCB.
+ Rationale
This is a straight-forward extension of the requirement
into the network context, and takes into account that it is
possible for parts of the system to fail while other parts
continue to operate normally. This may be a security-
relevant event; if so it must be audited.
4.1.3.2 Life-Cycle Assurance
4.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. A
team of individuals who thoroughly understand the specific
implementation of the TCB shall subject its design documen-
tation, source code, and object code to through analysis and
testing. Their objectives shall be: to uncover all design
and implementation flaws that would permit a subject exter-
nal to the TCB to read, change, or delete data normally
denied under the mandatory or discretionary security policy
enforced by the TCB; as well as to assure that no subject
(without authorization to do so) is able to cause the TCB to
enter a state such that it is unable to respond to communi-
cations initiated by other users. The TCB shall be found
resistant to penetration. All discovered flaws shall be
removed or neutralized and the TCB retested to demonstrate
that they have been eliminated and that new flaws have not
been introduced. Testing shall demonstrate that the TCB
implementation is consistent with the descriptive top-level
specification. No design flaws and no more than a few
correctable implementation flaws may be found during testing
and there shall be reasonable confidence that few remain.
MANUAL OR OTHER MAPPING OF THE FTLS TO THE SOURCE CODE MAY
FORM A BASIS FOR PENETRATION TESTING. (See the Security
Testing Guidelines.)
+ Interpretation
Testing of a component will require a testbed that
exercises the interfaces and protocols of the component
including tests under exceptional conditions. 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 partition that
implement the given mechanism. This integrated testing is
additional to any individual component tests involved in the
evaluation of the network system. The sponsor should iden-
tify 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 configura-
tions. A change in configuration within the allowable set
of configurations does not require retesting.
The testing of each component will include the intro-
duction of subjects external to the NTCB partition for the
component that will attempt to read, change, or delete data
normally denied. If the normal interface to the component
does not provide a means to create the subjects needed to
conduct such a test, then this portion of the testing shall
use a special version of the untrusted software for the com-
ponent that results in subjects that make such attempts.
The results shall be saved for test analysis. Such special
versions shall have an NTCB partition that is identical to
that for the normal configuration of the component under
evaluation.
The testing of the mandatory controls shall include
tests to demonstrate that the labels for information
imported and/or exported to/from the component accurately
represent the labels maintained by the NTCB partition for
the component for use as the basis for its mandatory access
control decisions. The tests shall include each type of
device, whether single-level or multilevel, supported by the
component.
The NTCB must be found resistant to penetration. This
applies to the NTCB as a whole, and to each NTCB partition
in a component of this class.
+ Rationale
The phrase "no subject (without authorization to do so)
is able to cause the TCB to enter a state such that it is
unable to respond to communications initiated by other
users" relates to the security services (Part II of this
TNI) for the Denial of Service problem, and to correctness
of the protocol implementations.
Testing is an important method available in this
evaluation division to gain any assurance that the security
mechanisms perform their intended function. A major purpose
of testing is to demonstrate the system's response to inputs
to the NTCB partition from untrusted (and possibly mali-
cious) subjects.
In contrast to general purpose systems that allow for
the dynamic creation of new programs and the introductions
of new processes (and hence new subjects) with user speci-
fied security properities, many network components have no
method for introducing new programs and/or processes during
their normal operation. Therefore, the programs necessary
for the testing must be introduced as special versions of
the software rather than as the result of normal inputs by
the test team. However, it must be insured that the NTCB
partition used for such tests is identical to the one under
evaluation.
Sensitivity labels serve a critical role in maintaining
the security of the mandatory access controls in the net-
work. Especially important to network security is the role
of the labels for information communicated between com-
ponents - explicit labels for multilevel devices and impli-
cit labels for single-level devices. Therefore the testing
for correct labels is highlighted.
The requirement for testing to demonstrate consistency
between the NTCB implementation and the FTLS is a straight-
forward extension of the TCSEC requirement into the context
of a network system.
4.1.3.2.2 Design Specification and Verification
+ Statement from DoD 5200.28-STD
A formal model of the security policy supported by the TCB
shall be maintained over the life cycle of the ADP system
that is proven and demonstrated to be consistent with its
axioms. A descriptive top-level specification (DTLS) of the
TCB shall be maintained that completely and accurately
describes the TCB in terms of exceptions, error messages,
and effects. A FORMAL TOP-LEVEL SPECIFICATION (FTLS) OF THE
TCB SHALL BE MAINTAINED THAT ACCURATELY DESCRIBES THE TCB IN
TERMS OF EXCEPTIONS, ERROR MESSAGES, AND EFFECTS. THE DTLS
AND FTLS SHALL INCLUDE THOSE COMPONENTS OF THE TCB THAT ARE
IMPLEMENTED AS HARDWARE AND/OR FIRMWARE IF THEIR PROPERTIES
ARE VISIBLE AT THE TCB INTERFACE. THE FTLS SHALL BE SHOWN
to be an accurate description of the TCB interface. A con-
vincing argument shall be given that the DTLS is consistent
with the model AND A COMBINATION OF FORMAL AND INFORMAL
TECHNIQUES SHALL BE USED TO SHOW THAT THE FTLS IS CONSISTENT
WITH THE MODEL. THIS VERIFICATION EVIDENCE SHALL BE CON-
SISTENT WITH THAT PROVIDED WITHIN THE STATE-OF-THE-ART OF
THE PARTICULAR NATIONAL COMPUTER SECURITY CENTER-ENDORSED
FORMAL SPECIFICATION AND VERIFICATION SYSTEM USED. MANUAL
OR OTHER MAPPING OF THE FTLS TO THE TCB SOURCE CODE SHALL BE
PERFORMED TO PROVIDE EVIDENCE OF CORRECT IMPLEMENTATION.
+ Interpretation
The overall network security policy expressed in this
model will provide the basis for the mandatory access con-
trol policy exercised by the NTCB over subjects and storage
objects in the entire network. The policy will also be the
basis for the discretionary access control policy exercised
by the NTCB to control access of named users to named
objects. Data integrity requirements addressing the effects
of unauthorized MSM need not be included in this model. The
overall network policy must be decomposed into policy ele-
ments that are allocated to appropriate components and used
as the basis for the security policy model for those com-
ponents.
The level of abstraction of the model, and the set of
subjects and objects that are explicitly represented in the
model, will be affected by the NTCB partitioning. Subjects
and objects must be represented explicitly in the model for
the partition if there is some network component whose NTCB
partition exercises access control over them. The model
shall be structured so that the axioms and entities applica-
ble to individual network components are manifest. Global
network policy elements that are allocated to components
shall be represented by the model for that component.
AN FTLS FOR A NETWORK CONSISTS OF A COMPONENT FTLS FOR
EACH UNIQUE TRUSTED NETWORK COMPONENT, PLUS ANY GLOBAL
DECLARATIONS AND ASSERTIONS THAT APPLY TO MORE THAN ONE COM-
PONENT. IF THE MODEL FOR EACH COMPONENT REPRESENTS ALL THE
GLOBAL MANDATORY POLICY ELEMENTS ALLOCATED TO THAT COM-
PONENT, THERE MAY NOT BE ANY GLOBAL ASSERTIONS NEEDED, AND
IN THIS CASE THE COLLECTION OF COMPONENT FTLS, WITH ANY
SHARED DECLARATIONS, IS THE NETWORK FTLS. EACH COMPONENT
FTLS SHALL DESCRIBE THE INTERFACE TO THE NTCB PARTITION OF
ITS COMPONENTS. The requirements for a network DTLS are
given in the Design Documentation section.
+ Rationale
The treatment of the model depends to a great extent on
the degree of integration of the communications service into
a distributed system. In a closely coupled distributed sys-
tem, one might use a model that closely resembles one
appropriate for a stand-alone computer system.
In all cases, the model of each partition will be
expected to show the role of the NTCB partition in each kind
of component. It will most likely clarify the model,
although not part of the model, to show access restrictions
implied by the system design; for example, subjects
representing protocol entities might have access only to
objects containing data units at the same layer of protocol.
The allocation of subjects and objects to different proto-
col layers is a protocol design choice which need not be
reflected in the security policy model.
THE FTLS MUST REPRESENT THE UNDERLYING REFERENCE MONI-
TOR AND ANY SUBJECTS IMPLEMENTING THE MANDATORY POLICY.
OTHER POLICY ELEMENTS DISTRIBUTED IN NTCB SUBJECTS (SEE THE
INTERPRETATION OF SYSTEM ARCHITECTURE) NEED NOT BE
REPRESENTED BY THE FTLS.
4.1.3.2.3 Configuration Management
+ Statement from DoD 5200.28-STD
During THE ENTIRE LIFE-CYCLE, I.E. DURING THE DESIGN,
DEVELOPMENT, and maintenance of the TCB, a configuration
management system shall be in place FOR ALL SECURITY-
RELEVANT HARDWARE, FIRMWARE, AND SOFTWARE that maintains
control of changes to THE FORMAL MODEL, the descriptive AND
FORMAL top-level SPECIFICATIONS, other design data, imple-
mentation documentation, source code, the running version of
the object code, and test fixtures and documentation. The
configuration management system shall assure a consistent
mapping among all documentation and code associated with the
current version of the TCB. Tools shall be provided for
generation of a new version of the TCB from source code.
Also available shall be tools, MAINTAINED UNDER STRICT CON-
FIGURATION CONTROL, for comparing a newly generated version
with the previous TCB version in order to ascertain that
only the intended changes have been made in the code that
will actually be used as the new version of the TCB. A COM-
BINATION OF TECHNICAL, PHYSICAL, AND PROCEDURAL SAFEGUARDS
SHALL BE USED TO PROTECT FROM UNAUTHORIZED MODIFICATION OR
DESTRUCTION THE MASTER COPY OR COPIES OF ALL MATERIAL USED
TO GENERATE THE TCB.
+ Interpretation
The requirement applies as written, with the following
extensions:
1. A configuration management system must be in place
for each NTCB partition.
2. A configuration management plan must exist for the
entire system. If the configuration management sys-
tem is made up of the conglomeration of the confi-
guration management systems of the various NTCB par-
titions, then the configuration management plan must
address the issue of how configuration control is
applied to the system as a whole.
ALL MATERIAL USED IN GENERATING A NEW VERSION OF THE
NTCB AND EACH NTCB PARTITION MUST BE PROTECTED, REGARDLESS
OF WHERE IT PHYSICALLY RESIDES.
+ Rationale
Each NTCB partition must have a configuration manage-
ment system in place, or else there will be no way for the
NTCB as a whole to have an effective configuration manage-
ment system. The other extensions are merely reflections of
the way that networks operate in practice.
THIS NEW REQUIREMENT EXPLICITLY MANDATES THE PROTECTION
OF MATERIAL USED TO GENERATE AN NTCB PARTITION, EVEN WHEN
THE GENERATION OCCURS BY DOWN-LINE LOADING OF A REMOTE COM-
PONENT.
4.1.3.2.4 Trusted Distribution
+ Statement from DoD 5200.28-STD
A TRUSTED ADP SYSTEM CONTROL AND DISTRIBUTION FACILITY SHALL
BE PROVIDED FOR MAINTAINING THE INTEGRITY OF THE MAPPING
BETWEEN THE MASTER DATA DESCRIBING THE CURRENT VERSION OF
THE TCB AND THE ON-SITE MASTER COPY OF THE CODE FOR THE
CURRENT VERSION. PROCEDURES (E.G., SITE SECURITY ACCEPTANCE
TESTING) SHALL EXIST FOR ASSURING THAT THE TCB SOFTWARE,
FIRMWARE, AND HARDWARE UPDATES DISTRIBUTED TO A CUSTOMER ARE
EXACTLY AS SPECIFIED BY THE MASTER COPIES.
+ Interpretation
THIS REQUIREMENT APPLIES AS STATED, WITH THE ADDITIONAL
REQUIREMENT THAT, IF DOWN-LINE LOADING IS USED, THERE MUST
BE A TRUSTED METHOD OF GENERATING, SENDING, AND LOADING ANY
SOFTWARE INVOLVED.
+ Rationale
THIS IS A STRAIGHTFORWARD EXTENSION OF THE REQUIREMENT
INTO THE NETWORK CONTEXT.
4.1.4 Documentation.
_ _ _ _____________
4.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.
4.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. The procedures
for examining and maintaining the audit files as well as the
detailed audit record structure for each type of audit event
shall be given. The manual shall describe the operator and
administrator functions related to security, to include
changing the security characteristics of a user. It shall
provide interpretations on the consistent and effective use
of the protection features of the system, how they interact,
how to securely generate a new TCB, and facility procedures,
warnings, and privileges that need to be controlled in order
to operate the facility in a secure manner. The TCB modules
that contain the reference validation mechanism shall be
identified. The procedures for secure generation of a new
TCB from source after modification of any modules in the TCB
shall be described. It shall include the procedures to
ensure that the system is initially started in a secure
manner. Procedures shall also be included to resume secure
system operation after any lapse in system operation.
+ 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).
6. Incremental updates; that is, it must explicitly
indicate which components of the network may change
without others also changing.
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).
The components of the network that form the NTCB must
be identified. Furthermore, the modules within an NTCB par-
tition that contain the reference validation mechanism (if
any) within that partition must be identified.
The procedures for the secure generation of a new ver-
sion (or copy) of each NTCB partition from source must be
described. The procedures and requirements for the secure
generation of the NTCB necessitated by changes in the net-
work configuration shall be described.
Procedures for starting each NTCB partition in a secure
state shall be specified. Procedures must also be included
to resume secure operation of each NTCB partition and/or the
NTCB after any lapse in system or subsystem operation.
+ 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.
As mentioned in the section on Label Integrity, cryp-
tography is one common mechanism employed to protect commun-
ication 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.
The requirements for descriptions of NTCB generation
and identification of modules and components that form the
NTCB are straightforward extensions of the TCSEC require-
ments into the network context. In those cases where the
vendor does not provide source code, an acceptable procedure
shall be to request the vendor to perform the secure genera-
tion.
Given the nature of network systems (e.g., various com-
ponents tend to be down at different times, and the network
system must continue operation without that component), it
is imperative to know both how to securely start up an NTCB
partition, and how to resume operation securely. It is also
necessary to know how to resume secure operation of the NTCB
after any partition has been down.
4.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. It shall include
results of testing the effectiveness of the methods used to
reduce covert channel bandwidths. THE RESULTS OF THE MAP-
PING BETWEEN THE FORMAL TOP-LEVEL SPECIFICATION AND THE TCB
SOURCE CODE SHALL BE GIVEN.
+ 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.
THE MAPPING BETWEEN THE FTLS AND THE NTCB SOURCE CODE
MUST BE CHECKED TO ENSURE TO THE EXTENT POSSIBLE THAT THE
FTLS IS A CORRECT REPRESENTATION OF THE SOURCE CODE, AND
THAT THE FTLS HAS BEEN STRICTLY ADHERED TO DURING THE DESIGN
AND DEVELOPMENT OF THE NETWORK SYSTEM. THIS CHECK MUST BE
DONE FOR EACH COMPONENT OF THE NETWORK SYSTEM FOR WHICH AN
FTLS EXISTS.
+ 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.
The bandwidths of covert channels are used to determine
the suitability of a network system for a given environment.
The effectiveness of the methods used to reduce these
bandwidths must therefore be accurately determined.
4.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.
The interfaces between the TCB modules shall be described.
A formal description of the security policy model enforced
by the TCB shall be available and an explanation provided to
show that it is sufficient to enforce the security policy.
The specific TCB protection mechanisms shall be identified
and an explanation given to show that they satisfy the
model. The descriptive top-level specification (DTLS) shall
be shown to be an accurate description of the TCB interface.
Documentation shall describe how the TCB implements the
reference monitor concept and give an explanation why it is
tamper resistant, cannot be bypassed, and is correctly
implemented. The TCB implementation (i.e., in hardware,
firmware, and software) shall be informally shown to be con-
sistent with the FORMAL TOP-LEVEL SPECIFICATION (FTLS). The
elements of the FTLS shall be shown, using informal tech-
niques, to correspond to the elements of the TCB. Documen-
tation shall describe how the TCB is structured to facili-
tate testing and to enforce least privilege. This documen-
tation shall also present the results of the covert channel
analysis and the tradeoffs involved in restricting the chan-
nels. All auditable events that may be used in the exploi-
tation of known covert storage channels shall be identified.
The bandwidths of known covert storage channels, the use of
which is not detectable by the auditing mechanisms, shall be
provided. (See the Covert Channel Guideline section.)
HARDWARE, FIRMWARE, AND SOFTWARE MECHANISMS NOT DEALT WITH
IN THE FTLS BUT STRICTLY INTERNAL TO THE TCB (E.G., MAPPING
REGISTERS, DIRECT MEMORY ACCESS I/O) SHALL BE CLEARLY
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.
The documentation includes both a system description
and a set of component DTLS's. The system description
addresses the network security architecture and design by
specifying the types of components in the network, which
ones are trusted, and in what way they must cooperate to
support network security objectives. A component DTLS shall
be provided for each trusted network component, i.e., each
component containing an NTCB partition. Each component DTLS
shall describe the interface to the NTCB partition of its
component. Both the system description and each component
DTLS shall be shown consistent with those assertions in the
model that apply to it. Appendix A addresses component
evaluation issues.
To show the correspondence between the FTLS and the
NTCB implementation, it suffices to show correspondence
between each component FTLS and the NTCB partition in that
component.
As stated in the introduction to Division B, the spon-
sor must demonstrate that the NTCB employs the reference
monitor concept. The security policy model must be a model
for a reference monitor.
The security policy model for each partition implement-
ing a reference monitor shall fully represent the access
control policy supported by the partition, including the
discretionary and mandatory security policy for secrecy
and/or integrity. For the mandatory policy the single domi-
nance relation for sensitivity labels, including secrecy
and/or integrity components, shall be precisely defined.
+ 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
unambiguously define the security functionality of com-
ponents as well as the interfaces between or among com-
ponents. 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.
The term "model" is used in several different ways in a
network context, e.g., a "protocol reference model," a "for-
mal network model," etc. Only the "security policy model" is
addressed by this requirement and is specifically intended
to model the interface, viz., "security perimeter," of the
reference monitor and must meet all the requirements defined
in the TCSEC. It must be shown that all parts of the TCB
are a valid interpretation of the security policy model,
i.e., that there is no change to the secure state except as
represented by the model.
Part II: Other Security Services
____ __ _____ ________ ________
5. Introduction
_ ____________
Part I of this Interpretation contains interpretations
of the Department of Defense Trusted Computer System Evalua-
tion Criteria (TCSEC), DOD 5200.28-STD. Part I deals with
controlling access to information. Part II contains addi-
tional network security concerns. These concerns differen-
tiate the network environment from the stand-alone computer.
Some concerns take on increased significance in the network
environment; other concerns do not exist on stand-alone com-
puters. Some of these concerns are outside the scope of
Part I; others lack the theoretical basis and formal
analysis underlying Part I. The criteria in this Part II
address these concerns in the form of additional security
requirements that may vary among applications. Overlap
between Part I and Part II is minimized as much as possible.
However, when an overlap occurs the association between the
concerns addressed in both parts is defined. Part II ser-
vices may be provided by mechanisms outside the NTCB.
5.1. Purpose and Scope
_ _ _______ ___ _____
This Part II addresses network security disjoint from
Part I. The rating derived in Part I is not effected by Part
II. Every component or system must have a Part I evaluation
as a basis for the Part II evaluation. Part II includes
generic requirements, security features, and evaluation cri-
teria. As described below, Part II evaluations differ from
Part I. The purpose of these evaluations is similar, how-
ever: to provide guidance to network managers and accredi-
tors as to the reliance they can place in security services.
These evaluations are input to the accreditor's decisions
concerning the operational mode and range of sensitive
information entrusted to the network.
The network sponsor shall identify the security ser-
vices offered by his system or component(s). Those services
will be evaluated against the criteria for those services in
Part II.
5.2. Criteria Form
_ _ ________ ____
The general form of Part II criteria is a relatively
brief statement, followed by a discussion of functionality,
strength of mechanism, and assurance, as appropriate.
Functionality refers to the objective and approach of a
_____________
security service; it includes features, mechanism, and per-
formance. Alternative approaches to achieving the desired
functionality may be more suitable in different applications
environments.
Strength of mechanism refers to how well a specific
________ __ _________
approach may be expected to achieve its objectives. In some
cases selection of parameters, such as number of bits used
in a checksum or the number of permutations used in an
encryption algorithm, can significantly affect strength of
mechanism.
Assurance refers to a basis for believing that the
_________
functionality will be achieved; it includes tamper resis-
tance, verifiability, and resistance against circumvention
or bypass. Assurance is generally based on analysis involv-
ing theory, testing, software engineering, validation and
verification, and related approaches. The analysis may be
formal or informal, theoretical or applied.
For example, consider communications integrity protec-
tion against message stream modification. A functionality
decision is to select error detection only, or detection and
correction; also one may select whether it is sufficient to
detect an odd number of 
The Rainbow Books