Hackers Toolkit v2.0/Hackers_Toolkit_v2.0.iso/HTML/archive/Rainbow/ncsc/ygreenncsc.txt

Text File | 1999-11-04 | 84KB | 1,750 lines

Writing Trusted Facility Manuals

NATIONAL COMPUTER SECURITY CENTER

FORT GEORGE G. MEADE, MARYLAND 20755-6000

NCSC TG 016

Library No. S239,639

Version 1

FOREWORD

Guidelines for Writing Trusted Facility Manuals provides a set of good
practices related to the documentation of trusted facility management
functions of systems employed for processing classified and other
sensitive information. A Trusted Facility Manual (TFM) is a document
written by a system vendor that describes how to configure and install a
specific secure system, operate the system in a secure manner, and make
effective use of the system privileges and protection mechanisms to
control access to administrative functions and databases.

Guidelines for Writing Trusted Facility Manuals is the latest addition to
the "Rainbow Series" of documents. These publications are the product of
the Technical Guidelines Program. The National Computer Security Center
designed these technical guidelines to provide insight to the Trusted
Computer System Evaluation Criteria requirements and guidance for meeting
each requirement.

Recommendations for revision to this guideline are encouraged and will be
reviewed by the National Computer Security Center through a formal review
process.

_________________

Patrick R. Gallagher, Jr. October 1992

     Director
     National Computer Security Center

ACKNOWLEDGMENTS

The National Computer Security Center wishes to extend special recognition
and acknowledgement for their contributions to this document to
Infosystems Technology, Inc., and to Dr. Virgil D. Gligor of the
University of Maryland as primary author and preparer of this document.
Special thanks also go to the many computer vendor representatives, and
members of the National Computer Security Center (NCSC) community who
enthusiastically gave of their time and technical expertise in reviewing
the material and providing valuable comments and suggestions.

Special recognition goes to Leon Neufeld, NCSC, who served as project
manager for the preparation and production of this document.

PREFACE

Throughout this guideline there will be recommendations made that are not
included in the Trusted Computer System Evaluation Criteria (TCSEC) as
requirements. Any recommendations that are not in the TCSEC are prefaced
by the word "should," whereas all requirements are prefaced by the word
"shall." It is hoped that this will help to avoid any confusion.

Examples in this document are not to be construed as the only
implementation that will satisfy the TCSEC requirement. The examples and
literature citations provided herein are merely suggestions of appropriate
designs and, possibly, 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 are to be
evaluated.

INTRODUCTION

The Department of Defense Computer Security Center (DoDCSC), established
in January 1981, expands on the work started by the DoD Security
Initiative. In 1985, the DoDCSC became the National Computer Security
Center (NCSC) to reflect its responsibility for computer security
throughout the Federal Government. The Director, NCSC, has the
responsibility for establishing and publishing criteria and guidelines for
all areas of computer security.

The principal goal of the NCSC is to encourage the widespread availability
of trusted computer systems. In support of that goal, the NCSC created a
metric, known as the DoD Trusted Computer System Evaluation Criteria
(TCSEC), against which computer systems could be evaluated for security.
The DoDCSC originally published the TCSEC on 15 August 1983 as
CSC-STD-001-83. In December 1985, the DoD adopted it, with a few changes,
as a DoD Standard, DoD 5200.28-STD. DoD Directive 5200.28, Security
Requirements for Automated Information Systems (AIS) requires the TCSEC to
be used throughout the DoD. The TCSEC is the standard used for evaluating
the effectiveness of security controls built into Automated Data
Processing (ADP) systems. The TCSEC has four divisions: D, C, B, and A,
ordered in a hierarchical manner with the highest division (A) being
reserved for systems providing the best available level of assurance.
Within divisions C, B, and A, a number of subdivisions, known as classes,
are also ordered in a hierarchical manner to represent different levels of
assurance in these classes.

Purpose

A Trusted Facility Manual (TFM) is one of the documents necessary to
satisfy the requirements of any class in the TCSEC. The TFM is directed
towards the administrators of an installation, and its goal is to provide
detailed, accurate information on how to (1) configure and install a
specific secure system, (2) operate the system in a secure manner, (3)
make effective use of the system privileges and protection mechanisms to
control access to administrative functions and databases, and (4) avoid
pitfalls and improper use of the administrative functions that would
compromise the Trusted Computing Base (TCB) and user security.

The importance of the TFM in supporting the operation of a secure computer
system cannot be over estimated. Even if one assumes, hypothetically, that
all users of a system and their applications are trusted, and that they
will use all of the available protection mechanisms correctly, the system
may still be administered and operated in an insecure manner. This may be
especially true when administrative users lack the skill, the care, or the
interest to use the system properly. Furthermore, the security damage that
administrative users can cause by careless use, or deliberate misuse, of
administrative authority is significantly larger than that caused by
ordinary users. Although use of a detailed, accurate TFM cannot address or
counter deliberate misuse of administrative authority, it can help
minimize chances of misuse due to lack of awareness of proper system use.
To help minimize these instances of system misuse, the TFM should include
examples of both proper use and warnings about consequences of misuse of
administrative functions, procedures, privileges, and databases.

This guideline presents the issues involved in writing TFMs. Its
objectives are (1) to provide guidance to manufacturers on how to document
functions of trusted facility management implemented by their systems and
(2) recommend a TFM structure, format, and content that would satisfy the
TCSEC requirements. The recommendations made herein should not be
considered as the only means to satisfy the TCSEC requirements.
Additionally, this document contains suggestions and recommendations
derived from the TCSEC objectives but which are not required by TCSEC in
the TFM area. For example, the TFM may include documentation required by
the TCSEC in the areas of System Architecture, Design Documentation, and
Trusted Distribution. The inclusion of this documentation in a TFM instead
of other separate documents is optional.

Scope and Contents

The TFM should give specific guidance to administrative users on how to
configure, install, and operate a secure computer system, and should
clearly illustrate the intended use of all security features, citing
actual system commands and procedures. Although a high level of detail in
illustrating key security concepts would benefit administrative users, the
TFM cannot be considered to be, nor can it be, a training manual in the
area of computer security in general, nor in the area of system
administration in particular. Instead, the TFM user is assume to have some
familiarity with the notion of trusted systems within the realm of
computer security. The TFM will provide the user with detailed information
on how to administer and operate a specific trusted system in a secure
manner.

Many different organizations of the TFM are possible. For example, an
acceptable TFM format would provide a separate section describing specific
security responsibilities of any separate administrative roles, such as
those of the security administrator, auditor, system programmer, operator,
that are supported in the system; available commands for each role; use of
each command; parameter and default settings; specific warnings and advice
regarding the use of functions, privileges and databases of that role; and
the specific responsibilities of that role for TCB security. Use of this
format is advisable for manuals of systems in higher security classes,
namely B2, B3, and A1, where separation of administrative roles is
required.

An equally acceptable TFM organization and section format would provide a
separate section for each functional requirement area of the TCSEC,
namely, for security policy (e.g., Discretionary Access Control (DAC),
Mandatory Access Control, (MAC) ), accountability, and TCB protection.
Each section would include available commands, system calls, and
procedures relevant to that area; use of each command (including the
effects of each command when used by different administrative roles);
parameter and default settings; and specific warnings and advice regarding
the use of functions, privileges, and databases available to commands of
that area. Use of this alternate format is advisable for lower security
classes, namely C1-B1, where the TCSEC does not mandate any separation of
administrative roles. Either of the two alternate TFM formats mentioned
above is equally acceptable for all TCSEC security classes as long as the
TFM satisfies the TCSEC requirements Furthermore, other TFM formats would
also be acceptable as long as they satisfy the stated TCSEC requirements.
The TCSEC neither requires nor suggests a specific TFM format.

