<HEAD>
<META NAME="GENERATOR" CONTENT="Internet
Assistant for Word 1.0Z">
<META NAME="AUTHOR" CONTENT="Herb Lewis
LaFond">
<TITLE>A Guide to Understanding Design Documentation</TITLE>
<BODY>
<H1>A Guide to Understanding Design
Documentation</H1>
<H2>ACKNOWLEDGMENTS</H2>
<P>
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.
<P>
Special acknowledgment is given to Barbara Mayer, NCSC, for her
invaluable input and review of
this document, which has resulted
in its current form.
<P>
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.
<P>
A Guide to Understanding Design Documentation
<P>
NCSC-TG-07 Version 1
<H2>1. INTRODUCTION</H2>
<H3>1.1 Purpose</H3>
<P>
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.
<P>
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.
<P>
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.
<P>
This
guideline is part of the Technical Guidelines Program to
provide helpful guidance on TCSEC
issues and the features they
address.
<H3>1.2 Scope</H3>
<P>
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.
<P>
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.
<P>
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
to computer systems and
products that are being built with the
intention of meeting the requirements of the TCSEC.
<P>
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]
<MENU>
<LI>The TCSEC gives
the following as the Assurance Control Objective:
</MENU>
<P>
<MENU>
<LI>"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]
</MENU>
<P>
<P>
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
its life-cycle, without
compromising the trustworthiness of the
system.
<P>
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.
<H2>2. OVERVIEW OF DESIGN
DOCUMENTATION PRINCIPLES</H2>
<P>
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.
<P>
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.
<H3>2.1 Purpose of Design Documentation</H3>
<P>
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.
<P>
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.
<H3>2.2
Design Documentation Development for Evaluation</H3>
<P>
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.
<P>
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.
<H3>2.3 Level of Detail of Design
Documentation</H3>
<P>
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.
<P>
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.
<H3>2.4 Level of Effort for Meeting the
Requirements</H3>
<P>
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.
and developed will make it
easier to understand the design of
the system.
<P>
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.
<P>
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
during its life-cycle.
<P>
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
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
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.
<P>
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
Different design
documentation formats present different advantages
and challenges to evaluators and different
advantages and costs
to vendors that should be weighed.
<P>
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.
<H2>3. MEETING THE CRITERIA
REQUIREMENTS</H2>
<P>
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.
<P>
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.
<H3>3.1 The C1 Design Documentation Requirements</H3>
<P>
Requirement 1 - Describe the philosophy of protection.
<P>
Requirement 2 - Describe how the philosophy of protection is translated
into the TCB.
<P>
Requirement 3 - Describe how the TCB is modularized (if modular).
<P>
(if modular).
<P>
Requirement 5 - Describe how the TCB protects itself.
<P>
Requirement 6 - Provide a statement of the system security policy.
<H3>3.2 The C2 Design
Documentation Requirements</H3>
<P>
No new requirements have been
added at the C2 class.
<H3>3.3 The B1 Design Documentation Requirements</H3>
<P>
Requirement 7 - Provide an informal or a formal description of
the
security policy model enforced by the TCB.
<P>
Requirement 8 - Explain the
sufficiency of the security policy
model to enforce the security policy.
<P>
Requirement 9 - Identify and describe the TCB protection mechanisms.
<P>
Requirement 10 - Explain how the TCB mechanisms satisfy the security
policy model.
<H3>3.4 The B2 Design Documentation Requirements</H3>
<P>
Requirement 11 - Describe how the TCB is modularized.
<P>
Requirement 12 -
Describe all of the interfaces between the TCB
modules.
<P>
Requirement 13 -
Provide a formal description of the security
policy model.
<P>
Requirement
14 - Prove the sufficiency of the security policy
model to enforce the security policy.
<P>
Requirement 15 - Show that the Descriptive Top Level Specification
(DTLS) is
an accurate description of the TCB interface.
<P>
Requirement 16 - Describe how
the TCB implements the Reference
Monitor Concept.
<P>
Requirement 17 -
Describe why the reference monitor is tamper
resistant.
<P>
Requirement 18 -
Describe why the reference monitor cannot be
bypassed.
<P>
Requirement 19 -
Describe why the reference monitor is correctly
implemented.
<P>
Requirement
20 - Describe how the TCB is structured to facilitate
testing.
<P>
Requirement 21 - Describe how the TCB is structured to enforce
least privilege.
<P>
Requirement 22 - Present the results and methodology of the covert
channel
analysis.
<P>
Requirement 23 - Describe the tradeoffs involved in restricting
<P>
Requirement 24 - Identify all auditable events that may be
used
in exploitation of known covert storage channels.
<P>
Requirement 25 -
Provide the bandwidths of known covert storage
channels whose use is not detectable by
auditing mechanisms.
<H3>3.5 The B3 Design Documentation Requirements</H3>
<P>
Requirement 26 - Identify all auditable events that may be used
in
exploitation of known covert timing channels.
<P>
Requirement 27 - Provide the
bandwidths of known covert timing
channels whose use is not detectable by auditing
mechanisms.
<P>
Requirement 28 - Describe how the system complies with
additional
B3 system architecture requirements, for example, minimal TCB
and
layering.
<P>
Requirement 29 - Informally show consistency of the TCB
implementation
(in hardware, firmware, and software) with the DTLS.
<P>
Requirement 30 - Informally show correspondence between elements
of the DTLS and elements of
the TCB.
<P>
Requirement 31 - Informally show consistency of the DTLS with
the model.
<H3>3.6 The A1 Design Documentation Requirements</H3>
<P>
Requirement 32 - Informally show consistency of the TCB implementation
with
the Formal Top Level Specification (FTLS).
<P>
Requirement 33 - Informally show
correspondence between elements
of the FTLS and elements of the TCB.
<P>
Requirement 34 - Clearly describe hardware, software, and firmware
internal to the TCB that is
not dealt with in the FTLS.
<P>
Requirement 35 - Informally or formally show
consistency of the
FTLS with the model.
<P>
Requirement 36 - Informally show
correspondence between the FTLS
and the DTLS.
<H2>4. COMPONENTS OF DESIGN
DOCUMENTATION</H2>
<P>
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.
<H3>4.1 Documenting The Security Policy</H3>
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).
<P>
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
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.
<P>
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).
<P>
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
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.
<P>
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.
<P>
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.
<P>
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.
<P>
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).
<P>
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.
<P>
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 -
<P>
———————————–
<P>
1 UNIX is a trademark of AT&T Bell
Labs
<P>
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.
<P>
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.
<P>
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
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.
<P>
Although the TCSEC design documentation requirement changes at
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
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]
<P>
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).
<H3>4.2 Documenting TCB Protection
Mechanisms</H3>
<P>
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
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.
<P>
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
support the additional
system architecture requirement for process
isolation. Process isolation mechanisms that
prevent untrusted
subjects from directly accessing separate address spaces are introduced
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).
<P>
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]
documentation.
<P>
One position for how the reference monitor hardware should be
documented is
presented in the following paragraphs:
<P>
"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.
<P>
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.
<P>
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]
<P>
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.
<P>
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.
<P>
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.
<P>
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
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.
<P>
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.
<P>
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.
<P>
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 of the reference
monitor concept
becomes more defined, the amount of design documentation
shall also increase.
<H3>4.3 Documentation of Covert Channels</H3>
<P>
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
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).
<P>
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
exploitation is not
auditable (Requirement 25).
<P>
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.
<H2>5. OTHER TOPICS</H2>
<H3>5.1
Modularity</H3>
<P>
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
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.
<P>
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.
<P>
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.
<H3>5.2
Hardware Design Documentation</H3>
<P>
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]
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.
<P>
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.
<P>
The hardware design documentation defines the hardware portion
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.
<P>
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.
<P>
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 thereference 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]
<P>
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.
<P>
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.
<P>
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 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]
<P>
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
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.
<P>
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]
<P>
For further information about
the RAMP program and about the configuration
management requirements for RAMP, contact:
<P>
National Computer Security Center
<P>
9800 Savage Road
<P>
Fort George G. Meade, MD 20755 6000
<P>
Attention: C12
<H2>6. SUMMARY OF DESIGN DOCUMENTATION</H2>
<P>
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.
<P>
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
enable developers to analyze
changes to the system to ensure that
they do not adversely affect the trustworthiness of the
system.
<H2>APPENDIX B</H2>
<H3>EXCERPTS FROM FINAL EVALUATION
REPORTS</H3>
<P>
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.
<P>
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
<H4>B.1 CLASS
C2</H4>
<H5>B.1.1 UTX/32S[6]</H5>
<P>
The
following documents were provided to the evaluation team in
fulfillment of the Design
Documentation criterion:
<P>
"Security Policy Model"
<P>
"Program Maintenance Manual UTX/32S, Release 1.0 (DRAFT)".
<P>
"System Calls" and "Maintenance" in the
"System
Administrator’s Reference Manual".
<P>
"4.2BSD and UTX-32 Differences Study for Gould
<P>
UTX/32S"
"Memory Management for Gould UTX/32S"
<P>
"Object Reuse Study for Gould UTX/32S"
<P>
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,
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.
<P>
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
<H5>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.</H5>
<P>
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.
<P>
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
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".
<P>
"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.
<H4>B.2
CLASS B2</H4>
<H5>B.2.1 Multics3]</H5>
<P>
The following documents satisfy the Design Documentation requirement:
<P>
Applicable Features
<P>
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.
<P>
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.
<P>
The DTLS
is an accurate description of the TCB interface.
<P>
The "Covert Channel
Analysis" describes all identified
covert channels, how they can and cannot be
restricted, how they
are audited, and their bandwidths.
<H4>B.3 CLASS
A1</H4>
<H5>B.3.1 SCOMP [4]</H5>
<P>
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,
<P>
"Detail Specification for
SCOMP Kernel Part I,
<P>
Release 2.1"
<P>
"Detail Specification for SCOMP Kernel Part II,
<P>
Release
2.1"
<P>
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:
<P>
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."
<P>
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."
<P>
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.
<P>
The TCB implementation was shown to be
consistent with the FTLS
by specification to source code mappings
<P>
"FTLS to Code Mapping for the SCOMP Kernel Software"
<P>
"FTLS to Code Mapping for SCOMP Trusted Software"
<P>
"Justification for Unspecified Code for the SCOMP Kernel
Software, Release
2.1"
<P>
"Justification for Unspecified Code for SCOMP Trusted
Software"
<P>
TCB testing is documented in:
<P>
"SCOMP Kernel Test Procedures"
<P>
"SCOMP Kernel
Functional Test Summary"
<P>
"Kernel Software Test Report for
the SCOMP,
<H6>Release 2.1"</H6>
<P>
"Trusted Software Test Plan for the SCOMP"
<P>
"Trusted
Software Test Report for the SCOMP,
<H6>STOP Release 2.0"</H6>
"Trusted Software Test Report for the SCOMP,
<P>
Appendix A:Test Programs, Appendix B: Test Results"
<P>
"SCOMP
Test and Verification Software
<P>
Description, Rev. 3"
<P>
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.
<P>
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:
<P>
"Detail Specification for SCOMP Kernel Part I,Release 2.1"
<P>
"Detail Specification for SCOMP Kernel Part II, Release 2.1".
<H2>GLOSSARY</H2>
<H3>Access</H3>
<P>
A specific type of interaction between a subject and an object
that results in the flow of
information from one to the other.[9]
<H3>Access Attribute</H3>
<P>
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]
<H3>Audit Trail</H3>
<P>
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]
<H3>Covert Channel</H3>
<P>
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]
<H3>Covert Storage Channel</H3>
<P>
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]
<H3>Covert Timing Channel</H3>
<P>
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]
<H3>Descriptive Top Level Specification (DTLS)</H3>
<P>
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]
<H3>Formal Security Policy
Model</H3>
<P>
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]
<H3>Formal Top Level Specification (FTLS)</H3>
<P>
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]
<H3>Least
Privilege</H3>
<P>
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]
<H3>Object</H3>
<P>
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]
<H3>Reference Monitor Concept</H3>
<P>
An access control concept that refers to an abstract machine that
mediates all accesses to
objects by subjects.[9]
<H3>Security Kernel</H3>
<P>
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]
<H3>Security Level</H3>
<P>
The combination of hierarchical classification and a set of nonhierarchical
categories that represents the sensitivity of information.[9]
<H3>Security
Mechanism</H3>
<P>
A system or means of implementing a security
service within a
system.
<H3>Security Policy</H3>
<P>
manages, protects,
and distributes sensitive information.[9]
<H3>Security Policy Model</H3>
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]
<H3>Security Service</H3>
<P>
A system or method of providing a security relevant feature in
the system.
<P>
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]
<H3>Subject</H3>
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]
<P>
Trusted Computing Base (TCB)
<P>
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]
<H2>REFERENCES</H2>
<MENU>
<LI>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.
<LI>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.
<LI>3. National Computer Security Center, Final Evaluation Report
of Honeywell Multics
MR11.0, CSC-EPL-85/003, June 1, 1986.
<LI>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.
<LI>5. Department of Defense Standard, Department of
Defense Trusted
Computer System Evaluation Criteria, DoD 5200.28- STD, December
1985.
of Gould, Inc.,
Computer Systems Division, UTX/32S, Release 1.0,
CSC-EPL-86/007, December 31, 1986.
<LI>7. National Computer Security Center, A Guide to Understanding
Configuration
Management in Trusted Systems, NCSC-TG-006, March
28, 1988.
<LI>8. National
Computer Security Center, Criterion Interpretation,
Report No. C1-CI-01-87, 1987.
<LI>9. National Computer Security Center, Glossary of Computer
Security Terms,
NCSC-TG-004-88, October 1988.
</MENU>
</BODY>
</HTML>
Add A Comment