Rainbow NCSC-TG-006
Rainbow NCSC-TG-006
Rainbow NCSC-TG-006
REFERENCES
Page 36
manner that they cannot be electrically altered during normal
device operations.[3]
Page 35
GLOSSARY
Page 34
generation of an element, but will not allow an edited copy to be
reinserted into the library. The SHOW function can be used to
audit the information about each element in the library.
The CMS CREATE CLASS function, together with the CMS INSERT
GENERATION function, can be used to specify the exact elements of
a software build, and the DESCRIPTION file can then refer to the
entire class by using the /GENERATION=classname qualifier on
either the source or action line of a dependency rule. The
makefile required by Unix (1) SCCS can be much more complex when
it is required to describe a software build for intermediate
testing."[2]
Page 33
The initial release, or initial delta, of each code module is
entered into the SCCS directory through the admin -n function,
thus creating the Master Library. The programmer may update each
module in the Master Library by using the get -e function "which
indicates that the module will be edited and then the completed
document will be reentered into the directory using the delta
function. As long as the module being edited was extracted from
the SCCS directory using get -e, it can be returned to the
library using delta, and all necessary update information will be
entered with it. The get function can be used to extract a copy
of any document, but after it is edited it cannot be reentered
into the library."[2]
Page 32
APPENDIX A: AUTOMATED TOOLS
"Under the Unix (1) system, the make utility, and the elements
admin, get, prs, and delta, which comprise the Source Code
Control System, provide a basic configuration accounting system.
Initially a directory is created using the mkdir function. At
this point, it is possible to use the owner, group, world
protection scheme provided by Unix (1) to protect the directory.
In addition a list of login identifiers is created which
specifies who may update each element to be processed by SCCS."
[2]
Page 31
will be reduced greatly and any necessary changes that are
required should be able to be identified with great ease. An
effective configuration management system should be able to show
what was supposed to have been built, what was built, and what is
presently being built.
Page 30
Fort George G. Meade, MD 20755©6000
Page 29
the system staff, errors may occur and shortcuts may be sought
which will jeopardize the entire configuration management plan.
A review process should be present to ensure that no single
person can create a change to the system and implement it without
being subject to some type of approval process. Supervisors, who
are responsible for the personnel performing the change should be
required to sign an official record that the change is the
correct change.[2]
Page 28
accountability for the TCB versions distributed to the customer.
Page 27
but not every vendor may have the desire or resources to
establish one. Whatever the preference, there should still be
some way of performing the control processes described
previously.
Page 26
various groups involved in the system development is to prevent
"unnecessary and contradictory changes to the system while
allowing changes that are responsive to new requirements, changed
functional allocations, and failed tests."[2] All of the members
of the Board should have a chance to voice their opinions on
proposed changes. For example, if system engineering proposes a
change that will affect security, both sides should be able to
present their case at a CCB meeting. If diversity did not exist
in the CCB, changes may be performed, and upon implementation may
be found to be incompatible with the rest of the system.
Page 25
and has been found to satisfy the TCSEC requirements for
configuration management at class B2.
* Program Management
* System Engineering
* Quality Assurance
* Technical Support
* System Installation
* Technical Documentation
* Program Development
* Security Engineering
* User Groups
Page 24
feasible and necessary. MER, Inc. has an online forum for
reviewing suggested changes. This forum makes it possible for
all of the members of the development team to comment on how the
proposed change may affect their work. Management would often
consult this forum to help arrive at their final decision.
Page 23
9.2 Configuration Management at MER, Inc.
Page 22
promote greater design flexibility or efficiency. The number of
baselines that may be established for a system will vary
depending upon the size and complexity of the system and the
methods supported by the designers and developers. It is
possible to establish multiple baselines existing at the same
time so long as configuration management practices are applied
properly to each baseline. The following example will discuss
the baseline concept using three common baseline categories:
functional, allocated, and product. It should be emphasized that
these are simply basic milestones and baselines should be
established depending upon the decisions of the designers and
developers.
Page 21
management that may be used to meet some of the requirements of
the TCSEC. Section 9.1 discusses the baseline concept as a
method of configuration identification. The baseline concept
utilizes the features of configuration management spoken of
previously, but divides the life-cycle of the system into
different baselines.
Page 20
be "maintained under strict configuration control"[1]
(Requirement 18). These tools may include forms used for change
control, conventions for labeling configuration items, software
libraries, as well as any automated tools that may be available
to support the configuration management process. Samples of any
documents to be used for reporting should also be contained in
the configuration management plan with a description of each.
9. IMPLEMENTATION METHODS
Page 19
* the item/product performs per the requirements
Page 18
status of all authorized changes being performed should be
formulated into a System Status Report that will be presented at
a Configuration Control Board meeting (see Section 9.3 THE
CONFIGURATION CONTROL BOARD).
Page 17
a change from its inception, through implementation and testing,
to release. The level of control exercised over the TCB may
exceed that of the rest of the system, but it is recommended that
all parts of the system be under configuration control.
Page 16
control of the system configuration as defined primarily in
design documents. For these, the Configuration Management plan
shall specify procedures to ensure that all documentation is
updated properly and presents an accurate description of the
system and TCB configuration. 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 non-existent.
Page 15
the item belongs to, the version of software that it is, or its
interface with other configuration items. When using a
numbering scheme like this, a change to a configuration item
should result in the production of a new configuration
identifier. This new identifier should be produced by an
alteration or addition to the existing configuration identifier.
A new version of a software program should not be identified by
the same configuration item number as the original program. By
treating the two versions as distinct configuration items, line-
by-line comparisons are possible to perform.
Page 14
(Requirements 10, 11). These tools are responsible for providing
assurance that no additional changes have been inserted into the
TCB that were not intended by the system designer. Automated
tools are available that make it possible to identify changes to
a system online (see APPENDIX A: AUTOMATED TOOLS). Any changes,
or suggested changes to a system should be entered into an online
library. This data can later be used to compare any two versions
of a system. Such online configuration libraries may even
provide the capability for line-by-line comparison of software
modules and documentation. At Class A1, the tools used to
perform this function shall be "maintained under strict
configuration control"[1] (Requirement 18). These tools shall
not be changed without having to undergo a strict review process
by an authorized authority.
Page 13
configuration and maintaining the integrity and traceability
of this configuration throughout the system life cycle."[4] The
basic function of configuration identification is to identify the
components of the design and implementation of a system. When it
concerns trusted systems, this specifically means the design and
implementation of the TCB. This task may be accomplished through
the use of identifiers and baselines (see Section 9.1 The
Baseline Concept). By establishing configuration items and
baselines, the configuration of the system and its TCB can be
accurately identified throughout the system life-cycle.
The TCSEC also requires at class B2 and above, that tools shall
be provided "for generation of a new version of the TCB from the
source code" and that there "shall be tools for comparing a newly
generated version with the previous TCB version in order to
ascertain that only the intended changes have been made in the
code that will actually be used as the new version of the TCB"[1]
Page 12
6.2 The B3 Configuration Management Requirements
Page 11
6. MEETING THE CRITERIA REQUIREMENTS
Page 10
configuration management requirements have been broken down into
19 separate requirements in Section 6 of this document. The
requirement number(s) will be located in parenthesis following
its appropriate discussion, e.g., (Requirements 2, 15), signifies
that the previous discussion dealt with TCSEC requirements 2 and
15 as stated in Section 6.
Page 9
configuration management of a trusted system and an untrusted
system, the word "system" shall be used as the object of
configuration management, encompassing both the system and the
TCB. It should be noted that the TCSEC only requires the TCB to
be controlled by configuration management, although it is
recommended that the entire system be maintained under
configuration management.
3. CONTROL OBJECTIVES
4. ORGANIZATION
Page 8
1. PURPOSE
For TCSEC classes B2 through A1, the TCSEC requires that all
changes to the Trusted Computing Base (TCB) be controlled by
configuration management. Configuration management of a trusted
system consists of identifying, controlling, accounting for, and
auditing all changes made to the TCB during its development,
maintenance, and design. The primary purpose of this guideline
is to provide guidance to developers of trusted systems on what
configuration management is and how it may be implemented in the
development and life-cycle of a trusted system. This guideline
has also been designed to provide guidance to developers of all
systems on the importance of configuration management and how it
may be implemented.
2. SCOPE
Page 7
PREFACE
Page 6
12. CONFIGURATION MANAGEMENT SUMMARY ....................... 27
GLOSSARY .................................................... 32
REFERENCES .................................................. 34
Page 5
CONTENTS
FOREWORD .................................................... i
ACKNOWLEDGEMENTS ............................................ ii
PREFACE ..................................................... v
1. PURPOSE ................................................. 1
2. SCOPE ................................................... 1
4. ORGANIZATION ............................................ 3
Page 4
ACKNOWLEDGEMENTS
Page 3
FOREWORD
____________________________
Patrick R. Gallagher, Jr. 28 March 1988
Director
National Computer Security Center
Page 2
NATIONAL COMPUTER
SECURITY CENTER
A GUIDE TO
UNDERSTANDING
CONFIGURATION MANAGEMENT
IN TRUSTED SYSTEMS
NCSC-TG-006-88
Library No. S-228,590
Page 1