This guideline contains eight additional sections. Section 2 defines the
security and accountability policies and mechanisms of systems. Section 3
identifies and explains the security-relevant and security-irrelevant
functions of an administrator. Section 4 identifies and explains the use
of TCB commands and interfaces used by administrative users. Section 5
defines day-to-day routine operations performed by administrative users
and the security vulnerabilities of these operations. Section 6 identifies
all TCB security and integrity responsibilities of administrative users.
Section 7 presents recommendations for writing the TFM that satisfy the
requirements of the TCSEC. Section 8 is a glossary. Section 9 lists the
references cited in the text. Each section consists of three parts: a
statement of purpose, an explanation of how that purpose can be achieved,
and an outline summarizing the recommendations made.

These guidelines apply to computer systems and products built or modified
with the intention of satisfying the TCSEC requirements.

Control Objectives

The control objectives for the TFM are similar to those of other
documentation areas of the TCSEC. They refer to what should be documented
in a particular area, such as the trusted facility management, and how
this documentation should be structured. Thus, the control objectives for
writing the TFM are:

     (1) the TFM shall address all the requirements specified by the TCSEC
     that are relevant to it; and
     (2) the TFM shall provide detailed, accurate information on how to:
          ₧ configure and install a specific secure system;
          ₧ operate a system in a secure manner;
          ₧ avoid pitfalls and improper use of administrative functions
          that would compromise system and user security.

TFM Introduction

The purpose of this section in the TFM is to explain the scope, use, and
contents of the TFM of a particular system. In general, the scope of the
TFM should include explanations of how to configure and maintain secure
systems, administer and operate them in a secure manner, make effective
use of the system's privileges and protection mechanisms for
administrative use, and avoid pitfalls and misuse of administrative
authority. Depending on the particular computer system, the complexity of
trusted facility management may differ and thus the scope of the TFM may
differ accordingly. For example, in large systems, system configuration
and installation is a complex activity described in a separate system
administration manual that may, or may not, include the other important
areas of the TFM. In contrast, system configuration and installation is a
relatively simple activity defined in a single chapter of a TFM for a
small system, such as a multiuser workstation.

The introduction to the TFM should also discuss the recommended use of the
manual. In particular, this section should define the skills and general
computer systems and security background assumed for administrative
personnel. This is necessary because different administrative functions
require different levels of skill. For example, an individual in the
system programming staff that configures, installs, and maintains the TCB
code often needs considerably more technical skills than an individual in
the accounts management staff. Similarly, a security administrator needs
more detailed knowledge of the system security policy and accountability
than individuals assigned to operator's roles. The definition of required
skills and background is important in aiding the management of a
particular organization in assigning appropriately trained individuals to
various administrative tasks.

In defining the use of the TFM, the introductory section should also
include a list of other system manuals that may be consulted by the
administrative staff. For example, most administrators may benefit from an
understanding of the Security Features User's Guide (SFUG). Most system
designs use the DAC mechanisms described in the SFUG for protection of, at
least, some administrative files, and may use the trusted path mechanism
to prevent spoofing of administrative commands. Similarly, whenever manual
sections that logically belong in the TFM are in fact provided in other
manuals ? system configuration and installation manuals, and system
reference manuals containing descriptive top-level specifications (DTLSs)
of commands and interfaces used by administrative usersthe TFM
Introduction should include references to these additional manuals. The
TFM should place the references to these manuals in context and provide a
brief extract of the relevant information from the specific manual
citation. This citation would help narrow the reader's focus to a few
pages of the referenced manual. Furthermore, references to documents,
manuals, and standards that may be beneficial to some administrative
personnel, such as password management and use guidelines and standards,
should be made in this section. References to educational and training
documents that are helpful to administrative personnel may also be
included here.

The TFM writer may also want to define the limitations of the TFM in terms
of security scope. For example, some security issues such as personnel
background verification, assignment and maintenance of users' trust
levels, physical system and environmental security, proper use of
cryptographic techniques and devices, and procedures that assign
individuals to administrative roles, generally fall outside the scope of
TFM definition. Explicit recognition of such limitations enables the
management of a secure facility to plan countermeasures for areas of
vulnerability not countered by the trusted systems.

Finally, the introductory section of the TFM should include a "road map"
defining the contents of each TFM section and possibly the relationships
between various manual sections. This road map may also identify the
self-contained sections of the manual that can be read independently of
other sections.

In summary, the introductory section of the TFM should include:

Scope of the manual

     ₧ guide the configuration and installation of secure systems;
     ₧ guide the operation of a system in a secure manner;
     ₧ enable administrative personnel to make effective use of the
     system's privileges and protection mechanisms;
     ₧ issue warnings about possible misuse of administrative authority.

Recommended use of the manual

     ₧ review skills and systems background necessary for administrative
     personnel;
     ₧ suggest additional manuals, reference material, and standard,
     needed by administrative personnel;
     ₧ specify the limitations of security scope;

TFM contents

     ₧ contents of each section;
     ₧ section relationships.

SYSTEM SECURITY OVERVIEW

The purpose of this section of the TFM is to define the security and
accountability policies and mechanisms of the system that are designed to
counter a set of perceived threats. The focus of this section should be on
the administrative-user functions available to counter threats, the
privileges and protection mechanisms available to administrative users,
and the general vulnerabilities associated with actions of administrative
users. This section should also include a list of dependencies on other
security measures, such as those for the maintenance of physical security,
which, although not required by the TCSEC, should be taken into account by
the management of the system installation and by system accreditors.

Threats

Examples of the general security threat handled by systems built to
satisfy a TCSEC class is that of unauthorized disclosure of information
through either unauthorized direct or indirect access to system and user
objects through system failures, subversion, and TCB tampering or through
use of covert channels. The manual should describe some of the common
attacks that cause unauthorized disclosure of information, in the context
of the specific system. These examples might include the use of Trojan
horses in untrusted shared programs, the use of covert channels by
untrusted users and applications, the use of known penetration methods
that cause unauthorized disclosure of sensitive or proprietary
information, and the misuse of access authorization to retrieve and
disclose sensitive information (e.g., insider attacks).

Countermeasures

Countermeasures Based on Security and Accountability Policies and
Procedures

This section of the TFM should include a brief discussion of the
protection mechanisms available in the system that help counter the
threats defined in the above section. This discussion should serve as a
summary of the protection philosophy used in the design and implementation
of the protection mechanisms and should include a presentation of the role
of security policy (both discretionary and mandatory policy, if any),
accountability, and assurance (both operational and life-cycle assurance).
The dependency of the system security mechanisms on administrative-user
actions should be emphasized here.

This section should point out clearly the types of threats that can, or
cannot, be countered by a specific policy or mechanism. For example, this
section should state that DAC mechanisms cannot, and are not meant to,
prevent or contain threats posed by Trojan horses implementing time bombs,
trap doors, or viruses placed in shared, untrusted applications [2]. DAC
mechanisms cannot, nor are they meant to, detect or prevent access
performed by an authorized subject on behalf of an unauthorized subject
(e.g., the surrogate access problem [3]). Furthermore, DAC mechanisms are
not, nor were they ever claimed to be, capable of controlling information
(as opposed to access privilege) flows. Only MAC can handle these
problems.

This section should discuss, in the context of the specific system, the
role of specific accountability mechanisms and policies in countering
security threats not handled by access control mechanisms. An example is
the use of audit mechanisms to complement access control mechanisms in the
sense that they can detect attacks initiated by authorized users (i.e., by
"insiders"), or that trusted-path mechanisms are required to prevent
spoofing, a threat not usually countered by access control mechanisms or
policies.

