ACKNOWLEDGMENTS
Special recognition is extended to James
N. Menendez, National
Computer
Security Center (NCSC), as project manager and co-author of this
document. Recognition is also extended to Don Brinkley
and Rick Dedrick,
Unisys, as co-authors of this document.
Special acknowledgment is given to Barbara
Mayer, NCSC, for her
invaluable
input and review of this document, which has resulted in its
current
form.
Acknowledgment is also given to all those
members of the computer
security
community who contributed their time and expertise by actively
participating in the review of this document.
TABLE OF CONTENTS
FOREWORD i
ACKNOWLEDGMENTS ii
1. INTRODUCTION 1
1.1 PURPOSE 1
1.2 SCOPE 1
1.3 CONTROL OBJECTIVE 2
2. OVERVIEW OF DESIGN DOCUMENTATION PRINCIPLES 3
2.1 PURPOSE OF DESIGN DOCUMENTATION 3
2.2 DESIGN DOCUMENTATION DEVELOPMENT FOR
EVALUATION 3
2.3 LEVEL OF DETAIL OF DESIGN DOCUMENTATION 4
2.4 LEVEL OF EFFORT FOR MEETING THE REQUIREMENTS 4
2.5 FORMAT OF DESIGN DOCUMENTATION 5
3. MEETING THE CRITERIA REQUIREMENTS 7
3.1 THE C1 DESIGN DOCUMENTATION REQUIREMENTS 7
3.2 THE C2 DESIGN DOCUMENTATION REQUIREMENTS 7
3.3 THE B1 DESIGN DOCUMENTATION REQUIREMENTS 7
3.4 THE B2 DESIGN DOCUMENTATION REQUIREMENTS 8
3.5 THE B3 DESIGN DOCUMENTATION REQUIREMENTS 9
3.6 THE A1 DESIGN DOCUMENTATION REQUIREMENTS 9
4. COMPONENTS OF DESIGN DOCUMENTATION 11
4.1 DOCUMENTING THE SECURITY POLICY 11
4.2 DOCUMENTING TCB PROTECTION MECHANISMS 14
4.3 DOCUMENTATION OF COVERT CHANNELS 16
5. OTHER TOPICS 19
5.1 MODULARITY 19
5.2 HARDWARE DESIGN DOCUMENTATION 19
5.3 CONFIGURATION MANAGEMENT 20
6. SUMMARY OF DESIGN DOCUMENTATION 23
APPENDIX A
SUMMARY OF DESIGN DOCUMENTATION REQUIREMENTS 25
APPENDIX B
EXCERPTS FROM FINAL EVALUATION REPORTS 29
B.1 CLASS C2 29
B.1.1 UTX/32S 29
B.2 CLASS B2 30
B.2.1 Multics 30
B.3 CLASS A1 31
B.3.1 SCOMP 31
GLOSSARY 33
REFERENCES 36
1. INTRODUCTION
1.1 Purpose
The
Trusted Computer System Evaluation Criteria (TCSEC) is
the standard used for evaluating the effectiveness of
security controls built
into Automated Data Processing (ADP) systems. The TCSEC is divided into four
divisions: D, C, B, and A, ordered in a hierarchical
manner, with the highest
division (A) being reserved for those systems providing
the best available
level of assurance.
Within Divisions C through A are a number of
subdivisions known as classes, which are also ordered in
a hierarchical
manner to represent different levels of trust in these
classes.
Design
Documentation is a TCSEC requirement for classes C1
and above. The
purpose of this guideline is to provide developers of trusted
computer systems with guidance in understanding and
meeting the design
documentation requirements contained in the TCSEC. To accomplish this, the
guideline addresses two goals. First, the guideline increases the vendors'
awareness of the importance of design documentation to the
security of their
system throughout the system life-cycle. Second, the guideline forms an
initial basis of understanding between the vendor and
evaluator communities
concerning what is expected by the evaluation team in the
review process and
deliverables for design documentation.
Any
examples in this document are not to be construed as
the only implementation that will satisfy the TCSEC
requirement. The examples
are merely suggested implementations. The recommendations in this document
are also not to be construed as supplementary
requirements to the TCSEC. The
TCSEC is the only metric against which systems will be
evaluated.
This
guideline is part of the Technical Guidelines Program
to provide helpful guidance on TCSEC issues and the
features they address.
1.2 Scope
Design
Documentation is a TCSEC requirement for classes C1
through A1. It is
one of the four types of documentation required by the
TCSEC. The other
three documentation requirements are for
a Trusted
Facility Manual (TFM), Security Features Users Guide
(SFUG), and Test Plan
Documentation. The
role of Design Documentation is to identify and describe
the Trusted Computing Base (TCB) and its security
features. Only Design
Documentation for the TCB is required to meet the TCSEC
requirements, but it
is strongly recommended that design documentation exist
for the entire
system. Throughout
this document, the word system will be used as the object
of design documentation to include the TCB and the
untrusted portions of the
system. However,
it should be emphasized that the TCSEC requirements are
based solely on the design documentation of the TCB.
Design
Documentation assists vendors during the system
life-cycle by thoroughly defining the policies that the
system enforces. It
also provides the material by which the evaluator can
assess whether, and to
what degree, the design intent was carried into the
implementation. The
design documentation is intended to guide the implementation
of the product;
it is not intended merely as an abstract philosophical
exercise completely
divorced from the "real" product.
Design
documentation also increases the developer's level
of understanding of the system. It should facilitate the correct
implementation of the intended behavior and features of
the system. This
guideline will discuss design documentation and its
features as they apply to
computer systems and products that are being built with
the intention of
meeting the requirements of the TCSEC.
1.3 Control Objective
Each of
the TCSEC requirements serves to ensure that one
of the three basic control objectives for trusted
computing - security policy,
accountability, and assurance - are satisfied. Throughout the system
life-cycle, design documentation aids in attaining the
third objective,
assurance, by helping to "substantiate claims for
the completeness of access
mediation and degree of tamper resistance." [5]
The
TCSEC gives the following as the Assurance Control
Objective:
"Systems
that are used to process or handle
classified or other sensitive information must be
designed to guarantee
correct and accurate interpretation of the security
policy and must not
distort the intent of that policy. Assurance must be provided that correct
implementation and operation of the policy exists
throughout the system's
life-cycle."[5]
Design
documentation plays an important role in providing
this life-cycle assurance. It demonstrates that correct implementation
and
enforcement of the system's security policy exists
throughout the system's
life-cycle. As it
relates to this control objective, design documentation
facilitates the efforts of vendors and system developers
in modifying and
maintaining the system throughout its life-cycle, without
compromising the
trustworthiness of the system.
In
addition, design documentation serves as a useful
training tool.
Design documentation presents a technical history of the
system, containing documentation on past changes to the
system as well as the
current system. It
can be used in the training of new systems programmers and
hardware engineers to familiarize them with the system.
2. OVERVIEW OF
DESIGN DOCUMENTATION PRINCIPLES
Design
documentation is a requirement for TCSEC classes C1 and
above. It provides
a means of communicating the design of a system to
developers that enables them to comprehend the design
principles of the system
and to make changes or upgrades to the system without
compromising the
trustworthiness of the system. The information contained in the design
documentation provides a rationale as to why a system is
designed as it is and
whether changes to the system will alter the intent of
the design.
Design
documentation plays an important role in the life-cycle
maintenance of a system and should not be viewed as a
burden to system
development. This
document should help developers understand the importance
of design documentation in the life-cycle of computer
systems, as well as to
the maintenance of trust in these systems. Developers should recognize the
importance of meeting the purpose and intent of the TCSEC
design
documentation requirements as opposed to meeting them in
a strictly
mechanical fashion.
2.1 Purpose of Design Documentation
The
primary purpose of design documentation is to define
and describe the properties of a system. As it relates to the TCSEC, design
documentation provides an explanation of how the security
policy of a system
is translated into a technical solution through the TCB
hardware, software,
and firmware.
Design
documentation explains the system's protection
mechanisms so that the effect a change may have on the
security of the system
can be evaluated prior to a change being performed. It relates the TCSEC
requirements to the architecture of a system and guides
the implementation of
the system under development. Complete documentation ensures that the
vendor
has an understanding of what elements of the system are
protection critical.
Design documentation explains the system design to the
vendor's development
team and enables the developers to understand the design
of the system well
enough to maintain the system and to perform any
necessary changes to it
without adversely affecting the trustworthiness of the
system. In addition,
the design documentation assists the evaluators by
providing them with a
vehicle by which the completeness and correctness of the
implementation can
be assessed.
2.2
Design Documentation Development for Evaluation
Developers
should incorporate the design documentation
requirements into the system development process. A plan that addresses each
design documentation requirement should be developed
early in the development
phase and shared with the National Computer Security
Center evaluators to
ensure the thoroughness of the documentation.
3
Iterative
development of the design documentation is the
key to minimizing vendor and evaluator efforts during the
evaluation process.
Vendors should precede their design documentation with
the submittal of an
outline of the design documentation to the
evaluators. This outline should
contain, among other things, a statement of purpose and
the intended audience
of the design documentation. Then, through a process of draft submittal,
evaluator comments and requests for additional
information, and draft revision
the design documentation requirements will be met. This guideline should
expedite this process by bringing the vendor's first
drafts closer to
evaluator expectations and by facilitating convergence
between vendor product
and evaluator expectations. If vendors establish a dialogue with evaluators
early in the design documentation development and solicit
their comments on
early and subsequent drafts of the design documentation,
both vendors and
evaluators will save a great deal of time and effort in
completing the
evaluation process.
2.3
Level of Detail of Design Documentation
The
level of detail of design documentation will determine
its usefulness and adequacy in meeting the TCSEC
requirements, as well as its
usefulness to the vendor in the development and
maintenance of the system.
For evaluators, the level of detail of the design
documentation is reviewed
to ensure that the system developer understands the
design of the system well
enough to make changes or upgrades to the system without
compromising the
trustworthiness of the system. Design documentation also ensures that the
developer understands the overall security concepts that
are required to be
part of the system design. How well the security properties of the
system
are documented, and how this information is integrated
into the design
documentation will determine whether or not the level of
detail of the design
documentation is sufficient in meeting the TCSEC
requirements.
The
design documentation shall be detailed enough to serve
as a useful tool for vendor maintenance of the system and
shall clearly
indicate what elements of the design impact the
trustworthiness of the system.
One purpose behind design documentation is to assist
vendors in maintaining
the system and should not present a burden to the vendor
in terms of quantity
or detail. A good
rule of thumb is that the level of detail of design
documentation should be sufficient to permit an
individual with a degree in
Computer Science, Electrical Engineering, or the
equivalent with knowledge and
skills in programming, hardware, or firmware development
to understand the
system design and be able to design system modifications
without adversely
affecting trustworthiness of the system.
2.4
Level of Effort for Meeting the Requirements
The
level of effort necessary for developing satisfactory
design documentation has historically been underestimated
because the intent
and implications of the TCSEC requirements for design
documentation have
seldom been completely understood. An important factor to consider when
deciding on an appropriate level of effort is the
importance of the design
documentation throughout the system life-cycle. Well structured design
documentation that is carefully planned and developed will
make it easier to
understand the design of the system.
5
The
level of effort necessary for a vendor to meet the
design documentation requirements varies from system to
system. The level of
effort generally will depend upon the necessary level of
detail, which depends
upon the class of evaluation and the complexity of the
system being evaluated.
The requirements for TCSEC classes C1 and C2 may be met
by simply following
good engineering documentation practices, but as the
TCSEC class level
increases, so does the level of detail and effort
necessary for meeting the
TCSEC requirements.
In terms
of quantity, the length of design documentation
at the higher classes has been found to be roughly
comparable in bulk to the
source listings of the overall system. In general, producing the design
documentation may require several man months to a man
year of system
development time at Classes C1 and C2, and up to several
man years at the
higher classes.
Although developing design documentation for a system may be
time consuming, this time will be amply rewarded by the
ease of system
maintainability during its life-cycle.
2.5
Format of Design Documentation
The
format and style for each vendor's design
documentation is specific to that vendor, and to suggest
a specific format
would restrict vendors in developing their design
documentation. Although
this guideline addresses distinct requirements for design
documentation, it
should not be assumed that separate documents are
necessary to meet each
requirement.
Indeed, the design documentation shall address each of the
requirements, but it is acceptable for evaluators to be
pointed to a number of
documents to address a specific requirement. Also, graphics serve as a useful
adjunct to design documentation, although not sufficient
alone to meet the
TCSEC requirement for design documentation. Developers may choose to use
graphics to describe a system in addition to other design
documentation.
Differences
among computer system architectures, designs,
and implementation approaches make developing a standard
format for design
documentation inadvisable. In addition, the format of design
documentation
for one system may be totally inappropriate for meeting
another system's
needs. The format
chosen by the vendor for presenting the design
documentation may be influenced by business concerns
other than expeditious
security evaluation.
Different design documentation formats present different
advantages and challenges to evaluators and different
advantages and costs to
vendors that should be weighed.
A
system's design may be evolutionary, resulting from
improvements that build upon an initial version. Maintaining documentation
on a system in a release/update form may be convenient
for a developer.
However, it is difficult for new developers and life-cycle personnel to
gain
an understanding of the overall system architecture from
documentation that
describes the system in chronological terms through
system releases and
updates. To be
useful, these updates shall be incorporated into the design
documentation, and the design documentation shall be
presented as a complete
description of the system, and not the initial
description plus supplemental
sections describing changes.
5
3. MEETING THE CRITERIA REQUIREMENTS
This section
lists the TCSEC requirements for design documentation
at each class. All
of these requirements have been extracted from the TCSEC
design documentation requirements and include explicit
and implicit design
documentation requirements, where necessary. Each numbered requirement is
referenced in the discussions that follow in Sections 6
and 7 of this
document. This
section serves as a quick reference for TCSEC class
requirements.
As the TCSEC
evaluation class level increases, it is implicitly
required that the design documentation be more
detailed. This is due to an
increase in assurance required at the higher classes, as
well as the
introduction of new features at the higher classes that
need to be
documented, for example, labeling, auditing.
3.1 The
C1 Design Documentation Requirements??
Requirement
1 - Describe the philosophy of protection.
Requirement
2 - Describe how the philosophy of protection
is translated into the TCB.
Requirement
3 - Describe how the TCB is modularized (if
modular).
Requirement
4 - Describe all interfaces between the TCB
modules (if modular).
Requirement
5 - Describe how the TCB protects itself.
Requirement
6 - Provide a statement of the system security
policy.
3.2 The
C2 Design Documentation Requirements
No new
requirements have been added at the C2 class.
3.3 The
B1 Design Documentation Requirements??
Requirement
7 - Provide an informal or a formal
description of the security policy model enforced by the
TCB.
Requirement
8 - Explain the sufficiency of the security
policy model to enforce the security policy.
Requirement
9 - Identify and describe the TCB protection
mechanisms.
Requirement
10 - Explain how the TCB mechanisms satisfy
the security policy model.
7
3.4 The
B2 Design Documentation Requirements
Requirement
11 - Describe how the TCB is modularized.
Requirement
12 - Describe all of the interfaces between
the TCB modules.
Requirement
13 - Provide a formal description of the
security policy model.
Requirement 14 - Prove the sufficiency of the
security
policy model to enforce the security policy.
Requirement
15 - Show that the Descriptive Top Level
Specification (DTLS) is an accurate description of the
TCB interface.
Requirement
16 - Describe how the TCB implements the
Reference Monitor Concept.
Requirement
17 - Describe why the reference monitor is
tamper resistant.
Requirement
18 - Describe why the reference monitor cannot
be bypassed.
Requirement
19 - Describe why the reference monitor is
correctly implemented.
Requirement
20 - Describe how the TCB is structured to
facilitate testing.
Requirement
21 - Describe how the TCB is structured to
enforce least privilege.
Requirement
22 - Present the results and methodology of
the covert channel analysis.
Requirement
23 - Describe the tradeoffs involved in
restricting covert channels.
Requirement
24 - Identify all auditable events that may be
used in exploitation of known covert storage channels.
Requirement
25 - Provide the bandwidths of known covert
storage channels whose use is not detectable by auditing
mechanisms.
8
3.5 The
B3 Design Documentation Requirements
Requirement
26 - Identify all auditable events that may be
used in exploitation of known covert timing channels.
Requirement
27 - Provide the bandwidths of known covert
timing channels whose use is not detectable by auditing
mechanisms.
Requirement
28 - Describe how the system complies with
additional B3 system architecture requirements, for
example, minimal TCB and
layering.
Requirement
29 - Informally show consistency of the TCB
implementation (in hardware, firmware, and software) with
the DTLS.
Requirement
30 - Informally show correspondence between
elements of the DTLS and elements of the TCB.
Requirement
31 - Informally show consistency of the DTLS
with the model.
9
3.6 The
A1 Design Documentation Requirements
Requirement
32 - Informally show consistency of the TCB
implementation with the Formal Top Level Specification
(FTLS).
Requirement
33 - Informally show correspondence between
elements of the FTLS and elements of the TCB.
Requirement
34 - Clearly describe hardware, software, and
firmware internal to the TCB that is not dealt with in
the FTLS.
Requirement
35 - Informally or formally show consistency
of the FTLS with the model.
Requirement
36 - Informally show correspondence between
the FTLS and the DTLS.
9
4. COMPONENTS OF DESIGN DOCUMENTATION?
Design
documentation describes why a system is trusted, how this
trust is achieved, the mechanisms which provide the
trust, and the relevant
information that makes proper maintenance of a system
possible. Design
documentation at TCSEC class C1 lays the foundation for
trusted systems by
defining the philosophy of protection of a system. As the TCSEC classes
increase, the level of detail and the quantity of
information contained in
the design documentation shall also increase. The following sections discuss
design documentation and its role in describing the
security policy of the
system, the protection mechanisms of the system, and the
specific
requirements concerning covert channels.
4.1
Documenting The Security Policy
The
design and development of any trusted system, from
TCSEC class C1 to A1, is based upon a philosophy of
protection that shall be
described in the design documentation (Requirement
1). Design documentation
explains and defines the philosophy of protection by
describing how a system
provides trust. Trust
in computer systems is provided by the protection
mechanisms contained within the TCB, such as
discretionary access controls and
identification and authentication mechanisms. These and all of the TCB
mechanisms and their functions shall be described in the
design documentation.
In addition, the system security policy, i.e., what is
being accessed by whom
or from what, shall also be described in the design
documentation (Requirement
6).
In order
to describe how a system is trustworthy, the
design documentation shall describe how the philosophy of
protection is
translated into the TCB (Requirement 2) and how it is
supported by the TCB
protection mechanisms.
The design documentation shall first define the
boundaries of the system and shall describe the parts of
the system that are
security relevant and the parts that are not. Rationale shall be presented
that those portions of the system which are claimed to be
outside of the TCB,
are really outside.
The proper identification of these parts is important to
the maintenance of security in the system because it is
necessary to know when
a change to the system will affect the TCB
implementation, and possibly
violate the security policy of the system.
At the
higher TCSEC classes, the description of the
philosophy of protection evolves into a more structured
description of how a
system provides trust.
At TCSEC class B1, this philosophy of protection shall
be presented as an informal or formal security policy
model in the design
documentation (Requirement 7). This security policy model shall informally
or
formally define the subjects, objects, modes of access,
and the security
properties of the system.
In addition, the model shall define the initial
state of the system, a secure state of the system, and
the way in which the
system progresses from one state to the next. An informal security policy
model may be presented in a natural language, for
example, English. An
explanation shall be provided demonstrating that the informal
model is
sufficient to enforce the security policy (Requirement
8).
11
At TCSEC
class B2, a formal security policy model shall
exist (Requirement 13).
In addition to the B1 requirements, the formal
security policy model shall contain: a set of security
properties that
captures the security policy, an abstract description of
the operations
performed by the TCB, and a rigorous argument through the
use of predicate
calculus that the description is consistent - internally
consistent, that is,
is not self-contradictory. The model shall include a proof that if the
initial state of the system satisfies the definition of a
"secure" state and
if all assumptions of the model are satisfied, then all
future states of the
system will be secure.
A
security policy model provides assurance that the system
has been designed to enforce the security policy and
provides a basis for the
TCB implementation.
As a means of increasing assurance, the design
documentation shall show that the security policy model
is sufficient to
enforce the security policy of the system (Requirement
8). At TCSEC class B1,
it shall be sufficient to show this in a natural
language, e.g., English, but
at class B2, this sufficiency of the security policy
model shall be shown
through a formal proof (Requirement 14). The design documentation shall
provide a mapping of the security properties to the
security policy. This
sufficiency shall be demonstrated by describing how all
aspects of the
security policy are addressed by the security policy
model.
An
example of a formal security policy that enforces the
DoD security policy is the Bell-La Padula model [1]. Although the Bell-La
Padula security policy model supports the DoD security
policy, it is important
to realize that this does not mean that the Bell-La
Padula model model can be
directly used for all systems. The Bell-La Padula model, when used with
different systems, will need to be representative of the
system.
At TCSEC
class B2, the TCSEC design specification and
verification requirement calls for a descriptive top
level specification
(DTLS) of the TCB to be maintained to provide documentary
evidence of how the
formal security policy model is implemented through the
TCB interface. The
DTLS provides evaluators with a better understanding of
the implementation of
the reference monitor and provides maintenance personnel
with the necessary
documentation to correct, modify, or augment the TCB
without destroying the
TCB's cohesiveness and internal consistency. The description of the TCB
should contain a description of the services and
functions provided by the
TCB and how they are invoked. For example, for UNIX1-based systems, the
DTLS
may be based upon enhanced manual pages. The manual pages shall include
enough information to satisfy the design specification
and verification
requirement that the TCB be described in "terms of
exceptions, error
messages, and effects."[5] These individual manual
sections should be
accompanied by detailed section headers which clearly
explain the security
concepts and entities referenced within each
section. The design
documentation shall demonstrate that the DTLS is an
accurate description of
the TCB interface (Requirement 15). It should do this by accurately and
completely describing the DTLS in relation to the TCB
interface.
The
design documentation shall be used to test against the
TCB to, "demonstrate that the TCB implementation is
consistent with the
descriptive top level specification." [5] The design documentation shall
describe how the TCB is structured to facilitate this
testing (Requirement
20).
------------------------------------
1 UNIX is a trademark of AT&T Bell Labs
12
At TCSEC
class B3, the design documentation shall
informally show consistency of the TCB hardware,
firmware, and software
implementation with the DTLS as well as showing
correspondence between
elements of the DTLS and elements of the TCB
(Requirements 29, 30). The goal
of these two requirements is to ensure that the mapping
between the TCB and
DTLS is complete, easily understandable, unambiguous, and
one-to-one between
elements of the TCB implementation and elements of the
DTLS. The level of
detail of this mapping should be sufficient for any
inconsistency to be
obvious to members of the vendor's development team
throughout the system
life-cycle.
Also at
TCSEC class B3, the design documentation shall
provide a mapping from the DTLS to the TCB implementation
(Requirement 30).
This mapping should demonstrate that all elements that
were specified were,
in fact, implemented, and that any code that appears
which is not specified
directly merely reflects implementation detail; that
there are no new,
unspecified, user interfaces implemented. With this mapping, the design
documentation shall describe all areas of correspondence
between elements of
the DTLS and elements of the TCB. For example, the mapping may be pointers
in the DTLS description to source code modules of the TCB
implementation.
The
addition of the design specification and verification
requirement of a mapping between the DTLS and the formal
security policy
model completes the evidence from the security policy to
implementation. The
entities of the model shall be shown to correspond to the
elements of the
DTLS (Requirement 31).
This correspondence provides assurance that the
security properties that are proven in the formal model
are accurately
reflected in the implementation.
At TCSEC
class A1, the mapping shall be from the formal
top level specification (FTLS) to the TCB (Requirements
32, 33). In addition,
the mapping to the model shall be from the FTLS
(Requirement 35). These
changes reflect the introduction of an FTLS requirement
in the design
specification and verification requirements at A1. The design documentation
shall describe how the FTLS accurately represents the TCB
interface. The
hardware/firmware components of the TCB, such as mapping
registers and direct
memory access input/output (I/O) components, that are
directly or indirectly
visible at the TCB interface shall be described in the
design documentation.
As stated previously, the goal of these requirements is
to ensure that the
mapping between the elements of the TCB implementation
and the FTLS are
complete, easily understandable, unambiguous, and
one-to-one.
Although
the TCSEC design documentation requirement
changes at class A1 to require a mapping from the FTLS to
the TCB, a DTLS is
still required for class A1 systems. At TCSEC class A1, the DTLS serves to
augment the FTLS by completing the description of the TCB
in an informal
language and by providing the conceptual glue to the
specification of the
reference monitor mechanism and the other TCB
components. Since there is an
explicit requirement at class A1 that both the FTLS and
DTLS correspond to the
formal security policy model, the DTLS and the FTLS must
correspond
(Requirement 36).
At TCSEC class A1, "the FTLS and DTLS may be two separate
documents, or they may be combined into a Complete Top
Level Specification
(CTLS). In a CTLS,
the FTLS and DTLS portions (shall) be separately
identifiable. The
CTLS (shall) be a complete and accurate description of the
TCB, and it (shall) be sufficiently well
commented/annotated so that it can be
easily understood with little or no knowledge of formal
specifications."[8]
13
It is
recognized that not all of the TCB internals are
able to be specified within the FTLS. For the hardware, firmware, and
software internal to the TCB, but not dealt with in the
FTLS, the design
documentation shall describe them in complete, clear, and
careful detail
(Requirement 34).
4.2 Documenting TCB Protection Mechanisms??
As part
of the description of the philosophy of protection
and how it translates into the TCB, the design
documentation shall include
explanations of the security services offered by the TCB
software, hardware,
and firmware mechanisms from a system level view
(Requirement 2). At TCSEC
class C1, the design documentation for these protection
mechanisms shall
include how the mechanisms protect the TCB from tampering
(Requirements 5).
The description of why the TCB is tamper resistant is an
important
requirement for all of the TCSEC classes. This design documentation
requirement supports the TCSEC class C1 system
architecture requirement which
calls for the TCB to maintain a domain that implements
the reference monitor
concept that, "protects it from external
interference or tampering"[5]. The
mechanisms described in this section of the design
documentation include
things such as Discretionary Access Control (DAC) and
identification and
authentication (I&A) mechanisms. For example, the design documentation shall
describe the DAC enforcement mechanism and how it
controls discretionary
access between named users or groups and named objects
within the ADP system.
As it relates to
identification and authentication, the design documentation
shall describe how users are identified to the TCB and
the mechanism that
authenticates the user's identity. Furthermore, the design documentation
shall describe how the TCB protects the authentication
data. To ensure that
these mechanisms have not failed in any way, hardware and
software mechanisms
shall exist to periodically validate the correct
operation of the on-site
hardware and firmware elements of the TCB. These system integrity mechanisms
shall also be described in the design documentation.
At TCSEC
class B1, the design documentation shall identify
and provide descriptions of the TCB protection mechanisms
(Requirement 9).
This documentation
is required to provide the additional assurance required
at TCSEC class B1.
In most cases, these TCB protection mechanisms at TCSEC
class B1 may be the same protection mechanisms that were
described in TCSEC
class C1, but at class B1, the description of these
mechanisms shall describe
how they support the additional system architecture
requirement for process
isolation. Process
isolation mechanisms that prevent untrusted subjects from
directly accessing separate address spaces are introduced
at TCSEC class B1
and shall be described in the design documentation. The design documentation
shall also show that all of the security services
required by the security
policy model are provided by the TCB mechanisms
(Requirement 10).
14
At TCSEC
class B2, the design documentation shall describe
how the TCB protection mechanisms implement the reference
monitor concept,
i.e., is nonbypassable, always invoked, and small enough
to be analyzed
(Requirement 16).
The design documentation requirement should demonstrate how
the reference validation mechanism is tamper resistant,
cannot be bypassed, is
correctly implemented, and is structured to enforce least
privilege
(Requirements 17, 18, 19, 21). Although a reference monitor has been in
place
since TCSEC class C1, the system architecture requirements
at TCSEC class B2
require that the TCB be protected, "from external
interference and tampering,"
maintain process isolation, and be "internally
structured into well defined
largely independent modules."[5] These additional
requirements shall be
reflected in the design documentation.
One
position for how the reference monitor hardware should
be documented is presented in the following paragraphs:
"For
microprograms (firmware), design documentation is
needed for common routines, that is, documentation which
fully describes the
functionality and what is done to implement that
functionality. At the least,
a high level view of major operations, e.g., interrupts,
I/O instruction
interpretations is needed if the microcode is not modular
enough to be
described in terms of microroutines.
For
items inside the TCB, but outside of the reference
monitor (such as most disk controllers, printers, and
other peripherals), the
interface must be described, but not the internals.
In the
case of systems that do not use microcode,
convincing arguments must be provided as to what elements
of the hardware are
security critical and why."[2]
The
design documentation for the TCB firmware should
parallel the documentation that is written for the TCB
software, that is, it
should fully describe the functionality and what is done
to implement the
functionality of the security kernel.
Assurance
needs to be provided that the TCB is protected
from modification.
At TCSEC class B2, the design documentation shall provide
this assurance through a description of why the reference
monitor is tamper
resistant (Requirement 17). This description shall include the methods
and
mechanisms by which the TCB protects itself from illicit
modification. Any
hardware mechanisms used by the TCB to separate
protection critical elements
from those that are not protection critical shall be
described. The
mechanisms used by the TCB to help support logically
distinct storage objects
with separate attributes shall also be described. The mechanisms used to
protect against illicit modification may include some of
the same mechanisms
used to mediate accesses of objects by subjects that were
introduced at TCSEC
class C1. These
mechanisms shall be described again at TCSEC class B2, but in
greater detail as to how they apply to the reference
validation mechanism.
15
The
previous paragraph explained how the design
documentation describes protection mechanisms, but more
importantly, at TCSEC
class B2, the design documentation shall show that all of
the TCB software,
firmware, and hardware mechanisms have been implemented
as described and that
the implementation functions correctly (Requirement
19). The design
documentation shall justify the correctness of the entire
TCB.
Also, at
TCSEC class B2, the design documentation shall
describe how the TCB is structured to enforce least
privilege (Requirement
21). This
description shall relate to the hardware, firmware, and software
modules of the TCB, as well as to the enforcement of
least privilege both
within the TCB and upon trusted subjects. Least privilege ensures that any
TCB module or trusted process has only those privileges
and capabilities
needed for it to perform the specific function for which
it was designed.
For example, if the hardware architecture implements
protection rings, a
description shall be given of the ring mechanisms. This description shall
show how access to the innermost ring provides a means of
running highly
privileged processes, while the outermost ring provides a
means of running
unprivileged processes.
Likewise, the description shall justify placement of
functions within the higher privileged rings and the
conferring of special
privileges to trusted processes. Thus, the hardware is shown as a means of
enforcing least privilege.
Similarly,
firmware and software mechanisms may provide a
means of enforcing least privilege. For example, a labeling mechanism may be
implemented in software or firmware. Because labels may be used to enforce
least privilege, the software or firmware modules
enforcing the labeling and
label based access control shall be shown as a means of
enforcing least
privilege.
The
separation of administrative roles in the system is
one more way in which least privilege may be
exercised. In this case, the
roles of system administrator, security administrator,
and/or system auditor
may be performed by separate individuals. This is to ensure that the security
functions of the system are not able to be performed by a
single person. The
way these roles are carried out in the system shall be
described in the design
documentation.
At TCSEC
class B3, the system architecture requirements
call for the TCB to be minimized, i.e., only security
relevant functions
appear within the TCB.
The TCB at this class, "shall incorporate significant
use of layering, abstraction, and data hiding," and
shall have minimal
complexity. The
design documentation shall describe how the system complies
with these additional architectural requirements in
(Requirement 28). As
stated previously, as the TCSEC classes increase and the
implementation`o& the
reference monitor concept becomes more defined, the
amount of design
documentation shall also increase.
4.3
Documentation of Covert Channels
A
portion of the B2 requirements for design documentation
addresses covert channels. The results of all covert channel analysis
need
to be in the design documentation to aid in the design
and development of TCB
mechanisms. For
this reason, the design documentation shall present the
results of the covert channel analysis and the
methodology used (Requirement
22). The design
documentation shall provide an overview of the covert
storage channel analysis and testing procedures. It shall document the
results of these tests and all of the covert channels
identified. All
auditable events shall be identified and described for
all covert storage
channels that are not removed from the system
(Requirement 24).
16
When
covert channels are identified, actions are sometimes
taken to restrict the bandwidth of those channels. The design documentation
shall describe and discuss these actions and the
resulting degree of covert
channel restriction in light of performance degradation,
operational utility,
or other considerations (Requirement 23). Processing delays resulting from
reducing the number and bandwidth of covert channels shall
be identified and
characterized. The
design documentation shall also note whether the
exploitation of known covert channels is auditable. There will be some
covert storage channels whose use will not be detectable
by auditing
mechanisms. The
design documentation shall document the worst case and
expected case bandwidths of these storage channels whose
exploitation is not
auditable (Requirement 25).
At TCSEC
class B3, the design documentation shall
recognize the introduction of covert timing channels into
the requirements and
shall consider them in all covert channel related
descriptions as stated above
(Requirements 26, 27).
The covert timing channel analysis and testing
procedures, and the results obtained from the tests shall
be described in the
design documentation.
Additionally at TCSEC class A1, formal methods shall be
used in the covert channel analysis and shall be
described in the design
documentation.
19
5. OTHER TOPICS?
5.1
Modularity
An important
architectural feature of trusted systems for
TCSEC class B2 and above is that the TCB be modular. The modularity of the
TCB is important for ease of understanding, ease of
analysis, and ease of
maintenance.
Modularity ensures that interfaces are well defined and errors
are contained. It
also provides a basis for enforcing least privilege. The
content of hardware and software modules should be
selected based on the
following criteria: a module performs exactly one well
defined action, a
module has a well defined interface, a module interacts
with other modules
only in well defined ways, and a module is called upon to
perform a function
whenever that function is required. Although TCB modularity is not a
requirement until class B2 (Requirements 11, 12), it is
possible that vendors
would want to build systems with modular TCBs at the
lower classes.
Regardless of class, if the TCB is modular, the design
documentation shall
describe how the TCB is modular and the interfaces between
the TCB modules
(Requirement 3, 4).
As with all design documentation, the level of detail
shall permit the description of the interfaces between
the modules to be a
useful description.
Specifically, the design documentation shall include
identification of the TCB hardware, software, and
firmware modules, why the
modules are considered as such, the interfaces between
them, and the
implementation of the modules. A mapping of the security services and
mechanisms to the modules should also be described.
The
level of detail of the design documentation increases
the amount of assurance to be gained by the developers
and evaluators. The
description of the interfaces between the modules,
whether hardware, firmware,
or software, shall describe the types and sources of
information passing
between them (Requirement 4). In addition, the interfaces between these TCB
modules and other system modules external to the TCB
shall be described. This
description is necessary to show that no breach of
security can occur through
the interfaces.
In some
cases, software modules may depend upon hardware
or firmware modules to perform correctly and these
dependencies should also be
included in the design documentation.
5.2
Hardware Design Documentation
Hardware
design documentation for a system shall be
provided at all levels of trust. Specifically, at TCSEC classes B2 and above,
it is felt that the hardware design documentation is
critical to the security
of a system. At this
class, systems "shall make effective use of available
hardware to separate those elements that are protection
critical from those
that are not."[5] To meet this TCSEC requirement,
developers should know the
hardware base they are building on top of. Also, evaluators will need the
hardware design documentation in order to evaluate that
the vendor is making
"effective use" of the hardware.
19
The
hardware design documentation includes descriptive
information about the system's Central Processing Unit(s)
(CPU), Memory
Management Unit(s) (MMU), and all other additional
processors, for example,
I/O Processors, channel devices. The hardware design documentation is
intended to discuss what the hardware is meant to do, but
does not need to
include details of implementation, such as the flow of
control to perform a
specific action.
The hardware design documentation for every logical module
in the hardware base should include a functional name,
functional
description, and a functional interface of that module.
The
hardware design documentation defines the hardware
portion of the TCB interface. The information on the hardware interface is
important to correctly develop TCB routines and device
drivers.
Additionally, the hardware design documentation provides
sufficient
information that the TCB meets the System Architecture
requirements of the
TCSEC.
The
information contained in the hardware design
documentation shall be complete, specifying all possible
interfaces to the
system hardware, including the user-to-hardware interface
as well as the TCB
software-to-hardware interface. The hardware design documentation should
include unprivileged instructions, privileged
instructions, unpublished
instructions, and all CPU-to-MMU, CPU-to-Channel,
CPU-to-I/O bus, and
additional processor interactions. Also, the software interface visible
registers that exist on the CPU, MMU, and other
processors shall be described
in the hardware design documentation.
The
design documentation for some hardware modules may
require internal detail down to a bit level functional
description of the
module. The
modules that fall into this category are those that make up the
reference monitor, such as the address translation
module, process isolation
support module, fault handling module, I/O control
module, and the diagnostic
module. These
hardware modules of the reference monitor directly support
security and will require an explanation of why the
reference monitor is
"tamper resistant, cannot be bypassed, and is
correctly
implemented."[5]
5.3
Configuration Management
The
design documentation for the system shall be under
configuration management for the entire life-cycle of the
system. Design
documentation is only useful if it is complete and
accurate. This means that
any change to the system should also result in a change
to the design
documentation for the system.
The
design documentation for a system should be treated as
a configuration item for the system and should be subject
to the
identification, control, accounting, and audit functions
of configuration
management.
"Initial phases of configuration control are directed towards
control of the system configuration as defined primarily
in design documents.
Often a change to one area of a system may necessitate a
change to another
area. It is not
acceptable to only write documentation for new code or newly
modified code, but rather documentation for all parts of the
TCB that were
affected by the addition or change shall be updated
accordingly. Although
documentation may be available, unless it is kept under
configuration
management and updated properly it will be of little, if
any use. In the
event that the system is found to be deficient in
documentation, efforts
should be made to create new documentation for areas of
the system where it is
presently inadequate or nonexistent."[7]
20
The
TCSEC requirements for configuration management do not
begin until TCSEC class B2, but this should not mean that
the design
documentation for TCSEC class C1 to B1 systems not be
under some type of
control. At these
lower classes, the control process for the design
documentation may be less formal than that required by
the configuration
management requirements, but it should still provide
assurance that the
design documentation accurately describes the current
system.
The
National Computer Security Center has recently
developed the Ratings Maintenance Program (RAMP) which
requires configuration
management at these lower classes of trust. "By training vendor personnel to
recognize which changes may adversely affect the
implementation of the
security policy of the system, and to track these changes
to the evaluated
product through the use of configuration management, RAMP
will permit a vendor
to maintain the rating of the evaluated product without
having to reevaluate
the new version." [7]
For
further information about the RAMP program and about
the configuration management requirements for RAMP,
contact:
National
Computer Security Center
9800
Savage Road
Fort
George G. Meade, MD 20755 6000
Attention:
C12
23
6. SUMMARY OF
DESIGN DOCUMENTATION
Design
documentation is responsible for describing systems at all
levels of trust.
During the life-cycle of a system, it describes the system
to facilitate changes and maintenance of the system. As it relates to the
security of a system, design documentation provides
assurance by describing
how a system provides trust and shows that all of the
protection mechanisms
of a system are correctly implemented and sufficiently
provide the needed
trust. At the
lower classes, design documentation begins to describe how
security is provided in a system by stating the
philosophy of protection of
the system. At
TCSEC class B1, the design documentation describes the
security policy model of a system, and at TCSEC class B2
the security policy
model is required to be formal.
Many of the
other requirements in the TCSEC are related to design
documentation.
Design documentation shall describe how these requirements
are satisfied.
Covert channels are specifically addressed in the design
documentation requirement. The assurance provided by design
documentation is
dependent upon its thoroughness and accuracy. When design documentation is
written, the role that it plays in the system life-cycle
should be kept in
mind. A new
employee should be able to look at the design documentation and
get an understanding of what the current system is and
how it works. The key
word in design documentation is current. When a system changes, the design
documentation shall change accordingly. By accurately describing a system,
design documentation provides assurance that there is an
understanding of how
and why the system provides trust. In addition, it provides information that
will enable developers to analyze changes to the system
to ensure that they
do not adversely affect the trustworthiness of the
system.
APPENDIX
B
EXCERPTS FROM
FINAL EVALUATION REPORTS
This appendix
reproduces excerpts from Final Evaluation Reports for
products currently on the Evaluated Products List. The excerpts are
reproduced from the "Applicable Features"
portion of the section describing
how the product met the requirements for Design
Documentation.
The Final
Evaluation Reports are available from the National
Computer Security Center.
However, most of the vendor documents mentioned in
this appendix contain proprietary information, and
therefore are not publicly
available. Please
do not request copies of the vendor documents from the
National Computer Security Center.
B.1 CLASS C2
B.1.1
UTX/32S [6]
The
following documents were provided to the evaluation
team in fulfillment of the Design Documentation
criterion:
"Security
Policy Model"
"Program
Maintenance Manual UTX/32S, Release 1.0
(DRAFT)".
"System
Calls" and "Maintenance" in the "System
Administrator's Reference Manual".
"4.2BSD
and UTX-32 Differences Study for Gould
UTX/32S"
"Memory
Management for Gould UTX/32S"
"Object
Reuse Study for Gould UTX/32S"
The
"Gould UTX/32S 1.0 Security Policy Model" describes
Gould's philosophy of protection and explains how this
philosophy is
translated into the TCB.
It identifies all elements comprising
the TCB,
including the kernel, programs, data files, and
processes. Subjects and
objects are identified, and the mediation of accesses
between them is
described. A
mapping from the TCB to the security philosophy is provided,
and the discretionary access control, identification and
authentication, and
audit features and mechanisms are described. Additionally,
the document
discusses the role of secure sockets in interprocess communications. The
"Gould UTX/32S 1.0 Security Policy Model"
identifies all programs comprising
the TCB.
The
kernel interface is described by the "System Calls"
section of the "System Administrator's Reference
Manual". The
"Maintenance"
section of the reference manual comprises manual pages
useful for systems
programmers in maintaining UTX/32S. "4.2BSD and
UTX-32 Differences Study for
Gould UTX/32S" describes differences between 4.2BSD
UNIX and Gould UTX/32
1.2. Using
"4.2BSD and 4.3BSD as Examples of the UNIX System," by J.S.
Quarterman, A. Silberschatz, and J.L. Peterson
(Computing Surveys, Vol. 17,
No. 4, December 1985, pp. 379-418), as a baseline, the document identifies
all instances where Gould UTX/32 differs from the
described UNIX system.
29
The
"UTX/32S Program Maintenance Manual" describes code
modifications made to UTX/32 to meet the requirements of
the "Gould UTX/32S
1.0 Security Policy Model". The document includes an overview of the
mechanisms implemented in UTX/32S to strengthen security
and to correct
problems found in UTX/32 and other UNIX systems, and detailed descriptions
for: the implementation of trusted servers to replace the
functionality of
the eliminated setuid and setgid bits; kernel
modifications; auditing
mechanisms; and additions, deletions, and
modifications to utilities and
libraries. Each
module description includes an overview, a functional
specification, and a design specification. Pointers to source code, which
Gould made
available to the evaluation team are provided.
Security
critical features of the Gould PowerNode hardware
used by UTX/32S are
described in "UTX/32S Traps and Interrupts and Memory
Management for Gould UTX/32S." "UTX/32S Traps and Interrupts" describes how
UTX/32S makes use of the trap and interrupt facilities to
interface with the
hardware and process
environments. "Memory
Management for Gould UTX/32S"
describes how UTX/32S uses the memory management
facilities of the PowerNode
hardware to provide the process environment. Both
documents include
applicable material from "Gould SS 6 (Virtual Mode), V6, and V9 Central
Processing Unit Reference Manual".
"Object
Reuse Study for Gould UTX/32S" provides details
regarding how UTX/32S hardware and software manage system
objects. This
study identifies the system resources which can be
allocated and deallocated,
and details the strategies used to ensure that one
process cannot gain access
to the resources or data previously allocated to another
process. This
study, along with "Memory Management for Gould
UTX/32S", provides a good
description of UTX/32S design features which are used to
meet the Object
Reuse criterion.
B.2 CLASS B2
B.2.1
Multics [3]
The
following documents satisfy the Design Documentation
requirement:
Applicable
Features
The
"Computer Security Model: Unified Exposition
and MULTICS Interpretation" provides a description
of Honeywell's philosophy
for protection and how this is translated into the
TCB. The security model
enforced by the TCB is the Bell-La Padula model.
Multics
has a set of Multics Design Documents (MDDs) that
describe the TCB.
(These documents are Honeywell Internal Documentation and
are available only through the vendor by request. Honeywell reserves the
right to deny such requests.) The MDDs are organized by major TCB service
or
function. These
design documents describe the interfaces between TCB
modules, how the TCB implements the reference monitor,
and how the TCB is
structured to facilitate testing and enforce least
privilege.
These
documents coupled with the Honeywell produced
"Multics Interpretation," referenced in the
previous paragraph identify the
security protection mechanisms and explain how they
satisfy the model.
30
The DTLS
is an accurate description of the TCB interface.
The "Covert Channel Analysis" describes all
identified covert channels, how
they can and cannot be restricted, how they are audited,
and their bandwidths.
B.3 CLASS A1
B.3.1
SCOMP [4]
The
following documents satisfy the Design Documentation
requirement:
The
manufacturer's philosophy of protection is
documented in
"SCOMP: A Solution to the
Multilevel Security Problem" and
its translation into the TCB given in "SCOMP Trusted
Computing Base." The
interfaces between the TCB modules are described in the
several Part II
specifications,
"Detail
Specification for SCOMP Kernel Part I,
Release 2.1"
"Detail
Specification for SCOMP Kernel Part II,
Release 2.1"
A formal
description of the security policy model (Bell-La
Padula) that is enforced by the TCB is given in
"Secure Computer Systems",
for the general case and Multics in particular in
"Computer Security Model:
Unified Exposition and MULTICS Interpretation". The Bell-La Padula Model has
been accepted by the National Computer Security Center to
model security
policy "Security Requirements for Automatic Data
Processing Systems" and to
be consistent with its axioms. An interpretation of the model for the SCOMP
system is given in "SCOMP Interpretation of the
Bell-La Padula Model."
The
specific TCB protection mechanisms are 1) protection
rings, 2) SPM
mediation of per user virtual memory, 3) minimum privilege for
each TCB function, 4) integrity levels for users, operators, administrators,
and security administrators, 5) individual trusted
software processes for
separate functions, and 6) ring gates and checks on
parameter passing. The
Part II Specifications previously referenced provide the
necessary
documentation for satisfaction of this requirement. The explanation given to
show that the TCB protection mechanisms satisfy the model
appears in "SCOMP
Interpretation of the Bell-La Padula Model."
Section
3 of "SCOMP Trusted Computing Base" describes the
SCOMP TCB reference monitor implementation. An analysis of the Reference
Monitor appears in Appendix C and concludes that the
informal proofs that the
SCOMP system implements the reference monitor concept are
adequate.
31
The TCB
implementation was shown to be consistent with the
FTLS by specification to source code mappings
"FTLS
to Code Mapping for the SCOMP Kernel
Software"
"FTLS
to Code Mapping for SCOMP Trusted
Software"
"Justification
for Unspecified Code for the
SCOMP Kernel Software, Release 2.1"
"Justification
for Unspecified Code for SCOMP
Trusted Software"
TCB
testing is documented in:
"SCOMP
Kernel Test Procedures"
"SCOMP
Kernel Functional Test Summary"
"Kernel
Software Test Report for the SCOMP,
Release 2.1"
"Trusted
Software Test Plan for the SCOMP"
"Trusted
Software Test Report for the SCOMP,
STOP Release 2.0"
"Trusted
Software Test Report for the SCOMP,
Appendix A:Test Programs, Appendix B: Test Results"
"SCOMP
Test and Verification Software
Description, Rev.
3"
The TCB
structure provided added assurance of the validity
of the testing and helped to demonstrate the
implementation of least
privilege. The
results of the covert channel analysis including conservative
bandwidth estimates are presented in "Covert
Channels in the SCOMP Kernel" and
"Flow and Covert Channel Analysis for SCOMP Trusted
Software, Release 2.1." 61
Auditable events, identified in Section 13 of "SCOMP
Trusted Facility Manual,
STOP Release 2.1", and the scheme of randomly
selected delays on exception
returns appear to satisfactorily limit the utility of the
identified covert
channels.
Finally,
the internal TCB mechanisms that are not security
related and hence not dealt with in the FTLS are
described in the commercial
Honeywell Level 6 documentation ("Honeywell Level 6
Minicomputer Systems
Handbook, CC71" and "Honeywell Level 6
Communications Handbook, AT97-02D"),
and the SCOMP system unique specifications:
"Detail
Specification for SCOMP Kernel Part I,
Release 2.1"
"Detail
Specification for SCOMP Kernel Part II,
Release 2.1".
32
GLOSSARY
Access
A
specific type of interaction between a subject
and an object that results in the flow of information
from one to the
other.[9]
Access Attribute
Characteristic
of an access of an object that
specifies possible results of the access. Four example access attributes
follow: execute (processing based upon the object accessed, but neither
altering nor viewing
capability); read (viewing but not altering
capability); append (altering but not viewing
capability); and write (both
altering and viewing capabilities).[1]
Audit Trail
A
chronological record of system activities that
is sufficient to enable the reconstruction, reviewing,
and examination of the
sequence of environments and activities surrounding or
leading to an
operation, a procedure, or an event transaction from its
inception to final
results.[9]
Covert Channel
A
communication channel that allows two
cooperating processes to transfer information in a manner
that violates the
system's security policy.
Also called confinement channel.[9]
Covert Storage Channel
A
covert channel that involves the direct or
indirect writing of a storage location by one process and
the direct or
indirect reading of the storage location by another
process. Covert storage
channels typically involve a finite resource (e.g.,
sectors on a disk) that is
shared by two subjects at different security levels.[5]
Covert Timing Channel
A
covert channel in which one process signals
information to another by modulating its own use of
system resources (e.g.,
CPU time) in such a way that this manipulation affects
the real response time
observed by the second process.[5]
Descriptive Top Level Specification (DTLS)
A
top level specification that is written in a
natural language (e.g.,
English), an informal program design notation, or a
combination of the two.[5]
33
Formal Security Policy Model
A
mathematically precise statement of a security
policy. To be
adequately precise, such a model must represent the initial
state of a system, the way in which the system progresses
from one state to
another, and a
definition of a "secure" state of the system. To be
acceptable as a basis for a TCB, the model must be
supported by a formal
proof that if the initial state of the system satisfies
the definition of a
"secure" state and if all assumptions required by the model hold, then
all
future states of the system will be secure. Some formal modeling techniques
include: state transition models, temporal logic models,
denotational
semantics models, algebraic specification models. An example is the model
described by Bell-La Padula.[9]
Formal Top Level Specification (FTLS)
A
top level specification that is written in a
formal mathematical language to allow theorems showing
the correspondence of
the system specification to its formal requirements to be
hypothesized and
formally proven.[9]
Least Privilege
This
principle requires that each subject in a
system be granted the most restrictive set of privileges
needed for the
performance of authorized tasks. The application of this principle limits
the damage that can result from accident, error, or
unauthorized use.[9]
Object
A
passive entity that contains or receives
information.
Access to an object potentially implies access to the
information it contains.
Examples of objects are: records, blocks, pages,
segments, files, directories, directory trees, and
programs, as well as bits,
bytes, words, fields, processors, video displays,
keyboards, clocks,
printers, and
network nodes.[9]
Reference Monitor Concept
An
access control concept that refers to an
abstract machine that mediates all accesses to objects by
subjects.[9]
Security Kernel
The
hardware, firmware, and software elements of
the Trusted Computing Base that implement the reference
monitor concept. It
must mediate all accesses, be protected from
modification, and be verifiable
as correct.[9]
Security Level
The
combination of hierarchical classification
and a set of nonhierarchical categories that represents
the sensitivity of
information.[9]
Security Mechanism
A
system or means of implementing a security
service within a system.
34
Security Policy
The
set of laws, rules, and practices that
regulate how an organization manages, protects, and
distributes sensitive
information.[9]
Security Policy Model
A
formal presentation of the security policy
enforced by the system.
It must identify the set of rules and practices that
regulate how a system manages, protects, and distributes
sensitive
information.[9]
Security Service
A
system or method of providing a security
relevant feature in the system.
Sensitivity Label
A
piece of information that represents the
security level of an object. Sensitivity labels are used by the TCB as the
basis for mandatory access control decisions.[9]
Subject
An
active entity, generally in the form of a
person, process, or device that causes information to
flow among objects or
changes the system state.
Technically, a process/domain pair.[9]
Trusted Computing Base (TCB)
The
totality of protection mechanisms within a
computer system -- including hardware, firmware, and
software -- the
combination of which is responsible for enforcing a
security policy. It
creates a basic protection environment and provides
additional user services
required for a trusted computer system. The ability of a trusted computing
base to correctly enforce a security policy depends
solely on the mechanisms
within the Trusted Computing Base and on the correct
input by system
administrative personnel of parameters (e.g., a user's
clearance level)
related to the security policy.[9]
36
REFERENCES
1. Bell, D.E., and
L.J. La Padula, "Secure Computer
System: Unified
Exposition and Multics Interpretation," MTR-2997,
Mitre Corp., Bedford, MA,
July 1975.
2. Gabriele, Mark
D., Excerpts from the Criteria Discussions Forum on
the Dockmaster computer system at the National Computer
Security Center,
Forum entry #0680,
Hardware Design Documentation at B2 and Above, May 9,
1987.
3. National
Computer Security Center, Final Evaluation Report of
Honeywell Multics MR11.0, CSC-EPL-85/003, June 1, 1986.
4. Department of
Defense Computer Security Center, Final Evaluation of
SCOMP, Secure Communications Processor, STOP Release 2.1, CSC-EPL-85/001,
September 23, 1985.
5. Department of
Defense Standard, Department of Defense Trusted
Computer System Evaluation Criteria, DoD 5200.28- STD,
December 1985.
6. National
Computer Security Center, Final Evaluation Report of Gould, Inc.,
Computer Systems Division, UTX/32S, Release 1.0,
CSC-EPL-86/007, December 31,
1986.
7. National
Computer Security Center, A Guide to Understanding
Configuration Management in Trusted Systems, NCSC-TG-006,
March 28, 1988.
8. National
Computer Security Center, Criterion Interpretation, Report
No. C1-CI-01-87, 1987.
9. National
Computer Security Center, Glossary of Computer Security
Terms, NCSC-TG-004-88, October 1988.