June NATIONAL COMPUTER SECURITY CENT
Found at: 0x1bi.net:70/textfiles/file?hacking/COLORBOOKS/brown.txt
GUIDE TO UNDERSTANDING TRUSTED FACILITY MANAGEMENT
June 1989
NATIONAL COMPUTER SECURITY CENTER
NCSC-TG-O15
Library No. S-231, 429
FOREWORD
The National Computer Security Center (NCSC) has established an aggresive
encourage the widespread availability to trusted computer operations. To
(TCSEC) and to assure that each feature of the TCSEC will be discussed in
NCSC has established a Technical Guideline Program This Technical
Guideline Program, and the cooperative business relationship being forged
fulfillment of our country's computer security requirement. We are
nformation.
"A Guide to Understanding Trusted Facility Management" is the latest in
the series of technical guidelines that are being published by the
National Computer Security Center. This technical guideline has been
accreditors, as well as end users understand what procedures, methods, and
classes ofthe TCSEC.
As the Director, National Computer Security Center, I invite your
_______________
atrick R. Gallagher Jr. :70
Director
National Computer Security Center
ACKNOWLEDGMENTS
Special recognition for their contributions to this document are extended
to Info Systems Technology, Inc., and to Dr. Virgil D. Gligor of the
University of Maryland as primary author of this document, and to Ms.
Valerie A. Maurer and MAJ James P. Gordon (U S Army) as Project Managers
for the production and preparation of this guideline.
Acknowledgment is given 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 guideline and providing valuable comments and suggestions. Special
thanks is given to Ms. Carol Lane, Mr. Leon Howell and Mr. Douglas Hardie
for their invaluable assistance and guidance in this effort.
PREFACE
This guideline contains information derived from the requirements of the
TCSEC prefaced by the word "shall", and recommendations derived from good
management. 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.
Throughout this guideline there will be examples, illustrations, or
citations of administrative roles and operations that have been used in
trusted facility management. The use of these examples, illustrations,
and citations does not mean that they contain the only acceptable
based solely on their availability in the computer security literature.
Examples in this document are not to be construed as the only
mplementations that will satisfy the TCSEC requirements or intended to
TABLE OF CONTENTS
FOREWORD i
ACKNOWLEDGMENTS ii
PREFACE iii
1.1. PURPOSE 1
1.2. SCOPE 2
1.3. CONTROL OBJECTIVES 3
3.1. REQUIREMENTS FOR SECURITY CLASS B2 5
3.1.1. Security Policy 5
3.1.2. Accountability 5
3.1.3. Operational Assurance 5
3.1.3.1. System Architecture 5
3.1.3.2. Trusted Facility Management 6
3.1.4. Life-Cycle Assurance 6
3.1.4.1. Security Testing 6
3.1.4.2. Design Specification and Verification
6
3.1.4.3. Configuration Management 7
3.1.5. Documentation 7
3.1.5.1. Trusted Facility Manual 7
3.1.5.2. Test Documentation 8
3.1.5.3. Design Documentation 8
3.2. REQUIREMENTS FOR SECURITY CLASS B3 9
3.2.1. Security Policy 9
3.2.2. Accountability 9
3.2.3. Operational Assurance 9
3.2.3.1. System Architecture 9
3.2.3.2. Trusted Facility Management 9
3.2.3.3. Trusted Recovery 11
3.2.4. Life-Cycle Assurance 11
3.2.4.1. Security Testing 11
3.2.4.2. Design Specification and Verification
3.2.4.3. Configuration Management 11
3.2.5. Documentation 11
3.2.5.1. Trusted Facility Manual 11
3.2.5.2. Test Documentation 11
3.2.5.3. Design Documentation 11
3.3. REQUIREMENTS OF SECURITY CLASS A1 12
3.3.1. Additional Life-Cycle Assurance Requirements 12
3.3.1.1. Configuration Management 12
3.3.1.2. Trusted Distribution 12
4.1. SEPARATION OF ADMINISTRATOR AND OPERATOR 13
4.1.1. Security-Relevant Functions of the System
Administrator 16
4.1.2. Security-Relevant Functions of the Operator 17
4.2. SEPARATION OF SECURITY AND NONSECURITY-RELEVANT FUNCTIONS 17
4.3. IMPACT OF OTHER TCSEC REQUIREMENTS 19
5.1. FUNCTIONS OF THE SECURITY ADMINISTRATOR 24
5.2. FUNCTIONS OF THE SECURE OPERATOR 30
5.3. FUNCTIONS OF THE ACCOUNT ADMINISTRATOR 31
5.4. FUNCTIONS OF THE AUDITOR 32
5.5. FUNCTIONS OF THE OPERATOR 36
5.6. FUNCTIONS OF THE SYSTEM PROGRAMMER 37
5.7. OTHER ROLES 38
5.8. RELATIONSHIP AMONG ADMINISTRATIVE ROLES 39
6.1. SECURITY POLICY 42
6.2. ACCOUNTABILITY 43
6.3. ASSURANCE 44
6.3.1. Operational Assurance 44
6.3.2. Life-Cycle Assurance 46
6.4. DOCUMENTATION 46
GLOSSARY 47
REFERENCES 58
LIST OF FIGURES
Figure 1. Required Class B2 Separation of Functions,
Privileges,and Databases 16
Figure 2. Required Class B2 and Class B3 Separation
of Functions, Privileges, and Databases of
Administrative Roles 19
Figure 3. Recommended Separation of Functions, Privileges, and
Databases of Administrative Roles 23
Figure 4. Relationships Among Administrative Roles 41
1. INTRODUCTION
The principal goal of the National Computer Security Center is to
encourage the widespread availability of trusted computer systems. In
Evaluation Criteria (TCSEC), against which computer systems could be
evaluated for security. The TCSEC was originally published on 15 August
changes, as a DoD Standard, DoD 5200.28-STD. DoD Directive 5200.28,
"Security Requirements for Automated Information Systems (AISs)", has
been written, among other reasons, to require the Depart*ment of Defense
Trusted Computer System Evaluation Criteria be used throughout the DoD.
The TCSEC is the standard used for evaluating the effectiveness of
available level of assurance. Within divisions C , B, and A, there are
manner to represent different levels of security.
1.1. PURPOSE
An important assurance requirement of the TCSEC, which appears in
all classes from B2 to A1, is trusted facility management. This refers to
the administrative procedures, roles, functions (e.g., commands, programs,
nterfaces), privileges and databases that are used for secure system
configuration, administration and operation.
The objective of trusted facility management is to support
accomplish this goal, two key requirements are the separation between
Administrator and Operator functions, in class B2, and between
Administrators, in class B3. This separation of administrative and
operator functions, and security-relevant and nonsecurity-relevant
functions of System Administrators, also applies to class A1. These
misdeed, and system failure do not affect administrative functions and
The purpose of "A Guide to Understanding Trusted Facility
Management" is to provide guidance to manufacturers on how to incorporate
functions of trusted facility management into their systems; to system
evaluators and accreditors on how to evaluate the design and
mplementation of trusted facility management functions; and to end users
on how to use these functions effectively, e.g., on how to avoid common
1.2. SCOPE
The guidelines for trusted facility management presented herein
of the TCSEC. This guideline is intended to present the issues involved
n the design of trusted facility management.
This guideline contains five.additional sections. Section 2
contains a brief overview of the inherent vulnerabilities of
administrative roles. Section 3 presents TCSEC requirements that affect
the design and implementation of trusted facility management functions,
and includes recommendations corresponding to each evaluation class.
Section 4 reviews the major requirements of trusted facility management as
Administrator's and Operator's functions and the possible partitioning of
the security-relevant functions of the Administrator and Operator into
of the other TCSEC requirements on trusted facility management, including
Not addressed herein are personnel security measures, physical
administrative measures external to the AIS. The evaluation of these
measures is beyond the scope of TCSEC-based evaluations [12, p.87]. These
by the TCSEC. Additional recommendations are made, which are derived from
the stated objectives of the TCSEC.
1.3. CONTROL OBJECTIVES
Trusted facility management is one of the areas of operational
assurance. As such, the trusted facility management is an aspect of the
objective, "assurance." The assurance objective provided in the TCSEC is:
"Systems that are used to process classified or other
nterpretation of the security policy and must not distort the intent of
that policy. Assurance must be provided that correct implementation and
operation of the policy exists throughout the system's life cycle."
This objective affects trusted facility management in two
mportant ways. First, administrative roles of the system are the key
components that help to ensure the enforcement of the system security
Second, the administrative roles must satisfy the life-cycle assurance
2. SECURITY ADMINISTRATION - THE PROBLEM
Weaknesses of trusted facility management are role specific and common to
all administrative roles. Careful examination of both common
administrative roles and role-specific weaknesses is important for both
administrative procedure external to the system in use. The distinction
between the two types of weaknesses is also useful for the strengthening
of mechanisms and procedures supporting different roles selectively.
The weaknesses discussed below are generic in the sense that they are not
Design, implementation, and use of auto*mated tools for analyzing specific
Three types of weaknesses affect all administrative roles to various
(1) unauthorized modification of hardware and software
both hardware and software changes, can take place during all phases of a
(2) penetration of a specific administrative role.
unauthorized administrative users, is usually made possible by flawed, or
(3) misuse of administrative authority. This can
arise from careless or deliberate misuse of administrative authority.
Misuse of authority can cause both TCB and user security violations, and
therefore can lead to extensive damage.
3. TCSEC REQUIREMENTS FOR TRUSTED FACILITY MANAGEMENT
Facility Management requirements.
3.1. REQUIREMENTS FOR SECURITY CLASS B2
3.1.1. Security Policy
No Additional Requirements.
3.1.2. Accountability
All identification and authentication requirements of
class B2, including trusted path, shall apply to the administrative users
ndividually.
All actions of administrative users shall be auditable in
accordance with the B2 audit requirements.
3.1.3. Operational Assurance
3.1.3.1. System Architecture
The TCB programs and data structures
mplementing administrative functions:
* must satisfy the modularity requirements of
class B2;
* must satisfy the least privilege principle;
* must use logically distinct storage objects
The interfaces of the administrative roles
mplemented by the TCB must be completely defined, and all the elements of
the TCB implementing the administrative roles must be identified.
3.1.3.2. Trusted Facility Management
The TCB shall support separate Operator and
Administrator functions. The Administrator's functions include those of:
* the Security Administrator
* System Programmer
* the Auditor
* the Account Administrator
(whenever this role is defined to be security-relevant).
These functions must be separated from those of the Secure Operator.
While the Administrator's functions may be combined into one function, we
functions include only the nonsecurity-relevant functions.
3.1.4. Life-Cycle Assurance
3.1.4.1. Security Testing
All security testing requirements of class B2
apply to the TCB functions and interfaces implementing administrative
3.1.4.2. Design Specification and
Verification
Recommendation:
-Descriptive Top-Level
Specifications (DTLSs) of the TCB functions and interfaces implementing
administrative roles must be maintained that completely and accurately
messages, and effects.
-A formal security and
ntegrity model of trusted facility management should be used to define the
3.1.4.3. Configura*tion Manage*ment
All configuration management requirements of
class B2 apply to the TCB functions and interfaces implementing administrative
3.1.5. Documentation
3.1.5.1. Trusted Facility Manual
A manual shall be available that provides the
following:
* be addressed to the ADP
that should be controlled when running a secure facility.
* give procedures examining
and maintaining the audit files.
* give the detailed audit
* describe the operator and
administrator functions related to security, to include changing the security
characteristics of a user.
* provide guidelines on the
consistent and effective use of the protection features of the system.
* explain how the protection
features of the system interact.
* show how to securely
* provide guidelines on
facility procedures, warinings, and privileges that need to be controlled in
order to operate the facility in a secure manner.
* identify the TCB modules
that contain the reference validation mechanism.
* describe the procedures
for secure generation of a new TCB from source after modification of any
modules in the TCB.
3.1.5.2. Test Documentation
All test documentation requirements of class B2,
except those for covert channel testing, apply to the TCB functions and
nterfaces implementing administrative roles as stated.
3.1.5.3. Design Docu*menta*tion
Documentation shall be available that provides a
* Interfaces between the TCB modules
mplementing functions of the administrative roles;
* Specific TCB protection mechanisms used for
the separation of administrative roles;
* Descriptions of the TCB modules
mplementing functions and interfaces of the administrative roles;
* How the least privilege principle is
administrative roles;
* How the actions of the administrative
Recommendation:
-A formal description of the security and integrity policy model
used to define the separation of administrative roles should be available
and proven to be sufficient to enforce the claimed separation.
3.2. REQUIREMENTS FOR SECURITY CLASS B3
All the requirements of Class B2 are included at this level. The
additional class B3 requirements are listed below.
3.2.1. Security Policy
No Additional Requirements.
3.2.2. Accountability
The trusted-path requirements of class B3 apply to
administrative users.
The additional audit requirements of class B3 apply to the
administrative users.
3.2.3. Operational Assurance
3.2.3.1. System Architecture
The additional TCB structuring requirements of
class B3 (i.e., significant use of abstraction, information hiding, and
layering) apply to the functions and interfaces of the TCB implementing
administrative roles.
3.2.3.2. Trusted Facility Management
The security-relevant administrative functions
(i.e., those of the Security Administrator, System Programmer, Auditor and
the Secure Operator's roles defined above) must be separated from the
nonsecurity-relevant administrative functions.
The security-relevant administrative functions
must be limited to those that are essential to performing the security
All actions of security personnel (Secure
Administrator and Secure Operator) must be audited.
Recommendations:
- The functions of security administration and
* System
* their privileges
* their databases.
- Different levels of trust should be
established for the following roles in accordance with the power and
vulnerability of each role:
* System Programmer (maintenance and
* Security Administrator;
* Auditor;
* Secure Operator;
* Account Administrator;
* Operator.
(Note: The distinction between the System
Administrators, Operators, and System Security Officers is explicitly made
n the audit requirements of the TCSEC [11, p. 16]. These roles
correspond to the Account Administrator, Secure/Normal Operator, and
Security Administrator/Auditor roles above. Also note that these
nonsecurity-relevant functions as they are made in the audit -- not
trusted facility management -- requirement area).
3.2.3.3. Trusted Recovery
The trusted recovery requirement of class B3
applies to the functions and interfaces of the TCB implementing
administrative roles.
3.2.4. Life-Cycle Assurance
3.2.4.1. Security Testing
All additional security testing requirements of
class B3 apply to the functions and interfaces of the TCB implementing
administrative roles.
3.2.4.2. Design Specification and
Verification
Recommendation:
- The additional design
the functions and interfaces of the TCB implementing administrative roles.
3.2.4.3. Configuration Management
No Additional Requirements.
3.2.5. Documentation
3.2.5.1. Trusted Facility Manual
The additional requirements shall include
3.2.5.2. Test Documentation
No Additional Requirements.
3.2.5.3. Design Docu*menta*tion
No Additional Requirements.
3.3. REQUIREMENTS OF SECURITY CLASS A1
All requirements of the security class B3 are included here. The
only additional requirements are in the following "Life-Cycle Assurance"
areas:
3.3.1. Additional Life-Cycle Assurance Requirements
3.3.1.1. Configuration Management
All additional configuration management
mplementing administrative roles.
3.3.1.2. Trusted Distribu*tion
All trusted distribution requirements of class
A1 apply to the TCB functions and interfaces implementing administrative
4. SATISFYING THE TCSEC REQUIREMENTS
The principal requirements of trusted facility management are:
* the separation of Operator and Administrator
functions;
* the logical (or physical) separation of the
* the implementation of least privilege such
that functions have only the minimum necessary privileges to the databases.
4.1. SEPARATION OF ADMINISTRATOR AND OPERATOR FUNCTIONS
The separation of Administrator and Operator functions is a
"The TCB shall support separate Operator and Administrator
functions."
The primary purpose behind the separation of the Operator and
Administrator functions is to limit the potential damage that untrusted,
or errant, code can inflict on the information the TCB uses to enforce the
affecting the enforcement of policy. Through the application of the
Administrator functions so that they are prevented from executing
untrusted code, the TCB data structures can be protected. The principle
of least privilege requires that each subject be granted the most
of the operator and administrator functions, the privileges need to be
established at a low level of granularity so that the proceses that
mplement those functions do not have unnecessary privileges. This low
level of granularity provides several important protections:
* limits the effects of errors on the part of
the administrator;
* limits the effects of incorrect code which
mplements the administrator functions;
* provides some protection against malicious
administrators, in that damage that can be done is strictly contained to the
the auditing of administrator actions. (This argument can be extended to
malicious code which is inserted in the administrator functions.)
The TCSEC recognizes the need to separate the operator and
adminstrator functions from the normal user abilities to execute code.
There are several ways to implement such separation. One way is to
enforce those restrictions on the Administrator and Operator functions.
They can only execute trusted code that has been shown to preserve the TCB
functions also have a separate account that allows them to be a normal
user. That separate account would not have any Operator or Administrator
capabilities. Whatever approach to separation is selected, it must be
code.
The separation of Operator and Administrator functions, namely
between the commands, programs, and interfaces implementing those
functions, is important because these functions are used with different
to be trusted to the same degree as that needed for Administrators. It
violated, overexposing the system to error, failure, and misdeed.
Furthermore, lack of functional separation would fail to confine the
effects of any function penetration, leaving the entire system in a
vulnerable state.
In addition to the separation of Administrator and Operator
functions, trusted facility management should also separate internal
and balances are necessary to avoid trusting too many all-powerful
Administrators. The identification of the security-relevant, internal
corresponding database shall be carefully performed and documented. The
the separation of accessible objects and of access privileges to shared
the least privilege principle within the TCB because it helps identify and
eliminate unnecessary Operator access to administrator data. For example,
the Administrator has full access to system databases that need not be
fully accessible to the Operator; i.e., the Administrator has Read/Write
Write privilege of the Operator to these databases would be eliminated.
Also, because these databases are separate, consistency checks may be
applied to the security-relevant functions of the Operator. This would
ncrease the robustness of the administrative functions of the system and,
mplicitly, its usefulness.
Figure 1 illustrates both the separation of function and of
Operator and Administrator are completely separated, the Administrator's
Administrator can always get access to all Operator functions, databases,
and privileges. For example, an Administrator can always log in as an
Operator and perform Operator functions. In contrast, the Operator cannot
the Administrator's. Note, this hierarchical relationship of roles is a
functional hierarchy. The system could provide a "flat" set of roles,
functions and privileges, and the hierarchy could be managed
administratively.
4.1.1. Security-Relevant Functions of the System
Administrator
The security-relevant functions of the System
Administrator include those that:
* Define and change the user security
characteristics and those of the system security data (e.g., user identifier,
user's group identifiers, user/group maximum security level; and the
maximum/minimum security level of the system data, the maximum/minimum
* Define and change the system's security
characteristics (e.g., security level limits of multilevel channels, I/O
* Perform system programming functions; (e.g.,
trusted system configuration in accordance with the configuration management
may affect system configuration, distribution and installation).
* Perform audit functions (e.g., determine what
events should be audited, manage the audit trail, analyze the audit trail,
4.1.2. Security-Relevant Functions of the Operator
The security-relevant functions of the Operator include
those that:
* Enable and disable peripheral
* Control the mounting of file systems
and load labeled disk packs and tape reels on appropriate drives.
* Recover user files following system
crashes.
* Handle printed output.
* Perform maintenance operations on
user databases and routine maintenance of TCB databases.
* Boot up and shut down the system.
4.2. SEPARATION OF SECURITY AND NONSECURITY-RELEVANT FUNCTIONS
The second requirement of the trusted facility management is to
dentify, audit, and separate the security-relevant functions of the
Administrator from the nonsecurity-relevant functions. The purpose of
this requirement is to prevent an Operator or Administrator from executing
untrusted code using their special privileges that would enable that code
to corrupt the policy enforcement data or mechanisms. This requirement is
ntroduced in class B3, and is stated in the TCSEC as follows:
"The functions performed in the role of a
Security Administrator shall be identified. The AIS administrative personnel
AIS. Nonsecurity functions that can be performed in the Security
Administrator role shall be limited strictly to those essential to performing
the security role effectively."
Both the Administrator and the Operator roles include
administrative functions that are used to implement the security and
accountability policies supported by a system. Nonsecurity-relevant
functions are those that cannot affect the implementation of security and
accountability policies supported by a system. The separation of
nonsecurity-relevant functions need to be trusted to a degree lower than
that of the security-relevant ones. A higher degree of trust implies that
the operational and life-cycle assurance tasks are more extensive than
those necessary for functions of a lower level of trust. Although some
nonsecurity-relevant functions of the Administrator may be functionally a
violations. In class B3, essentially where the nonsecurity-relevant
functions of the Administrator shall be removed from the TCB. The TCSEC
essential to performing the security role. While the separation of
administrative functions is not required below class B2, the benefits and
Figure 2 illustrates both the separation of function and of
of the Operator and Security Administrator (i.e., the nonsecurity-relevant
(Alternative administrative procedures for systems that do not
may be useful for systems in TCSEC classes C1 through B1.)
4.3. IMPACT OF OTHER TCSEC REQUIREMENTS ON TRUSTED FACILITY
MANAGEMENT
The third important requirement of trusted facility management is
the integration of functions and programs that implement administrative
accountability, assurance, and documentation requirements of specific
TCSEC classes are satisfied. For example, in a B3 or above system, the
necessary and that they are designed to satisfy the abstraction,
nformation hiding, and layering requirements. Furthermore, in a class B3
or above system, the nonsecurity-relevant functions of Administrators
excluding from the TCB modules that are not protection critical" [11].
Some work environments require the system to support multiple work shifts.
Such a system design, allowing multiple individuals to belong to the same
Most documentation requirements of the TCSEC apply to trusted
facility management as stated in each evaluation class. However, some
Users' Guide (SFUG) and for covert channel analysis are obviously not
applicable. The SFUG is relevant for all users, whereas the Trusted
Facility Manual and Management are relevant only for administrative users.
Also, since most administrative users have multilevel access to system
and user data, they must be trusted to maintain the secrecy and
classification of the data. Thus, administrative users must be cleared to
the highest level of data classification. Furthermore, all code
mplementing functions of administrative roles should be scrutinized to
ensure, to the largest extent possible, that it does not contain any
Trojan horses or trap doors. Additional requirements imposed by the TCSEC
oftrusted facility management are discussed in the section entitled,
"TCSEC Requirements For Trusted Facility Management."
5. SEPARATION OF OPERATOR'S AND ADMINISTRATOR'S ROLES
An important aspect of trusted facility management is that of
Operators into separate roles. For example, this partitioning could
of Accounts Administrator; and also could distinguish between the
the nonsecurity-relevant ones (the Operator role). Although this further
t is suggested:
(1) by the need to differentiate between the
Administrator and Operator,
(2) by the need to divide the power (e.g.,
that incorporate different levels of trust,
(3) by the need to avoid entrusting all
The System Programmer's functions differ from those of the
Security Administrator, Auditor, Account Administrator and Operators. The
System Programmer's functions, privileges, and databases include those of
the other roles, as the System Programmer is the most privileged
administrative user defined in any system. In contrast with the other
s the case because some of the System Programmer's actions take place
before the Auditor's programs and databases are configured and loaded.
Furthermore, the System Programmer's maintenance activities may refer to
the maintenance/repair of the TCB, including the other roles' interfaces
(e.g., commands, programs), databases, and privileges. Whenever possible,
the System Programmer functions should be relegated to system maintenance
mode only and monitored by administrative procedure. Whenever possible,
classified data, have been removed (e.g., by changing disk packs or
overwriting memory) prior to performing TCB maintenance. Note that any
modification of the TCB code, even by authorized users in the System
allow the design of a system whose mode of operation does not include an
all-powerful role.
The Auditor's functions, databases, and access privileges differ
Administrator, Account Administrator, Operators). The separation of the
Auditor's functions, databases, and access privileges from those of the
Security Administrator, Account Administrator, and Operators is an
mportant application of the separation of privilege and least privilege
Security Administrator be allowed to undertake Auditor functions or
vice-versa, the entire security function would become the responsibility
of a single, unaccountable individual or role in normal mode of system
operation. For example, a Security Administrator may take actions that
evidence of his actions. Although this is obviously undesirable, the
TCSEC does not require the separation of Security Administrator and
Auditor functions (and neither does it require the separation between
Secure Operator and Operator functions).
Figure 3 illustrates both the fine-grained separation of roles and
of databases/privileges. The relationships between the different roles
The design of each administrative role should include explicitly the set
of commands, privileges, and databases specific to that role. In
contrast, the assignment of individuals to the roles is best left to the
management of the installations familiar with the skill, interests, and
trust that can be assigned to the individuals. Furthermore, this guide
Such distinctions depend on the operational environment and administrative
two roles become indistinguishable, whereas in large system environments
the two roles are different. In some environments, the System Programmer
n others the System Programmer can only install a given object code
version of it. For example, it is not uncommon that System Programmers at
a given installation site add device drivers to a TCB for new multilevel
System Programmer is allowed to modify, recompile, and rebuild the TCB,
nstallation site and evidence be gathered to demonstrate to the
Accreditor that the system rating is maintained properly. Again, it
configuration may invalidate the system's rating.
The distinction between various Operator's and Administrator's functions
are established by:
(1) who performs the system configuration,
(2) who defines the user and the system security
characteristics,
(3) who performs systems operations such as
effective management of the computer resources and accountability for
those personnel.
5.1. FUNCTIONS OF THE SECURITY ADMINISTRATOR
The security-relevant functions of the Security Administrator can
operate at more than one security level, and invoke processes or programs
that operate with some system privileges. Thus, these functions must be
trusted to a high degree. These functions include identification and
authentication functions, mandatory access control functions, and
1. The identifica*tion and authentica*tion functions of the
Security Administrator may include:
The setting of the parameters of the login/out mechanism,
* timeout period (maximum amount of time the system waits
for the next command or for the completion of the current command);
* maximum login time (maximum amount of time the user may
* limit of successive, unsuccessful tries to log in from a
* limit of successive, unsuccessful tries to log in to an
account, regardless of the terminal location, before Administrators are
notified;
* terminal lockout establishment and resetting;
* multiple (simultaneous) login attributes;
* whether a specific user's login needs to trigger an
administrative warning (to the Administrator or to the Operator's console).
The setting of the authentication parameters; the Security
Administrator functions may include those that carry out the following
* if the authentication mechanism is password-based, the
Security Administrator determines the password characteristics (whether the
user's password choice is user-generated or system-generated, the setting of
the minimum and maximum password age, the password complexity parameters,
etc.);
* if the mechanism is dialogue-based, the Administrator
nstalls the dialogue programs on a per-user basis;
* the Administrator defines and manages the distribution
of special passwords for the trusted processes that are started by passwords
(i.e., the TCB repair and maintenance processes, such as security-label
[Note: The above
and the system Security Administrator carries out the installation decisions
made by that organization.]
The definition of user account and registration profile;
this definition may include:
* user identifier (this should be unique for the lifetime
of the system); initial user password; change of user password;
* user's full name, address, and affiliation;
* user's group identifiers (these should also be unique
for the lifetime of the system);
* user's default group.
The definition of group accounts and
* user group id (this should be unique for the system's
lifetime);
* group title, group administrator identifier, name and
address;
* group disk quota;
* group statistics.
[Note: In some
environments, the user and the group identifiers of registered users may not
be disclosed to other users. Note also that, whenever the TCB does not
automatically create unique identifiers for users and for groups, the system
Security Administrator does not reuse user/group names until he is certain
that name conflicts do not occur.]
2. The mandatory access control functions of the Security
Administrator may include the following:
Definition and maintenance of the security label map; this
ncludes functions such as the mapping between internal representations and
Setting of the security-level limits and the default
Labeling of imported unlabeled data, and unlabeled media
Reclassification of objects; this includes:
* object upgrade or downgrade;
* label overrides on user output;
* restoration of damaged labels (whenever this function is
not provided by the System Programmer role).
3. The discretionary access control functions of the Security
Administrator may include the following:
Initialization of the discretionary access privileges for
nitialization of storage quotas for user groups.
Definition and maintenance of group membership (whenever
[Note: Since any change in group
membership affects all discretionary access control decisions made by
ndividual users, such changes should not take place without prior
consultation with the users who may be affected by this decision.]
Setting of discretionary privileges on file systems.
Changes of object ownership in systems that support the
notion of ownership; also, changes of discretionary privileges on objects
Discretionary distribution, review, and revocation of
ndividual users to distribute, review, and revoke privileges directly (i.e.,
4. Additional functions of the Security Administrator are listed
below. Specifically, the Security Administrator may:
Perform consistency checks to verify that:
* the database of user and system security profiles
* the TCB is installed properly (e.g., displays and checks
nstallation tables);
* the TCB does not contain extraneous programs (e.g.,
Determine that the current system configuration is within
the constraints established by configuration management and the System
* device and terminal registration;
* maximum storage size;
* file (device) system name table and file (device) mount
tables;
* device and terminal connection database.
Cut off user/group accounts (whenever the Account
Administrator is not defined as a separate role).
Delete user/group accounts.
Display and update constants of various system tables.
Initiate and analyze the system integrity tests.
Supervise the maintenance procedures (hardware, etc.).
Respond to real-time alarm messages (B3 and higher).
Destruction of errant processes.
Definition of the site identifier, logo, and the site
authentication protocols within a network.
Set up and access the following four
types of databases:
* The database of the user and system
* The security label map;
* The file system hierarchy;
* The system configuration database
[this includes the current hardware configuration and the security-level
limits of the various devices, terminal connections, the file-system name and
mount database, etc.].
All the modifications to these databases are performed by the
Security Administrator using the commands of a trusted database editor and
the system's trusted path. Although the trusted path mechanism is not
commands are part of the administrative interface commands that must be
Administrators are audited.
5.2. FUNCTIONS OF THE SECURE OPERATOR
The security-relevant functions of the Operator role can operate
across more than one security level and sometimes invoke processes that
trust. An Operator who executes security-relevant operations is called
the Secure Op*er*a*tor. These functions of the Secure Operator may
nclude the following:
1. Booting and shutting down the system; setting the system's
clocks; also, setting the security level of individual system devices within
the range of levels allowed by the Security Administrator's database.
[Note: Shutting down the system requires that the
Operator ensure that appropriate physical and administrative security
features be in place to protect the information while the system is not
the date be removed and the system cleared.]
2. Locating damaged user files and volumes. The "salvager" process
dentifies damaged labels (e.g., labels inconsistent with those of containing
until repair is finished by the System Programmer and Security Administrator.
3. Performing routine maintenance of TCB databases.
The Operator performs the following routine maintenance
operations:
* audit file backup (whenever this is not
ncluded in the Auditor's role);
* security-level changes for some devices (these
are within the limits set by the system Security Administrator);
* user database backup;
* security-map backup;
* TCB tables backup.
It must be noted that the Operator should not have the privilege
to modify file contents for file backup.
4. Performing on-line terminal and device tests (including
authentication tests).
5. Responding to user's requests.
The Operator should be able to respond to the
following user requests:
* mount/unmount physically (externally) labeled
* import/export other physically (externally)
labeled data into/from the system.
It must be noted that all Operator's actions must be auditable.
Mounting unlabeled storage devices is not recommended. The TCB needs the
Label information in order to correct access control decisions. If the
Operator is not provided the label, the system will not be able to enforce
the policy correctly.
5.3. FUNCTIONS OF THE ACCOUNT ADMINISTRATOR
The security-relevant functions of the Administrator role may not
need the special privileges to operate properly, but in most installations
they will be trusted processes However, all output generated by the
Account Administrator will be marked with the highest security level.
Otherwise, leakage of classified information may take place (e.g., encoded
n the user bills). The nonsecurity-relevant role of the Security
Administrator is called the Account Administrator.
The (nonsecurity-relevant) functions of the Account Administrator
are listed below. Specifically, the Account Administrator:
1. Installs and maintains accounting files.
2. Turns system accounting on and off.
3. Runs accounting tools and produces
accounting reports/bills.
4. Enables and disables accounts at users'
Administrator); however, the Account Administrator does not have the privilege
to define or change the users' security profiles.
5. Establishes the billing rates, prices and
6. On a regular basis, collects system
* system availability;
* system configuration;
* disk/CPU/memory statistics.
7. Publishes revenue/cost reports.
5.4. FUNCTIONS OF THE AUDITOR
The Auditor role invokes processes that operate with system
trust. These functions include those that enable the audit selectivity
mechanism (e.g., audit-event setup and change), the management of audit
trails, the setting of the covert-channel delays and randomization
variables, audit data compression and postprocessing analysis [7]. Data
they may contain information generated at all security levels defined in
the system. System High is defined as the security label that dominates
all other security labels in the system. In a sense, it is the highest
the System High level such that it is hierarchically higher than all the
mandatory access controls provide additional protections for the audit
1. The Auditor functions that define the events recorded in the
audit log (or trail) may include:
Functions that turn on and off events that should be recorded in
the audit trail to ensure the consistency of subsequent events selected by
the Auditor. These events ensure that the postprocessing tools function
object-unique name is the unique name that identifies and distinguishes a
file system, the object-unique name includes the associated directory
names so users can use the same name for objects in different
For similar reasons, all events that record process creation or
Functions that display all security-relevant events which can be
audited.
(The determination of the security-relevant events in a system is
as those provided by a user invocation of a TCB or trusted process call,
s security-relevant if it causes a state transition or if it denies a
ntroduction of an object in an address space of a process is
because it causes a state transition in the interpretation of the
current-access-set component of that model's interpretation [2].
Similarly, distribution and revocation of access privileges cause a state
transition because they modify the access-matrix component of the model;
transition because it modifies the security-function component of the
model. Other state transitions, which should also be audited, may modify
multiple components of a system state; e.g., the creation/destruction of
objects that modify both the object hierarchy and the access matrix.
Additional security-relevant events may be derived from the interpretation
of the trusted facility management model whenever such a model is not
ncluded in the security policy model. Also, additional security-relevant
events may be derived from the covert-channel handling requirements of the
TCSEC).
Functions that turn on or off audit events selectively on a
ncluded here. These events may be signaled by the processors, TCB, or
trusted processes. Selection of auditor-determined subsets of these
events should also be possible.
Functions that turn on or off events representing accumulations of
other auditable events (e.g., multiple successive unsuccessful logins) and
alarms are also included here.
2. Auditor functions that help manage the audit files may include:
Creation and destruction of audit logs and postprocessing audit
files.
Change of audit-log size and of warning points. The warning
available in the audit log. When these warning points are crossed by the
event recording mechanism, an auditor warning may be given by the system.
corrective action [7].
Functions used to empty full audit files.
Functions that format and compress events in the audit log and
audit data into text format, and combine partial event records into the
Functions that display the audit log and postprocessing audit
files in various formats.
Consistency checking functions which operate on the entire auditor
3. Functions that set the delays or the randomization values for
covert channel handling should also be included in the Auditor's role.
The reason for this is that the covert channel handling guideline of the
TCSEC correlates the covert-channel audit requirement with specific
covert-channel bandwidth values and, therefore, with delay values and
audit delays, specific channels may, or may not, need to be audited.
Thus, the specification of the delay values and randomization ranges
becomes the duty of the Auditor. These functions may include:
The setting of the default and current values of the delays for
The setting of the default and current values of the randomization
4. Functions that perform the postprocessing of the audit data are
necessary for any audit log analysis and, therefore, should be included in any
trusted system. Although some of these functions are independent of the
the audit logs, most of these functions are specific to the postprocessing
analysis required by specific applications.
In summary, the functions of the Auditor role may set up, access
and modify the following types of databases:
* audit log files containing full or partial
* audit event file containing the definition of
all auditable events in the system;
* selected-event file containing the definitions
of all events selected on a per-user, per-process, per-security-level,
* formatted or compressed audit files containing
the input to the postprocessing phase;
* audit report files.
Access to the audit databases may be performed only by individuals
Use of Auditor commands must be audited. For class B3 and above systems,
the use of Auditor commands must be through the trusted path mechanism.
5.5. FUNCTIONS OF THE OPERATOR
The security-relevant functions of the Operator role do not need
all the system privileges to operate properly. However, the Operator
Low and System High because he may need to operate at different security
levels. System Low is the security label that is dominated by all other
label.
The (security-relevant) functions of the Operator are defined
below. Specifically, the Operator:
1. Performs user volume backup. This includes:
* complete volume dumps;
* complete volume retrievals.
2. Performs system performance metering.
3. Responds to various other user requests
(request for the installation of user-level software packages, etc.).
4. Adjusts resource quotas for user-visible
5.6. FUNCTIONS OF THE SYSTEM PROGRAMMER
The functions of the System Programmer role are the most
configuration, distribution and maintenance. These functions are not
necessarily audited and, thus, any error, omission, or malicious act,
(However, some form of auditing, possibly off-line, is still necessary in
actions may also be required in some environments for the execution of the
System Programmer functions. Furthermore, a two-person rule may be
nstituted or built into the login procedure requiring that a System
also logging in). Thus, the System Programmer functions should have the
may include the following:
1. Trusted system distribution; for example,
this includes the generation and handling of the site's system master copy.
2. Setting of system configuration parameters
(as specified by the site's configuration management policy); for example,
this includes:
* generic system configuration;
* initialization of the TCB data
* loading of the TCB.
3. Nonroutine TCB maintenance; for example,
this includes:
* analysis of dumps;
* installation of "patches" to the TCB
code and data (for this the Operator should be able to recompile TCB code from
modified source code and should use a trusted loader to reload the system);
* trusted recovery actions after
file system structure, on individual TCB files, directories and tables,
* repairs damaged security labels
(damaged labels identified by Secure Operators or Users).
The databases of the System Programmer include:
* all TCB files (e.g., TCB code, security-map,
auditor files);
* all TCB tables (e.g., interrupt vectors, trap
tables, gates).
5.7. OTHER ROLES
Other administrative roles can be defined in a secure system. For
example, in certain environments the role of the Analyst can be defined.
An Analyst may be an otherwise unprivileged user who is trusted to label
mported data from various system inputs, to create new files and label
them as he sees fit. The Analyst cannot label any data file with a
actions are audited as are those of a normal user.
When a system is tied into a network, additional roles may be
necessary to ensure consistency and accuracy of the network policy
enforcement. Such roles could involve additional security-relevant
5.8. RELATIONSHIP AMONG ADMINISTRATIVE ROLES
The fine-grained separation of administrative roles defined above
administrative roles based on a notion of "role dominance" (not to be
confused with the notion of dominance among security or integrity levels).
This notion signifies the ability of an administrative user in a certain
other roles and, if necessary, to log in and take actions in that role.
Object attributes include:
* access privileges;
* size;
* security and integrity levels; and
* ownership.
Profile attributes include:
* user and group identifiers;
* passwords;
* group membership; and
* time restrictions on user activity.
The above notion of role dominance can be useful because it
administrative users' background and interests, etc.) that should be
nvested in a role and a measure of vulnerability associated with that
maintains sensitive information describing the behavior of all users,
ncluding the administrative ones. The Security Administrator dominates
the Secure Operator, Account Administrator, Analyst, and user roles;
noted that users in the same role do not dominate each other. Although
they share most functions, privileges, and databases of the common role,
their security profiles are disjoint to allow individual accountability.
This helps distinguish the activities of individual users in the same
functions and privileges, and the role relationships that could be managed
administratively. Implementations of hierarchical relationships among
administrative roles can benefit from the use of mandatory security and,
especially, integrity models. Mandatory integrity models, such as the
Biba model [4] and the Clark-Wilson model [8], could be used to guide the
6. IMPACT OF OTHER TCSEC REQUIREMENTS ON TRUSTED FACILITY MANAGEMENT
The major areas of the TCSEC requirements (security policy,
accountability, assurance and documentation) impact on trusted facility
management. The design and implementation of the functions of various
administrative roles may use some of the security mechanisms and policies
of the underlying system to implement some of their special protection
functions may use the discretionary access control mechanisms or may
choose to implement to protect the Security Administrator databases from
other administrative users and from normal users. This section examines
the relationship of other TCSEC requirements to trusted facility
management.
6.1. SECURITY POLICY
To support the system's security policies, the functions of
trusted facility management must control access to, and sharing of,
administrative data. Trusted processes implementing the security
functions of the Administrator's and Operator's role share files of the
administrative database in a variety of ways. Some files are private to
each role and are never shared with other roles, with other users of the
audit log and the postprocessing audit files are private to the Auditor
files, such as those containing the user and group registration, may be
Secure Operator and Account Administrator processes. Account
Administrators and Operators may perform special tasks, such as the
collection of user and system statistics and performance metering, for
others in the same role). Furthermore, other files are shared between
Security Administrator role, read by the "login" trusted process, and read
and written by the "change-password" trusted process, which can be invoked
by any user.
To control access to administrative data and to implement the
above-mentioned sharing relationships among processes of the
administrative roles, the design and implementation of trusted facility
management may, or may not, rely on discretionary and mandatory access
controls of the underlying system. If they do, some processes
mplementing role functions, which need to read and write files at all
occasionally. Some other processes will operate at the highest level in
the system (e.g., accounting and audit processes) and maintain data files
at this level (e.g., audit log and postprocessing files, accounting files).
Whenever the sharing relationships among programs and processes of
the administrative roles cannot be supported by existing mechanisms, new
mechanisms have to be introduced. For example, the association of
more complex integrity mechanisms (discussed below). In all such cases,
the design and implementation of trusted facility management functions
6.2. ACCOUNTABILITY
The accountability requirements of the TCSEC impose several
constraints on the implementation of trusted facility management, in
addition to the separation of roles. First, the identification and
authentication of all administrative users must be unambiguous, and must
be done on an individual basis, not on a per-role basis. For example, if
all users of a role share the same password, accountability will be lost
commit acts of intrusion attributable to those users.
Second, the trusted-path mechanism for classes B3 and above must
ensure that the administrative users are connected to the commands or
can interpose themselves into the path connecting any combination of the
administrative users, their commands, and their processes. This can be
accomplished by providing administrative consoles recognized and separated
by the TCB hardware or software from the rest of the terminals, or by the
Third, use of all administrative functions, other than those used
by System Programmers in maintenance mode, must be audited. This implies
that trusted programs and processes implementing these commands should be
able to request the writing of audit records during the execution of those
commands. In all areas of accountability, the design and implementation
of trusted facility management functions should follow existing guidelines
(see example, [7]).
6.3. ASSURANCE
The assurance requirements of the TCSEC have a significant impact
on trusted facility management both in the operational and in the
life-cycle areas. These requirements affect both the design and the
mplementation of the trusted facility management functions.
6.3.1. Operational Assurance
The only relevant areas of operational assurance are the
analysis area is not relevant here because (1) all users in
n an unauthorized way, and (2) all code implementing administrative
functions is reviewed to ensure, to the largest possible extent, that no
Trojan horses are present. The system integrity requirements of the TCSEC
are also irrelevant here as they deal only with the test of proper
The system architecture requirements impose major
constraints on the design of trusted facility management. Because all the
are part of a system's TCB, all requirements of TCB interface definition
apply to the administrative interfaces. Similarly, all requirements of
nternal TCB structuring, such as those of modularity, abstraction,
nformation hiding, and layering apply to the design and implementation
code of the programs and processes of trusted facility management.
Careful analysis and documentation of this design and implementation area,
as well as careful scrutiny by evaluators, is expected in this area.
The application of the least privilege principle to the
observed here. First, the protection of the administrative databases
and individual privileges. (The term file is used here in a generic sense
to represent a logically small structure such that the structure does not
nclude information unrelated to the specific function). Second, programs
and processes of the administrative roles should have access only to the
TCB and user files, and to the privileged TCB calls, that are necessary
for implementing those roles, but to no other files or calls. Several
files should be associated only with certain processes. Privileged TCB
calls, which can be represented by ring-gate descriptors [15,19],
corresponding to specific calls [16,14], should be associated with
controlled by careful application of nondiscretionary labels and
authorizations at system configuration or installation time.
The only specific requirement of trusted recovery imposed
on the design and implementation of trusted facility management is that
the consistency of the administrative databases be maintained after system
crashes. This requirement can be satisfied by ensuring that :
* these databases are stored
on nonvolatile storage that survives system crashes;
* that updates to such
* that at least one of the
administrative roles is equipped with commands for checking the consistency of
the administrative file contents. Note that this could be a fully automated
mechanism not requiring administrator interaction.
6.3.2. Life-Cycle Assurance
Most life-cycle assurance requirements apply to the
example, security testing, configuration management, and trusted
to the degree of rigor commensurate with the chosen evaluation class.
This is the case because the TCB code and interfaces include the
In contrast, only some of the requirements of the design
management directly. For example, the need for accurate DTLSs for the TCB
nterfaces applies as stated. However, the requirements for a formal
model, for an interpretation of this model in the DTLSs of the trusted
facility management part of the TCB, and for a convincing argument that
the DTLSs are consistent with the model are not directly applicable here.
The reason for this is that no generally acceptable formal model of the
trusted facility management area exists to date. Should a generally
acceptable formal model become available, then all requirements of the
management directly.
6.4. DOCUMENTATION
The documentation requirements of the TCSEC relevant to the
trusted facility management area are the trusted facility manual
of the design documentation [8]. In the design documentation area, only
the requirements referring to the DTLSs, TCB internal structuring, and
enforcement of the least privilege principle are relevant.
GLOSSARY
Access
A specific type of interaction between a subject and an
object that results in the flow of information from one to the other.
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.
Administrator
See Administrative User.
Approval/Accreditation
The official authorization that is granted to an AIS to
comprehensive security evaluation of the system's hardware, firmware, and
other system procedural, administrative, physical, TEMPEST, personnel, and
communications security controls.
Audit
To conduct the independent review and examination of
Audit Event Selection
Selection, by authorized personnel, of the auditable
events that are to be recorded on the audit trail.
Audit Mechanism
The processes used to collect, review, and/or examine
Audit Postprocessing
Processing, under the control of authorized personnel, of
Audit Trail
A chronological record of system activities that is
operation, a procedure, or an event in a 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, actions 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
events, and analyzing the trail of audit events.
Authenticate
(1) To verify the identity of a user, device, or other
entity in a computer system, often as a prerequisite to allowing access to
(2) To verify the integrity of data that have been stored,
transmitted, or otherwise exposed to possible unauthorized modification.
Authenticated User
A user who has accessed an AIS with a valid identifier and
authentication combination.
Auto*mated Informa*tion System (AIS)
An assembly of computer hardware, software and/or firmware
configured to collect, create, communicate, compute, disseminate, process,
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
Covert Channel
A communication channel that allows a process to transfer
nformation in a manner that violates the system's security policy. See
also: Covert Storage Channel, Covert Timing Channel.
Covert Storage Channel
A covert channel that involves the direct or indirect
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., CPU time)
n such a way that this manipulation affects the real response time
observed by the second process.
Data
Information with a specific physical representation.
Data Integrity
The property that data meet an a priori expectation of
quality.
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
dentity 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
ndirectly) on to any other subject.
Formal Security Policy Model
A mathematically precise statement of a security policy.
To be adequately precise, such a model must represent the initial state of
a system, the way in which the system progresses from one state to
another, and a definition of a "secure" state of the system. To be
acceptable as a basis for a TCB, the model must be supported by a formal
a "secure" state and if all assumptions required by the model hold, then
all future states of the system will be secure. Some formal modeling
techniques include: state transition models, temporal logic models,
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
formally proven.
Functional Testing
The segment 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 be granted
the most restrictive set of privileges needed for the performance of
authorized tasks. The application of this principle limits the damage
that can result from accident, error, or unauthorized use.
Mandatory Access Control
A means of restricting access to objects based on the
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 it to
compromise. To accomplish this, sensitivity labels are normally stored on
the same physical medium and in the same form (i.e., machine-readable or
Multilevel Secure
A class of system containing information with different
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,
network nodes, etc.
Object-Unique Names
The unique name that identifies and distinguishes a
file system, the object-unique name includes the associated directory
names so users can use the same name for objects in different directories.
Operator
An administrative role or user assigned to perform routine
maintenance operations of the AIS and to respond to routine user requests.
Output
Information that has been exported by a TCB.
A protected/private character string that is used to
authenticate an identity.
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
nformation from an object to a subject.
Read Access (Read Privilege)
Permission to read information.
Secure Operator
An administrative role (or user) assigned to perform those
aspects of the Operator role that can affect the security relevant data
used by the TCB to enforce its policy (e.g., notifying the TCB of the
Security Administrator
An administrative role (or user) responsible for the
enforce the security safeguards on all others who have access to the
Automated Information System (with the possible exception of the Auditor).
Also called System Ad*min*is*tra*tor.
Security Label 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).
Security Level
The combination of a hierarchical classification and a set
of nonhierarchical categories that represents the sensitivity of
nformation.
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 presentation of the security policy enforced by
the system. It must identify the set of rules and practices that regulate
Security-Relevant Event
Any event that attempts to change the security state of
the system, (e.g., change discretionary access controls, change the
event that attempts to violate the security policy of the system (e.g.,
too many attempts to login, attempts to violate the mandatory access
control limits of a device, attempts to downgrade a file, etc.).
Security Testing
A process used to determine that the security features of
a system are implemented as designed. This includes hands-on functional
testing, penetration testing, and verification.
Sensitive Information
Information that, as determined by a competent authority,
must be protected because its unauthorized disclosure, alteration, loss,
or destruction will at least cause perceivable damage to someone or
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 mandatory access control decisions.
Separation of Privilege
The separation of functions, namely between the commands,
or erroneous code in one function is prevented from affecting the code or
Spoofing
An attempt to gain access to a system by posing as an
authorized user. Also called masquerad*ing or mimick*ing.
Subject
An active entity, generally in the form of a person,
changes the system state. Technically, a process/domain pair.
Subject Security Level
A subject's security level is equal to the security level
of the objects to which it has both Read and Write access. A subject's
user.
System Administrator
See Security Administrator.
System High
The security label that dominates all other security
labels in the system. In a sense, it is the highest possible label.
System Low
The lowest security level supported by a system at a
System Programmer
An administrative role (or user) responsible for trusted
maintenance.
Top-Level Specification (TLS)
A nonprocedural description of system behavior at the most
abstract level; typically, a functional specification that omits all
mplementation details.
Trap Door
A hidden software or hardware mechanism that can be
triggered to permit system protection mechanisms to be circumvented. It
s activated in some innocent-appearing manner; e.g., a special "random"
key sequence at a terminal. Software developers often introduce trap
certain functions. Synonymous with back door.
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
Trusted Computer System
A system that employs sufficient hardware and software
assurance measures to allow its use for processing simultaneously a range
of sensitive or classified information.
Trusted Computing Base (TCB)
The totality of protection mechanisms within a computer
one or more components that together enforce a unified security policy
over a product or system. The ability of a TCB to enforce correctly a
unified security policy 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 level) related to the security policy.
Trusted Path
A mechanism by which a person at a terminal can
communicate directly with the Trusted Computing Base. This mechanism can
only be activated by the person or the Trusted Computing Base 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
nput 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
top-level specification, top-level specification with source code, or
Virus
A self-propagating Trojan horse, composed of a mission
component, a trigger component, and a self-propagating component.
Vulnerability
A weakness in system security procedures, system design,
mplementation, internal controls, etc., that could be exploited to
violate system security policy.
Write
A fundamental operation that results only in the flow of
nformation from a subject to an object.
Write Access (Write Privilege)
Permission to write an object.
REFERENCES
Technical Report MIT/LCS/TR-401, March 1988.
Exposition and Multics Interpretation," MITRE Corp., Rep. No. MTR-2997,
Systems," Mitre Corp., MTR-3153, Bedford, Mass., June 1975.
1, January/February 1987.
Research Center, Moffet Field, California, (June 1986).
Military Computer Security Policies," Proc. of the IEEE Symp. on Security
and Privacy, Oakland, Calif., April 1987.
Trusted Systems, NCSC-TG-001, version-1, July 1987.
Documentation In Trusted Systems, NCSC-TG-007, version-1, October 1988.
Access Control in Trusted Systems, NCSC-TG-003, version-1, September 1987.
CSC-STD-002-85, April 1985.
Criteria, DoD 5200.28-STD, December 1985.
M.S. Hecht, W.D. Jiang, A. Johri, G.L. Luckenbaugh, and N. Vasudevan,
"Design and Implementation of Secure Xenix," IEEE Trans. on Software
Engineer*ing, vol. SE-13, No. 2, February 1986.
Mayfield, "Traditional Capability-Based Systems: An Analysis of their
Ability to Meet the Trusted Computer Security Evaluation Criteria,"
Dotterer, V.D. Gligor, W.D. Jiang, A. Johri, G.L. Luckenbaugh, and N.
Vasudevan, "Unix Without the Superuser," Proc. of the Usenix Conference,
September 1987.
Security," Proc. of the IEEE Symp. on Security and Privacy, Oakland,
Calif., 1988.
of Information Sharing in Computer Systems," Proc. of the IEEE, vol. 63,
no. 9, September 1975.
Lecture, Communica*tions of the ACM, vol. 27, no. 8, August 1984..