The emphasis in describing the above-mentioned threats and countermeasures
should be on the identification of the TCB mechanisms and policies that
counter a specific threat. For example, the summary of the countermeasures
supported by the system should include the basic assertion (and in other
design documents, the justification) that the TCB itself is
noncircumventable and tamperproof. Additional points of emphasis may be
that all countermeasures supported in the system require the interaction
of both access control and accountability mechanisms, and that these
mechanisms should be employed by both ordinary and administrative users.
This section should provide examples of interaction between ordinary and
administrative user decisions to illustrate both the positive and negative
consequences of such interaction.

Explicit Physical Security Assumptions

The TCSEC does not include requirements for physical security of the
system installation. However, the TFM should include a section or a
subsection that states the physical security assumptions made by the
system designers. These assumptions should be satisfied by the management
of the organization responsible for deploying the system, as the
evaluation of physical security is the responsibility of the system's
accreditors.

The explicit inclusion of the physical security assumptions made by
designers in the TFM will provide the accreditors with the necessary input
for the deployment of the system in different operational environments and
provide the administrative users an important input for the sound
definition of the system security profile. For example, systems that do
not provide trusted paths for administrative users usually assume that a
set of terminal ports is reserved for the connection of administrative
consoles that are physically separated from the rest of the user terminals
for the entire lifetime of the system. Also, a common assumption is that
the system definition of the security profile ensures that the level of
trust associated with the physical environment containing a system's
peripheral will always dominate the maximum sensitivity associated with
that peripheral. Similarly, this section should emphasize that systems
allowing legitimate users to access their components (e.g., removable
media) should be used only in environments where both administrative and
ordinary users are trusted to access all data in the system and are
trusted not to misuse their physical access permissions. (In such
environments, the use of untrusted applications may still require the use
of trusted systems even though all users are trusted to access all data.)
In systems that do not allow users to access the system components, or
when the above level of user trust cannot be guaranteed, the TFM should
suggest the physical controls necessary to counter, or deter, the
potential threat of physical access to system components. The presentation
of the physical security assumptions made by system designers should
enable accreditors to determine the security risks and exposures assumed
by system use as well as the required countermeasures.

Protection Mechanisms Available to Administrative Users

The security of any system depends directly on the security of the
administrative commands, interfaces, and databases. For this reason,
administrative commands, privileges, and databases shall be protected from
ordinary users, and in some TCSEC security classes, shall be separated on
a role basis. This section should identify the protection mechanisms
available to administrative users to ensure that these users are aware of
the means available to control access to their commands, privileges, and
databases.

All protection mechanisms that can be manipulated by ordinary users are
also usually available to administrative users. For example, all user
identification and authentication, and DAC mechanisms are available to
administrative users. In addition to mentioning these mechanisms, which
the SFUG already defines, this TFM section should include the description
of the mechanisms available only to the administrative users and the mode
of their safe use. For example, the use of special trusted-path mechanisms
based on physically protected, hard-wired consoles, which may allow the
invocation of command processors available only to administrative users,
and the use of audit mechanisms to detect potential intrusion by
authorized users, are only a few of the protection mechanisms specific to
administrative users [7].

Security Vulnerabilities and Warnings

This section should describe the security vulnerabilities of
administrative commands and procedures, and should suggest specific ways
to counter them. Reference [7] cites generic examples of common
vulnerabilities of administrative roles and role-specific vulnerabilities.
In addition to similar examples, this TFM section should include a
discussion of system-specific vulnerabilities and countermeasures required
in the assumed environments of system use.

In any system, design and implementation assumptions are made about
administrative actions and their sequence of use. For example, the loading
of a system during the installation phase, and the installation itself,
may require the use of special administrative commands in a specific
sequence. The definition of a user security profile may require that
administrators do not reuse user and group identifiers, and that the
definition of the system security profile prohibits the reuse of bit
encodings of sensitivity levels without careful analysis of consequences.
Other potential vulnerabilities, such as those resulting from
mismanagement of audit logs and postprocessing of files (in on-line,
off-line, and hard-copy form) should also be explained here. Design and
implementation assumptions should be stated explicitly in this section to
ensure that administrative users are aware of the negative consequences of
not satisfying these assumptions.

Separation of Administrative Roles

Security classes B2-A1 of the TCSEC require that the roles of the
administrative users be separated. This requirement means that the
commands, procedures, privileges, and databases of the various
administrative roles shall be separated by system design and shall be
documented as such. Role separation of classes B3 and A1 also requires the
separation of security-relevant functions from the security-irrelevant
ones. Reference [7] cites the rationale and the means of achieving role
separation in trusted systems.

The TFM shall define each separate role supported by the system. Each role
should be clearly defined in terms of the commands and TCB interfaces
available to the role, the use of each command, the command effects and
exceptions (whenever these are not defined in the DTLS of the TCB),
parameter and default settings, specific warnings for the command use, and
advice. The TFM should also define the specific security mechanisms used
to protect privileged commands and data used by administrators.

In summary, the TFM section presenting the system security overview for
administrative users should include the following subsections:

     2.1 Threats to System Security
     2.2 Countermeasures Based on Security Policy and Accountability
     2.3 Explicit Physical Security Assumptions
     2.4 Protection Mechanisms Available to Administrative Users
     2.5 Security Vulnerabilities of Administrative Users and Warnings
     2.6 Separation of Administrative Roles (for classes B2-A1)

SECURITY POLICY

The purpose of this section is to identify and explain the
security-relevant and security-irrelevant functions of the administrators.
In particular, this section should explain, in the area of
security-relevant functions, the use of the TCB commands and interfaces by
administrative users to initialize discretionary access privileges, to set
default user accesses to system objects after user registration, and to
distribute, review, and revoke access privileges on behalf of users in
systems that implement DAC in a centralized way [2]. In systems that
support MAC, this section also identifies and explains the use of TCB
commands and interfaces by administrators to define and change the system
security profile (e.g., the system-sensitivity map, sensitivity level
limits for system devices, and file systems), to define and change object
sensitivity levels (e.g., label imported, unlabeled data, and media), and
to change the trust level of active subjects, whenever such a function is
supported. This section also should define the administrator's interfaces
for other functions related to the support of DAC and MAC, such as
changing object ownership, restoring privileges deleted accidentally,
destroying errant processes, running consistency checks on system and user
security profiles, and managing user accounts.

Reference [7] outlines the role of the security administrators in support
of the security policy defined in a system. The TFM should specify the
commands, system calls, functions, their parameters and default settings
provided for each area of security policy and support, and should provide
examples of use, potential misuse, and security implications of command
misuse. For example, the TFM should explain how the administrator can
change the sensitivity label of an object or a subject, and cite the
expected security consequences of such action and also how the
administrator may determine the consequences of such a change in the given
system. Similarly, the administrator may decide to reuse a binary
representation of a sensitivity level to define a new sensitivity level.
For this process, the manual shall state the circumstances in which this
change is allowed, if ever, and should explain the conditions under which
this change is safe. All commands, system calls, and functions should be
defined in terms of their effects, exceptions, and parameters. The use of
commands should be illustrated by examples showing the correct settings of
various command options. This section should describe the recommended
reactions of the administrator to such exceptions (unless these reactions
are already described in the call/command DTLS).

The administrative functions and interfaces used in supporting the
security policy have potential vulnerabilities. Reference [7] outlines
some of these generic vulnerabilities. The TFM shall include warnings of
all known specific vulnerabilities in the given system and possibly
suggest means of reducing system risk associated with such
vulnerabilities. Minimally, the TFM should specify the dependencies of the
administrative roles on external policies and procedures that would help
reduce system risk associated with identified vulnerabilities.

In summary, the security policy section of the TFM should include the
following subsections (whose contents are discussed in more detail in
reference [7]):

Discretionary Access Control

     ₧ TCB commands and interfaces used to initialize DAC privileges and
     defaults;
     ₧ TCB command interfaces to distribute, review, and revoke user
     privileges in systems that support centralized DAC;
     ₧ group membership definition and impact on DAC.
     ₧ change of object ownership (if any), restoration of accidentally
     deleted privileges, destruction of errant processes;

Mandatory Access Control

     ₧ TCB commands and interfaces to define and change system security
     profile; classify, reclassify and import objects; and change trust
     level of active subjects;
     ₧ consistency checking of system security and user profiles.

Management of User Accounts

     ₧ definition and deletion of user and group accounts and identifiers.

Command System Call and Function Definitions

     ₧ effects and exceptions (if not defined in DTLSs);
     ₧ parameter and default settings;
     ₧ examples of command use and potential misuse.

Warnings of Specific Vulnerabilities of Administrative
Procedures and Activities Related to Security Policy.

ACCOUNTABILITY

Identification and Authentication Functions of
Administrative Users

The purpose of this section is to identify and explain the use of TCB
commands and interfaces that should be used by administrative users to set
up user security profiles, and to determine authentication and
authorization parameters associated with the user identification and
authentication mechanism. Reference [7] defines the role of the security
administrator in the identification and authentication area. The TFM shall
specify the commands, system calls and functions, and their parameters and
default settings that are provided by the specific system, and should
provide examples of the use,or potential misuse of these commands, and the
security implications of command misuse. For example, the TFM should
explain how the administrator can initialize user passwords, can
distribute special passwords to other administrative users, and set up
account restrictions (e.g., restricted time intervals for login, account
cutoff). The commands that allow the definition of user and group
identifiers shall include an explanation of how these identifiers should
be chosen, why they should not be reused, and what the consequences of
identifier reuse are.

In most systems, the setting of the user security profile also includes
the definition of some discretionary privileges associated with the user
account. For example, in systems that use groups to enforce DAC policies,
administrators define the group membership. The TFM shall explain the
consequences of adding or deleting a user identity to a group in terms of
the added or lost discretionary privileges, and provide appropriate
warnings. In systems where the user security profile also includes the
specification of the maximum level of trust for each user, the TFM shall
also discuss the security implications of incorrect definition or change
of these levels and the interactions between these levels and the
sensitivity levels of various system components (defined in the system
security profile). It should also include examples of and warnings about
such changes.

The commands available to system administrators also include those to
define and change the parameters of the login/logout mechanism used by a
system. Consequently, the TFM should explain how to define these
parameters, which include the time-out period, multiple login attributes,
maximum login time, and limits on unsuccessful logins from a terminal or
into an account [7] (e.g., specific commands, command options, formats,
parameter ranges, and default values). Whenever the trusted path
mechanisms available to administrative users require special procedures,
such as use of specific hard-wired consoles, the TFM shall specify how the
administrative users can use the trusted path mechanism in a secure
manner.

The TFM shall also explain the implications of the system security profile
definition in providing authorization data for user logins. For example, a
terminal's maximum and minimum sensitivity levels provide cutoff values
for whether a certain user login level can be used and whether a certain
user with a given user and group level clearance can log in at all from a
given terminal. The relationship between the terminal minimum's and
maximum's sensitivity levels and the user's clearance level shall be
explained so that consistent levels can be defined for both terminal
sensitivity and user level of trust.

Finally, administrator commands for temporarily terminating an user access
to the system and for permanently deleting the user account shall be
defined, and the implications of such actions defined. This section should
also include warnings about potential vulnerabilities, such as object
ownership set to the identity of an user or account that is no longer
valid, or the reuse of an old identifier, that persist when a user account
is not deleted correctly or completely, and examples of such
vulnerabilities [7].

For all administrative commands defined in this and other system security
areas, this TFM section should include an explanation of all exceptions
and, possibly, a administrator's recommended response to these exceptions.
(This reaction may already be described in the system call/command DTLS).
All administrative databases that are accessed by these commands should be
identified showing how they are, or can be, protected. All mechanisms
available for the protection of the identification and authentication data
shall be clearly explained. The use of these mechanisms should be
illustrated by examples.

Audit

The purpose of this section of the TFM is to familiarize administrative
users with the TCB commands and interfaces of the system's audit
mechanism. These commands include those that enable or disable the audit
selectivity mechanism (e.g., audit-event setup and change), those that
help manage the audit trails (logs), those that perform data compression
and post processing analysis, and in classes B2?A1, those that set correct
channel delays and randomize variables.

Some system includes a set of audit events that should always be selected
for audit to ensure the consistency of subsequent events selected by the
auditor and the proper functioning of the postprocessing tools. These
events should be explicitly highlighted for special discussion in the list
of auditable events supported by the system. The complete list of events
shall be defined in the TFM. The audit selection mechanism should also be
presented, and examples of use should be provided. Commands of the audit
selectivity mechanism include those that turn on and off events on a
per-user, per-process, per-terminal, per-sensitivity-level, or per-object
basis. In TCSEC classes B3 and A1, the commands that turn on and off
events representing accumulations of other auditable events and
audit-system alarms (if any) shall also be presented.

Systems that support audit mechanisms include commands that help manage
the audit files. These commands, which include those to create new and
destroy old audit logs, to change audit log size and warning points, to
display, format, and compress audit data, and to check the consistency of
the audit database after crashes, and when these changes take effect,
shall also be included in the TFM. The procedures that shall be used by
auditors to ensure that the audit files do not overflow shall also be
presented. The format in the audit log file of each record field and of
each type of auditable event shall be presented and explained. Commands
for postprocessing of audit logs (if any) shall also be included in the
TFM.

Systems designed to satisfy the B2 - A1 security requirements need to have
covert channels restricted to certain limits. One means of reducing covert
channel bandwidths is by placement of delays and by setting of
randomization variables in system kernels and trusted processes. Commands
that accomplish this task should be presented in the TFM of these systems
along with a description of the covert channel handling policy recommended
for enforcement. These recommendations should be derived from the
covert-channel analysis guideline of the TCSEC and are important because
they affect not only the security policy and the accountability areas of
the system, but also system performance. Reference [7] defines the
administrative functions necessary to support audit activities. As
suggested in the covert channel guidelines of the TCSEC, bandwidth
reduction policy should be coordinated with audit policy. For this reason,
the TFM should present the bandwidth reduction policy in the same section
with that presenting the audit policy.

Recommendations on audit procedures should also be included in the TFM.
These procedures would suggest auditing groups of specific events that may
reveal misuse of access privileges, potential system-penetration attacks,
and covert channel usage. They may also suggest the frequency of audit
review and provide advice on how to manage audit files on-line and
off-line.

For commands used by administrative users for audit, the TFM should
include a description of their effects and exceptions, and should provide
examples of use, potential misuse, and security implications of command
misuses. Recommendations for administrator's reactions to command
exceptions should also be made. Reference [7] provides examples of
vulnerabilities caused by misuse of audit command and authority. These
examples include loss of audit log consistency, loss of audit logs, loss
of user privacy, and various forms of denial of service. Specific
instances of vulnerability in a given system and possible suggestions for
reducing the system's exposure to such vulnerabilities should also be
included in the audit section of the TFM.

In summary, the accountability section of the TFM should include the
following subsections:

Identification and Authentication

     ₧ TCB commands and interfaces for setting up user security profiles
     and authentication and authorization parameters of the login
     mechanism;
     ₧ password distribution to ordinary and administrative users,
     management of password generation, and protection of passwords;
     ₧ account restrictions (e.g., restricted time intervals for login,
     and account cutoffs);
     ₧ choice of user and group identifiers;
     ₧ maximum levels of trust for users and groups;
     ₧ computation of the current level of trust for subjects (e.g.,
     subject's clearance).

Definition and Change of System Parameters of the Login
Mechanism and when they take effect

     ₧ timeout interval;
     ₧ multiple login attributes;
     ₧ maximum login time;
     ₧ limits on unsuccessful logins from a terminal or to an account;
     ₧ use of special trusted path mechanisms for administrative users.

Audit Mechanism

     ₧ audit-event selection mechanisms (e.g., audit-event setup and
     change);
     ₧ management of audit logs (e.g., protections of audit logs);
     ₧ functions for formatting, compressioning, and postprocessing of
     audit files;
     ₧ interfaces for setting of covert channel delays and randomization
     of variables;
     ₧ description of audit log and event formats.

Commands, System Calls and Function Definition

     ₧ effects and exceptions of each command of the accountability area
     (if not defined in DTLSs);
     ₧ parameter and default settings;
     ₧ examples of use and potential misuse.

Warnings of Specific Security Vulnerabilities of
Administrative Activities and Procedures Related to
Identification, Authentication, Trusted Path and Audit

5 ROUTINE OPERATIONS

The purpose of this section of the TFM is to define the routine operations
performed by administrative users, describe the operation's security,
describe the vulnerabilites associated with these operations, and provide
appropriate warnings. These operations are carried out, in most cases, by
execution of appropriate commands from a system console. However, in some
instances, these operations involve manipulation of physical devices, such
as printers, storage devices, removable media, communication switches, and
modems. For this reason, this TFM section may differ from the rest of the
TFM. It should contain not only definitions of specific commands and TCB
interfaces, but also procedures and policies for secure use and
manipulation of hardware devices.

Routine operations of administrative personnel include both
security-relevant and security-irrelevant operations. Security-relevant
functions include those that boot and shut down the system, set system
clocks, identify damaged user volumes and files, perform TCB backups and
on-line device tests, run system integrity tests, and respond to user
requests to mount/unmount volumes. Routine security-irrelevant operations
include those that perform system metering, and that require operator
response to various user requests [7]

This section the TFM should include a description of each command used for
routine operations, including its effects and exceptions, and should
provide examples of use, potential misuse, and security implications of
command misuse. Examples of vulnerabilities of security-relevant, routine
operations include the booting of an old version of the TCB, causing
inconsistency problems for users; system shutdown while still in normal
operation causing loss of files and file system inconsistencies; and
inadequate use of devices and device interfaces (e.g., printers).

This section the TFM should also include descriptions of administrative
commands that perform security-irrelevant routine operations. These
commands include those traditionally performed by account administrators,
such as commands used for maintenance of accounting files, for turning on
and off accounting, for running accounting tools, for collecting
statistics of system and resource usage, and billing information.

Administrative policies and procedures that define security-relevant
handling of devices shall also be included in the TFM. For example,
procedures to install, activate, and set the current sensitivity level of
a printer within the predefined range should be defined, and examples of
the installation procedure should be given.

In summary, the TFM section defining the routine administrative operations
and procedures should include the following subsections:

Security-Relevant Procedures and Operations

     ₧ running of system diagnostics;
     ₧ system boot and shutdown;
     ₧ setting of system clocks;
     ₧ identification of damaged user files and volumes;
     ₧ routine backup of TCB files;
     ₧ on-line device testing;
     ₧ response to user requests to mount/unmount volumes;
     ₧ handling of peripheral devices, removable storage, and output
     (e.g., printers, printer output, diskpacks, tape reels).

Security-Irrelevant Procedures and Operations

     ₧ back-up of user volumes;
     ₧ system metering;
     ₧ response to various user requests;
     ₧ user account administration.

Commands, System Calls and Function Definitions

     ₧ effects and exceptions of each command of the routine operations
     area (unless defined in the DTLSs);
     ₧ parameter and default settings;
     ₧ examples of use and potential misuse.

Warnings of Specific Security Vulnerabilities

Routine Operations

SECURITY OF THE TCB

The two purposes of this TFM section are to identify and explain all
aspects of TCB security and integrity that become the responsibility of
administrative users. Because the security of all user programs, data, and
application subsystems is provided by the TCB, the maintenance of TCB
security and integrity is one of the most sensitive administrative
functions.

Maintenance of TCB security spans the entire system life cycle. It
includes procedures for strict configuration management during system
development and use,and for secure system distribution, installation, and
local maintenance. In some cases, administrative users are allowed and
required to generate another evaluated version of the TCB from source code
(e.g., make changes to the TCB source code and regenerate the TCB on
site). In such cases, the TFM shall include detailed descriptions of
procedures that generate a new TCB version from source code, the necessary
system commands, the list of approved tools (e.g., compilers, linkers,
loaders) for TCB generation, examples of command use, warnings of possible
problems in generating a new TCB, vulnerabilities that may affect TCB
security, and configuration management.

The TFM shall also provide, or reference a separate document that
provides, a description of command exceptions, appropriate warnings, and
possible exception handling advice. The TFM should also provide, or
reference a separate document that describes, the configuration management
tools. The TFM shall include descriptions of the procedures that must be
followed by site administrators to install new releases of the TCB.

TCB security may be violated during installation and maintenance (see
[7]). For this reason, the TFM shall provide a description of the TCB
installation procedures, including the required commands, exceptions,
parameter settings, required system configuration, warnings, and advice.
The installation procedures should contain descriptions of the TCB data
structures that must be initialized by the user, and of the TCB loading.
Also, the installation procedures should include a list of tools (e.g.,
editors, loaders) approved for TCB installation and an appropriate
description of secure installation assumptions (e.g., administrative
procedures, such as those that require physical audit of the installation
procedure by independent personnel).

All TCB maintenance procedures shall be defined in the TFM. These
procedures should include analyzing system "dumps" after crashes,
conducting crash-recovery and restart actions, performing consistency
checking of TCB files and directories, changing system configuration
parameters (e.g., table sizes, devices, and device drivers), running
periodic system integrity checks, and repairing damaged labels. A list of
the approved tools for TCB maintenance, relevant commands, exceptions,
warnings, and advice should also be included in this section.

The ability to install and maintain a system's TCB in a secure manner
requires that administrative users be cognizant of all TCB modules.
Administrators should especially be cognizant of those hardware modules
containing the reference monitor mechanism, and of all the of default file
protections for TCB files or objects. If available, the command needed to
run a tool that checks the correct privilege and sensitivity-level
initialization for TCB files or objects shall be identified and its use
illustrated. Thus, either the TFM itself shall provide a list of all TCB
modules, including their interfaces, and shall specify the TCB file or
object privileges necessary to protect the TCB or the TFM shall list a
separate document that does.

The TFM shall include warnings and advice on how to handle both generic
and system-specific vulnerabilities (if any) of TCB installation and
maintenance. For example, administrative users should be warned that
interchanges of dedicated-console and user-terminal communication lines
can cause potential loss of trusted path for administrative users, that
placement of extraneous code in the TCB configuration may result from
using an unapproved tool, and that running a borrowed untrusted program
under administrative identity may cause an untold number of TCB security
problems [7].

Finally, the TFM shall include a description of policies and procedures
that define the distribution procedures for a trusted system (i.e., a
class A1 requirement). These policies and procedures shall be used to
maintain the integrity of the mapping between the master copy defining the
current version of the TCB and the on-site installed copy.

In summary, the TFM section that defines the security measures necessary
for protection of the TCB should include the following subsections:

Generation of the TCB Source Code

     ₧ list of TCB code modules, module interface and data (including
     modules of the reference monitor);
     ₧ list of approved tools for TCB generation;
     ₧ procedures for TCB generation;
     ₧ vulnerabilities.

Configuration Management Policy

(if required, reference to a separate configuration management document)

Ratings-maintenance Plan

(if applicable, reference to a separate rating mainenance document)

TCB Installation Procedure

     ₧ TCB generation from source code (whenever allowed by the system
     manufacturer);
     ₧ TCB hardware installation;
     ₧ TCB data structure initialization;
     ₧ TCB loading;
     ₧ setting of TCB file protection;
     ₧ list of approved tools.

TCB Maintenance Procedures

     ₧ analysis of system dumps;
     ₧ crash recovery and restart;
     ₧ changes of configuration parameters;
     ₧ repair of damaged TCB data structures;
     ₧ consistency-checking procedures;
     ₧ running of periodic system-integrity checks

Trusted Distribution of the TCB

     ₧ policies and procedures;
     ₧ correspondence between master copy and installed copy

Commands, System Calls, and Function
Definitions for TCB Generation from Source
Code, Installation, Maintenance, and Trusted
Distribution

     ₧ effects and exceptions (unless defined in DTLSs);
     ₧ parameter and default settings;
     ₧ examples of use and potential misuse.

Warnings of Specific Security Vulnerabilities
of TCB Generation, Installation, Maintenance,
and Distribution

SATISFYING THE TCSEC REQUIREMENTS

This section of the TFM should contain the definition of the TFM
requirements on a TCSEC class basis. All of the requirements listed below
derive from corresponding documentation requirements and objectives of the
TCSEC. Although similar TFM requirements appear in multiple classes, the
contents of TFM sections shall reflect the complexity of policy,
accountability, assurance, and documentation of the evaluation class.
Consequently, this section should contain suggestions and recommendations
that may not be found in the TFM requirements area but that derive from
other TCSEC areas. These suggestions and recommendations illustrate the
added complexity of various TCSEC classes.

Requirements and Recommendations for Security

Class C1

The TFM of a C1 class system may have the following structure:

TFM Introduction

The TFM introduction may include the following topics:

Scope of the TFM

     ₧ guide to configure and install secure systems;
     ₧ guide to operate a system in a secure manner;
     ₧ enable administrative personnel to make effective use of the
     system's privileges and protection mechanisms;
     ₧ issue warnings about possible misuse of administrative authority.

Recommended use of the TFM

     ₧ review skills and systems background necessary for administrative
     personnel, suggest additional manuals, reference material, and
     standards needed by administrative personnel;
     ₧ specify the limitations of security scope;

Contents of the TFM

     ₧ contents of each section;
     ₧ section relationships.

System Security Overview

This section of the TFM shall include a brief description of the system
administration vulnerabilities specific to the given system, warnings, and
advice on how to counter these vulnerabilities.

"A manual addressed to the ADP administration shall present cautions about
the function and privileges that should be controlled when running a
secure facility [6]."

The above TCSEC requirement suggests that the administrative functions and
privileges that need to be controlled when running a secure facility shall
be identified, and the vulnerabilities associated with those functions and
privileges shall be determined. Warnings relating to these vulnerabilities
shall be presented.

The administrative functions and privileges that need to be controlled
when running a class C1 secure facility include those supporting security
policy (i.e., DAC), accountability (i.e., identification and
authentication), and operational assurance (i.e., system integrity).

Security Policy

This section of the TFM shall include descriptions of the TCB commands,
interfaces, and procedures to:

     ₧ initialize discretionary access privileges and defaults for
     individual users and groups;
     ₧ distribute, review, and revoke privileges on an individual user or
     group basis;
     ₧ change object ownership (if any), restore accidentally deleted
     privileges, and kill errant processes;
     ₧ define and change group membership (whenever groups are supported),
     and explain the effect of such action on DAC;
     ₧ explain the implications of creating and deleting user and group
     accounts on DAC.

     (For specific DAC requirements, the reader should refer to [2].)

Accountability

Identification and Authentication

This section of the TFM shall include descriptions of the TCB commands,
interfaces and procedures to perform the following functions:

     ₧ conduct setup of user/group security profiles,and authentication
     and authorization parameters of the login mechanism;
     ₧ conduct password management distribution to ordinary and
     administrative users or groups (see [4]);
     ₧ define account restrictions (e.g., time intervals for login,
     account cutoff time).

This section shall also include descriptions of the definition and change
of login mechanism parameters. These parameters include:

     ₧ types of terminals supported and terminal; interface
     initialization;
     ₧ time?out interval;
     ₧ multiple login attributes (if supported);
     ₧ maximum login time;
     ₧ limits on unsuccessful logins from a terminal or to an account.

Routine Operations

Although the TCSEC does not cite specific requirements in this area, the
TFM should include commands and procedures for the following activities:

     ₧ perform ystem boot and shut down;
     ₧ set system clocks;
     ₧ conduct on-line device testing;
     ₧ perform backup of user volumes;
     ₧ perform system metering;
     ₧ response to various user requests.

Security of the TCB

This section of the TFM shall include descriptions of the TCB command
procedures that are provided "to validate periodically the correct
operation of the on-site hardware and firmware elements of the TCB."[6]

In all areas of the TFM, and for all security classes where TCB commands
and interface descriptions are required, the TFM shall include:

     ₧ effects and exceptions of each command (if not already defined in
     the DTLS);
     ₧ parameter and default setting;
     ₧ examples of potential use and misuse.

In all areas of the TFM, and for all security classes, warnings (i.e.,
cautions) shall be provided for specific security vulnerabilities of the
relevant administrative commands, interfaces, and procedures. Any
modification to the TCB, for all security classes, may invalidate the
systems rating [5].

Requirements and Recommendations for Security

Class C2

Security class C2 includes all the TFM requirements of security class C1.
In addition, the following documentation requirements are added.

TFM Introduction

No Additional Requirements/Recommendations (NAR)

System Security Overview

The first design documentation requirement of TCSEC is that:

"Documentation shall be available that provides a description of the
manufacturer's philosophy of protection and an explanation of how this
philosophy is translated into the TCB."[6]

The above requirement suggests that the system security overview section
should include an additional subsection on security philosophy. This
section should contain a discussion of the security threats that could be
countered by the use of this system, and of specific countermeasures based
on security policy and accountability.

Security Policy

(NAR)

Accountability

The second documentation requirement is: "The procedures for examining and
maintaining the audit files as well as the detailed audit record structure
for each type of audit event shall be given [6]. This requirements implies
that the following sections should be added to the accountability area:

Identification and Authentication

(NAR)

Audit

The TFM should include a section describing the audit mechanisms, TCB
commands, interfaces, and procedures for the following activities:

     ₧ deterimine audit selection mechanisms; these mechanisms include the
     commands and procedures necessary to display all security-relevant
     auditable events, to select the required and the optional audit
     events, and to turn on and off events selectively on a per-user and
     per-process basis;
     ₧ conduct audit log management; this activity includes commands and
     procedures to create, save, and destroy saved audit logs; to change
     audit log size and warning point for audit log overflow; to format,
     compress and display audit logs;
     ₧ protect audit commands and databases;
     ₧ ensure maintenance of audit consistency;
     ₧ perform postprocessing of audit data; this is an optional feature
     of a system and of the TFM, and includes mostly application-specific
     commands and procedures for intrusion detection. (However, all of
     these commands and procedures, and also the available tools and their
     protection from unauthorized user access, should be described
     whenever they are provided);

The audit section of the TFM shall include a detailed description of the
audit record structure for each type of audit event and of the entire
audit log. (For specific details of audit requirements, the reader should
refer to [1]).

Routine Operations

(NAR)

Security of the TCB

Additional requirement that is relevant to TCB protection is included
here.

Requirements and Recommendations for Security

Class B1

All TFM requirements of a class C2 system are included here. The
documentation requirements of class B1 suggest significant additions to
the TFM contents beyond those implied by the TCSEC requirements of
security policy and accountability.

The TFM of a class B1 system should include the following additional
documentation:

TFM Introduction

(NAR)

System Security Overview

This section should include any additional requirement referring to the
system security overview. That is, this section of the TFM "shall provide
guidelines on the consistent and effective use of the protection features
of the system; [and] how they interact." [6] This suggests that the TFM
should include a discussion of the interaction between the protection
mechanisms and functions available to administrative users and those
available to ordinary users. As mentioned in Section 2 above, this
interaction is particularly important in the areas of security policy and
accountability.

Security Policy

The additional security policy requirements of MAC and labeling suggest
that additional administrative responsibilities should be documented in
the TFM. The TFM requirement that "[t]he manual shall describe the
operator and administrator functions related to security,"[6] suggests
that the TFM should include a description of all TCB commands, interfaces
and procedures to perform the following functions:

     ₧ define and change system security profiles;
     ₧ classify, reclassify, import, and export objects;
     ₧ perform consistency checks on system and user security profiles.

Accountability

Identification and Authentication

The B1 requirements mandate the identification and authentication
recommendations of classes C1 and C2 (i.e., they mandate the
identification and authentication on a per-individual-user basis). In
addition, it requires that the TFM includes TCB commands and procedures to
define and change the user (and, possibly, group) levels of trust. It also
requires that the computation of a subject's login level of trust be
included in the TFM.

Audit

The additional B1 requirements that shall be included in the TFM
documentation include:

     ₧ a description of how the audit mechanism records any override of
     output markings;
     ₧ a description of how the TCB commands, interfaces, and procedures
     support audit on a per-object-sensitivity-level basis.

Routine Operations

     (NAR)

Security of the TCB

The additional TFM requirement in this area is that the TFM "shall provide
guidelines on [...] how to securely generate a new TCB"[6].

This requirement suggests that the TFM include:

     ₧ a list of approved tools for TCB generation;
     ₧ a description of procedures for TCB generation;
     ₧ a description of the vulnerabilities in generating a new TCB.

The B1 requirements of the TFM also state that the TFM "shall provide
guidelines on [...] privileges needed to be controlled in order to operate
the facility in a secure manner" [6]. This implies that the settings and
the defaults for the protection privileges of the TCB files should be
specified. Warnings about the improper setting of such privileges should
be included.

Requirements and Recommendations for Security

Class B2

All TFM requirements of the class B1 are included here. The documentation
requirements of class B2 suggest additions to the TFM contents beyond
those implied by the TCSEC requirements of security policy,
accountability, and operational assurance.

The TFM of a B2 system should include the following additional
documentation.

TFM Introduction

(NAR)

System Security Overview

The only additional requirement for inclusion in this section is the
separation of administrative functions into two roles, namely that of the
administrator and that of the operator. Section 3 discusses the
documentation requirements for B2 role separation.

Security Policy

The two additional security-policy requirements that should be documented
in the TFM address the areas of subject sensitivity and device labels. The
TFM shall include the TCB commands and procedures to:

     ₧ change the security label of an active subject (if this function is
     provided);
     ₧ assign and change the device sensitivity levels.

This section of the TFM shall also include a discussion of the security
vulnerabilities associated with change of trust level of an active
subject. Also it shall include a discussion of the relationship between
the device sensitivity levels and the level of trust associated with the
physical environment in which the devices are located.

Accountability

Identification and Authentication

The only additional TFM requirement here is that of documenting the
trusted-path mechanisms available to administrative users whenever this
mechanism differs from that available to ordinary users (and documented in
the SFUG).

Audit

The only additional TFM requirement of the audit area is that of defining
the TCB commands and interfaces for auditing covert channels, for setting
delays in covert channels, and for randomizing covert-channel variables.

Routine Operations

The routine operations performed by administrative users should be
presented according to the separation of roles required by the trusted
facility management area of the TCSEC and suggested by [7].

Security of the TCB

The additional TFM requirements for this section include:

     ₧ the list of TCB modules shall identify the modules of the reference
     monitor mechanism;
     ₧ "[...] the procedures for secure generation of a new TCB from
     source after modification of any modules in the TCB shall be
     described" [6]. (This requirement implies that configuration
     management shall be in place. References to additional documents
     defining these procedures and plans could be included in the TFM).

7.5 Requirements and Recommendations for
Security

Class B3

The only additional requirements of class B3 that shall be included in the
TFM are in the areas of system overview, audit, routine operations, and
security of the TCB.

TFM Introduction

(NAR)

System Overview

The TFM should include a discussion of the physical security assumptions
made by the system designers and implementators that must be satisfied by
the installed system. Also, this section shall include a discussion of the
separation between the security-relevant and security-irrelevant functions
of the administrators and operators (see [7]).

Security Policy

(NAR)

Accountability

Identification and Authentication

(NAR)

Audit

The TFM should describe the TCB commands and interfaces available to the
auditor that enable him or her to monitor the accumulation of auditable
events and to respond effectively to such event signals.

Routine Operations

The additional routine operations carried out by secure and ordinary
operators should be specified in the TFM. These should include:

     ₧ the identification of damaged user files and volumes;
     ₧ the routine backup of TCB files;
     ₧ the mounting and unmounting of volumes.

Security-irrelevant administrator and operator actions, such as handling
user requests and managing the accounting system, should also be
documented here.

Security of the TCB

Two additional TFM requirements are included here. The first is that "[The
TFM] shall include procedures to ensure that the system is initially
started in a secure manner" [6]. This requirement suggests that the TFM
must document procedures for:

     ₧ TCB hardware installation (using the list of approved hardware
     modules);
     ₧ TCB loading; TCB data structure initialization;
     ₧ Initialization of privileges for TCB file ;
     ₧ use of approved initialization tools.

The second requirement is that "procedures shall also be included to
resume secure system operation after any lapse in system operation" [6].

This requirement suggests that the TFM should document procedures for:

     ₧ analysis of system dumps;
     ₧ crash recovery and restart in a secure state;
     ₧ repair of damaged TCB data structures (e.g., labels);
     ₧ changes of configuration parameters (e.g., table sizes);
     ₧ consistency checking procedures.

Requirements of Security Class A1

Although no additional explicit TFM requirements beyond that required for
B3 are included here, the TFM should define procedures for trusted
distribution consistent with the [6] requirements.

GLOSSARY 1

Access - A specific type of interaction between a subject and an object
that results in the flow of information from one to the other.

Account Administrator - An administrative role or user assigned to
maintain accounting files, tools, user accounts, and system statistics.

Administrative User - A user assigned to supervise all or a portion of an
AIS system.

Approval Accreditation - The official authorization that is granted to an
AIS system to process sensitive information in its operational
environment, based upon comprehensive security evaluation of the system's
hardware, firmware, and software security design, configuration, and
implemetation and of the other system procedural, administrative,
physical, TEMPEST, personnel, and communications security controls.

Audit - To conduct the independent review and examination of system
records and activities.

Audit Event Selection - Selection, by authorized personnel, of the
auditable events that are to be recorded on the audit trail.

Audit Mechanism - The part of the TCB used to collect, review, and/or
examine system activities.

Audit Post Processing - Processing, by authorized personnel, of specified
events that had been recorded on the audit trail.

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 in transaction from its inception to
final results.

Auditable Event - Any event that can be selected for inclusion in the
audit trail. These events should include, in addition to security-relevant
events, events taken to recover the system after failure and any events
that might prove to be security relevant at a later time.

Auditor - An authorized individual, or role, with administrative duties,
which include selecting the events to be audited on the system, setting up
the audit flags that enable the recording of those events, and analyzing
the audit. trail

Authenticate - (1) To verify the identity of a user, device, or other
entity in a computer system, often as a prerequisite to allowing accss to
resources in a system.(2) To verify the integrity of data tHat has been
stored, transmitted, or otherwise exposed to possible unauthorized
modification.

Authenticated User - A user who has accessed an AIS system with a valid
identifier and authenticator.

Automated Information System (AIS) - An assembly of computer hardware,
firmware, and software configured to collect, create, communicate,
compute, disseminate, process, store, and /or control data or information.

Bandwidth - A characteristic of a communication channel that is the amount
of information that can be passed through it in a given amount of time,
usually expressed in bits per second.

Category - A restrictive label that has been applied to classified or
unclassified data as a means of increasing the protection of the data and
further restricting access to the data.

Channel - An information transfer path within a system. May also refer to
the mechanism by which the path is effected.

Covert Channel - A communication channel that allows two cooperating
processes to transfer information in a manner that violates the system's
security policy. Synonymous with Confinement Channel.

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.

Covert Timing Channel - A covert channel in which one process signals
information to another by modulating its own use of system resources
(e.g., Central Processing Unit time) in such a way that this manipulation
affects the real response time observed by these second process.

Data - Information with a specific physical representation.

Data Integrity - The state that exists when computerized data is the same
as that in the source documents and has not been exposed to accidental or
malicious alteration or destruction.

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.

Discretionary Access Control - A means of restricting access to objects
based on the identity and need-to-know of the user, process, and/or groups
to which they belong. The controls are discretionary in the sense that a
subject with a certain access permission is capable of passing that
permission (perhaps indirectly) on to any other subject.

Formal Security Policy Model - A mathematically precise statement of a
security policy. To be adequately precise, such a model shall 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 shall be supported by a
formal proof that if the initial state of the system satisfies the
definition of a "secure" state. 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, and algebraic specification models.

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.

Functional Testing - The portion of security testing in which the
advertised features of a system are tested, under operational conditions,
for correct operation.

Least Privilege - The principle that requires that each subject in a
system be granted the most restrictive set of privileges (or lowest
clearance) needed for the performance of authorized tasks. The application
of this principle limits the damage that can result from accident, error,
or unauthorized use.

GLOSSARY 2

Mandatory Access Control - A means of restricting access to objects based
on the sensitivity (as represented by a label) of the information
contained in the objects and the formal authorization (i.e., clearance) of
subjects to access information of such sensitivity.

Multilevel Device - A device that is used in a manner that permits
simultaneousl processing of data of two or more security levels without
risk of compromise. To accomplish this, sensitivity labels are normally
stored on the same physical medium and in the same form (i.e.,
machine-readable or human-readable) as the data being processed.

Multilevel Secure - A class of system containing information with
different sensitivities that, simultaneously permits access by users with
different security clearances and need-to-know, but prevents users from
obtaining access to information for which they lack authorization.

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.

Operator - An administrative role or user assigned to perform routine
maintenance operations of the AIS system and to respond to routine user
requests.

Output - Information that has been exported by a TCB.

Password - A private character string that is used to authenticate an
identity.

Process - A program in execution. It is completely characterized by a
single current execution point (represented by the machine state) and
address space.

Read - A fundamental operation that results only in the flow of
information from an object to a subject.

Read Access (Privilege) - Permission to read information.

Security Administrator - An administrative role or user responsible for
the security of an AIS and having the authority to enforce the security
safeguards on all others who have access to the AIS (with the possible
exception of the Auditor).

Security Level - The combination of a hierarchical classification and a
set of non-hierarchical categories that represents the sensitivity of
information.

Security Policy - The set of laws, rules, and practices that regulate how
an organization manages, protects, and distributes sensitive information.

Security Policy Model - A formal ( informal .in the case of B1)
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.

Security-Relevant Event - Any event that attempts to change the security
state of the system (e.g., change the DAC, change the security level of
the subject, change user password). Also, any event that attempts to
violate the security policy of the system, (e.g., too many attempts to log
in, attempts to violate the MAC limits of a device, attempts to downgrade
a file).

Security Testing - A process used to determine that the security features
of a system are implemented as designed and that they are adequate for a
proposed application environment.

Sensitive Information - Any information, the loss, misuse, modification
of, or unauthorized access to, that could affect the national interest or
the conduct of Federal programs, or the privacy to which individuals are
entitled under Section 552a of Title 5, U.S. Code, but that has not been
specifically authorized under criteria established by an Executive order
or act of Congress to be kept classified in the interest of national
defense or foreign policy.

Sensitivity Label - A piece of information that represents the security
level of an object and that describes the sensitivity (e.g.,
classification) of the data in the object. Sensitivity labels are used by
the TCB as the basis for MAC decisions.

Subject - An active entity, generally in the form of a person, process, or
device that causes information to flow among objects or changes in the
system state. Technically, a process/domain pair.

Subject Security Level - A subject's security level that is equal to the
security level of the objects to which it has both read and write access.
A subject's security level shall always be dominated by the clearance of
the user associated with the subject.

System Programmer - An administrative role or user responsible for the
trusted system distribution, configuration, installation, and nonroutine
maintenance.

System Security Map - A map defining the correspondence between the binary
and ASCII formats of security levels (e.g., between binary format of
security levels and sensitivity labels).

Top-Level Specification (TLS) - A nonprocedural description of system
behavior at the most abstract level; typically, a functional specification
that omits all implementation details.

Trap Door - A hidden software or hardware mechanism that can be triggered
to permits system protection mechanisms to be circumvented. It is
activated in some innocent-appearing manner (e.g., special"random" key
sequence at a terminal).

Trojan Horse - A computer program with an apparently or actually useful
function that contains additional (hidden) functions that surreptitiously
exploit the legitimate authorizations of the invoking process to the
detriment of security; for example, making a "blind copy" of a sensitive
file for the creator of the Trojan horse.

Trusted Computer System - A system that employs sufficient hardware and
software assurance measures to allow its use for simultaneous processing a
range of sensitive or classified information.

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. A TCB
consists of one or more components that together enforce a unified
security policy over a product or system. The ability of a TCB to enforce
a security policy correctly depends solely on the mechanisms within the
TCB and on the correct input by system administrative personnel of
parameters (e.g., a user's clearance) related to the security policy.

Trusted Path - A mechanism by which a person at a terminal can communicate
directly with the TCB. This mechanism can only be activated by the person
or the TCB and cannot be imitated by untrusted software.

User - Person or process accessing an AIS either by direct connections
(i.e., via terminals), or indirect connections (i.e., prepare input data
or receive output that is not reviewed for content or classification by a
responsible individual).

Verification - The process of comparing two levels of system specification
for proper correspondence (e.g., security policy model with top-level
specification, TLS with source code, or source code with object code).
This process may or may not be automated.

Write - A fundamental operation that results only in the flow of
information from a subject to an object.

Write Access (Privilege) - Permission to write an object.

REFERENCES

[1] National Computer Security Center, A Guide to Understanding Audit in
Trusted Systems, NCSC-TG-001, Version 2, June 1988.

[2] National Computer Security Center, A Guide to Understanding
Discretionary Access Control in Trusted Systems, NCSC-TG-003, version-1,
September 1987.

[3] Gligor V. D., J. C. Huskamp, S. R. Welke, C. J. Linn, W. T. Mayfield,
Traditional Capability-Based Systems: An Analysis of their Ability to Meet
the Trusted Computer Security Evaluation Criteria, Institute for Defense
Analyses, IDA Paper P1935, February 1987.

[4] Department of Defense, Password Management Guideline, CSC-STD-002-85,
April 1985.

[5] National Computer Security Center, The Rating Maintenance Phase, NCSC
TG 013, 23 June 1989.

[6] National Computer Security Center, Trusted Computer System Evaluation
Criteria, DoD 5200.28-STD, 1985.

[7] National Computer Security Center, Guidelines for Trusted Facility
Management, NCSC TG 015, 18 October 1989.