GUIDE TO UNDERSTANDING TRUSTED FACILITY MANAGEMENT
NATIONAL COMPUTER SECURITY CENTER
Library No. S-231, 429
The National Computer Security Center (NCSC) has established an aggresive program to study and implement computer security technology and to encourage the widespread availability to trusted computer operations. To provide insight into the Trusted Computer Systems Evaluation Criteria (TCSEC) and to assure that each feature of the TCSEC will be discussed in detail and provide the proper interpretation with specific guidance, the NCSC has established a Technical Guideline Program This Technical Guideline Program, and the cooperative business relationship being forged with the computer and telecommunication industries, will result in the fulfillment of our country's computer security requirement. We are determined to meet the challenge of identifying trusted computer guidelines suitable for use in processing all types and classifications of information.
"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 written to help the computer security manufacturers, system evaluators, accreditors, as well as end users understand what procedures, methods, and processes are required for trusted facility management at B2 through A1 classes ofthe TCSEC.
As the Director, National Computer Security Center, I invite your recommendations for revision to this technical guideline. We plan to review this document periodically or when the need arises.
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.
This guideline contains information derived from the requirements of the TCSEC prefaced by the word "shall", and recommendations derived from good practices prefaced by the word "should" when conducting trusted facility 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 procedures, methods, or processes. The selection of these examples is based solely on their availability in the computer security literature. Examples in this document are not to be construed as the only implementations that will satisfy the TCSEC requirements or intended to single out any particular operating system to highlight weaknesses and shortfalls, but merely to provide clarification. The examples are suggestions of appropriate implementations.
The principal goal of the National Computer Security Center is to encourage the widespread availability of trusted computer systems. In support of that goal a metric was created, the DoD Trusted Computer System Evaluation Criteria (TCSEC), against which computer systems could be evaluated for security. The TCSEC was originally published 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 Directive [AIS; automated information system (AIS); automated information system security; AUTOMATED INFORMATION SYSTEMS; COMPUSEC; Computer Security; computer security (COMPUSEC); Department of Defense; DOD], "Security Requirements for Automated Information Systems (AISs)", has been written, among other reasons, to require the Department of Defense Trusted Computer System Evaluation Criteria be used throughout the DoD. The TCSEC is the standard used for evaluating the effectiveness of security controls built into AISs. The TCSEC is divided into four divisions: D, C, B, and A, ordered in a hierarchical manner with the highest division (A) being reserved for systems providing the best available level of assurance. Within divisions C , B, and A, there are subdivisions known as classes, which are also ordered in a hierarchical manner to represent different levels of security.
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, interfaces), privileges and databases that are used for secure system configuration, administration and operation.
The objective of trusted facility management is to support security and accountability policies throughout a system's operation. To accomplish this goal, two key requirements are the separation between Administrator and Operator functions, in class B2, and between security-relevant and nonsecurity-relevant functions of System 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 separations help ensure that security-adverse effects of human error, misdeed, and system failure do not affect administrative functions and data.
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 implementation of trusted facility management functions; and to end users on how to use these functions effectively, e.g., on how to avoid common pitfalls of system management.
The guidelines for trusted facility management presented herein refer to the separation of administrative functions, interfaces, and procedures of an important assurance requirement of classes B2 through A1 of the TCSEC. This guideline is intended to present the issues involved in 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 stated in the TCSEC. Section 5 presents the separation between Administrator's and Operator's functions and the possible partitioning of the security-relevant functions of the Administrator and Operator into separate roles, functions and databases. Section 6 discusses the impact of the other TCSEC requirements on trusted facility management, including design and modeling alternatives for trusted facility management.
Not addressed herein are personnel security measures, physical security of the automated information system equipment, and other administrative measures external to the AIS. The evaluation of these measures is beyond the scope of TCSEC-based evaluations [12, p.87]. These guidelines apply to computer systems, processing environments, and products built or modified with the intention of satisfying the TCSEC requirements. Note that this document contains suggestions and recommendations derived from TCSEC objectives but which are not required 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 sensitive information must be designed to guarantee correct and accurate interpretation of the security policy and must not distort the intent of that policy. Assurance must be provided that correct implementation and operation of the policy exists throughout the system's life cycle."
This objective affects trusted facility management in two important ways. First, administrative roles of the system are the key components that help to ensure the enforcement of the system security policy, and thus, their function must support the intent of that policy. Second, the administrative roles must satisfy the life-cycle assurance requirements of correct implementation and operation.
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 system designers and administrators because exposure to some of these weaknesses can be reduced or eliminated by specific designs or by 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 specific to any particular system or design. Careful analysis should be performed in designing and implementing specific systems to identify specific additional weaknesses and their required countermeasures. Design, implementation, and use of automated tools for analyzing specific system weaknesses are useful, but still a research subject .
Three types of weaknesses affect all administrative roles to various degrees:
3. TCSEC REQUIREMENTS FOR TRUSTED FACILITY MANAGEMENT
In the TCSEC, requirements for Trusted Facility Management are for security classes B2 through A1. Classes C1 through B1 have no Trusted Facility Management requirements.
3.1. REQUIREMENTS FOR SECURITY CLASS B2
3.1.1. Security Policy
No Additional Requirements.
All identification and authentication requirements of class B2, including trusted path, shall apply to the administrative users individually.
All actions of administrative users shall be auditable in accordance with the B2 audit requirements.
3.1.3. Operational Assurance
184.108.40.206. System Architecture
The TCB programs and data structures implementing administrative functions:
The interfaces of the administrative roles implemented by the TCB must be completely defined, and all the elements of the TCB implementing the administrative roles must be identified.
220.127.116.11. Trusted Facility Management
The TCB shall support separate Operator and Administrator functions. The Administrator's functions include those of:
These functions must be separated from those of the Secure Operator. While the Administrator's functions may be combined into one function, we recommend they be separated as described in section 5. The remaining functions include only the nonsecurity-relevant functions.
3.1.4. Life-Cycle Assurance
18.104.22.168. Security Testing
All security testing requirements of class B2 apply to the TCB functions and interfaces implementing administrative roles as stated.
22.214.171.124. Design Specification and Verification Recommendation:
126.96.36.199. Configuration Management
All configuration management requirements of class B2 apply to the TCB functions and interfaces implementing administrative roles as stated.
188.8.131.52. Trusted Facility Manual
A manual shall be available that provides the following:
184.108.40.206. Test Documentation
All test documentation requirements of class B2, except those for covert channel testing, apply to the TCB functions and interfaces implementing administrative roles as stated.
220.127.116.11. Design Documentation
Documentation shall be available that provides a description of:
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.
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
18.104.22.168. 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.
22.214.171.124. 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 roles effectively.
All actions of security personnel (Secure Administrator and Secure Operator) must be audited.
(Note: The distinction between the System Administrators, Operators, and System Security Officers is explicitly made in 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 distinctions do not require the separation of security-relevant and nonsecurity-relevant functions as they are made in the audit-not trusted facility management-requirement area).
126.96.36.199. 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
188.8.131.52. Security Testing
All additional security testing requirements of class B3 apply to the functions and interfaces of the TCB implementing administrative roles.
184.108.40.206. Design Specification and Verification
220.127.116.11. Configuration Management
No Additional Requirements.
18.104.22.168. Trusted Facility Manual
The additional requirements shall include procedures to ensure that the system is initially started in a secure state and procedures to resume secure system operation after any lapse in system operation.
22.214.171.124. Test Documentation
No Additional Requirements.
126.96.36.199. Design Documentation
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
188.8.131.52. Configuration Management
All additional configuration management requirements of class A1 apply to the TCB functions and interfaces implementing administrative roles.
184.108.40.206. Trusted Distribution
All trusted distribution requirements of class A1 apply to the TCB functions and interfaces implementing administrative roles.
4. SATISFYING THE TCSEC REQUIREMENTS
The principal requirements of trusted facility management are:
4.1. SEPARATION OF ADMINISTRATOR AND OPERATOR FUNCTIONS
The separation of Administrator and Operator functions is a requirement of TCSEC class B2, which states:
"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 security policy. Any code executed with Operator or Administrator privileges has the ability to change the TCB data structures, thus affecting the enforcement of policy. Through the application of the principal of least privilege and the separation of Operator and 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 restrictive set of privileges needed for the specific task. In the case of the operator and administrator functions, the privileges need to be established at a low level of granularity so that the proceses that implement those functions do not have unnecessary privileges. This low level of granularity provides several important protections:
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 data structures properly. This requires that the people who perform those 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 shown to restrict the Operator or Administrators from executing untrusted 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 privileges, on different system data. Should these functions not be separated, Operators could use commands that include Administrators' privileges and databases. This would mean that all Operators would need to be trusted to the same degree as that needed for Administrators. It would also mean that the principles of least privilege and separation of privilege, which are two of the most important security principles (see reference  for a further explanation of these principles), are 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 system databases which the Operator and Administrator manipulate. Checks and balances are necessary to avoid trusting too many all-powerful Administrators. The identification of the security-relevant, internal system databases and the correlation between each function and the corresponding database shall be carefully performed and documented. The separation of Operator's and Administrator's functions shall also lead to the separation of accessible objects and of access privileges to shared databases. This is an essential design requirement for the enforcement of 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 privileges to some (shared) databases, such as the system security profile, for which the Operator only needs Read privileges. Thus, the Write privilege of the Operator to these databases would be eliminated. Also, because these databases are separate, consistency checks may be derived from the security-relevant databases of the Administrator and applied to the security-relevant functions of the Operator. This would increase the robustness of the administrative functions of the system and, implicitly, its usefulness.
Figure 1 illustrates both the separation of function and of privileges/databases for class B2. Note, although the functions of the Operator and Administrator are completely separated, the Administrator's privileges include those of the Operator in the sense that the 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 get access to functions, databases, and privileges that are exclusively 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:
4.1.2. Security-Relevant Functions of the Operator
The security-relevant functions of the Operator nclude those that:
4.2. SEPARATION OF SECURITY AND NONSECURITY-RELEVANT FUNCTIONS
Separation of Duties
The second requirement of the trusted facility management is to identify, 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 introduced 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 shall only be able to perform Security Administrator functions after taking a distinct auditable action to assume the Security Administrator role on the 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 security-relevant functions. Security-relevant functions include all 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 security-relevant and nonsecurity-relevant functions is important because 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 part of the TCB in class B2, flaws in these functions should lead only to potential denial-of-service instances, but not to security or integrity violations. In class B3, essentially where the nonsecurity-relevant functions of the Administrator shall be removed from the TCB. The TCSEC does permit the inclusion of nonsecurity relevant functions that are essential to performing the security role. While the separation of administrative functions is not required below class B2, the benefits and protection it provides should be seriously considered.
Figure 2 illustrates both the separation of function and of privileges/databases for classes B2 and B3. Note, although the functions of the Operator and Security Administrator (i.e., the nonsecurity-relevant role of the Administrator) are completely separated.
(Alternative administrative procedures for systems that do not support any separation of roles have been suggested . These procedures 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 roles within the TCB in such a way that the security policy, accountability, assurance, and documentation requirements of specific TCSEC classes are satisfied. For example, in a B3 or above system, the design of each function supporting a specific role must ensure that the programs executing that function operate with the fewest privileges necessary and that they are designed to satisfy the abstraction, information hiding, and layering requirements. Furthermore, in a class B3 or above system, the nonsecurity-relevant functions of Administrators shall be removed from the TCB because "significant system engineering shall be directed towards minimizing the complexity of the TCB and excluding from the TCB modules that are not protection critical" . Some work environments require the system to support multiple work shifts. Such a system design, allowing multiple individuals to belong to the same role, shall ensure that these individuals are not forced to share a role password, such that accountability on an individual basis is lost.
Most documentation requirements of the TCSEC apply to trusted facility management as stated in each evaluation class. However, some requirements such as those that state the need for a Security Features 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 implementing 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 of trusted facility management are discussed in the section entitled, "TCSEC Requirements For Trusted Facility Management."
5. SEPARATION OF OPERATOR'S AND ADMINISTRATOR'S ROLES [Separation of Duties; accreditation authority; DAA; Designated Approving Authority (DAA)]
An important aspect of trusted facility management is that of partitioning the security-relevant duties of the Administrators and Operators into separate roles. For example, this partitioning could distinguish the security-relevant roles of Security Administrator, System Programmer, and Auditor-in addition to the non-security-relevant role of Accounts Administrator; and also could distinguish between the security-relevant functions of the Operator (the Secure Operator role) and the nonsecurity-relevant ones (the Operator role). Although this further partitioning of the Administrator's duties is not required by the TCSEC, it is suggested:
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 roles, some of the System Programmer's actions may not be auditable. This is 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, work on TCB code should be done on a developmental system rather than on a system in current use. The developmental system may be a physically separate system or a system from which user data, and in particular 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 Programmer role, may invalidate the system's rating. The above measures 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 significantly from those of the other administrative roles (e.g., Security 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 important application of the separation of privilege and least privilege principles. Should such separation not be performed, and should the 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 represent misuse of authority and then use Auditor functions to erase any 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 defined here are explained in Section 5.8.
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 does not distinguish between the role of the System Programmer of a specific installation and that assigned to a manufacturer's programmer. Such distinctions depend on the operational environment and administrative procedures enforced in that environment. In small system environments the two roles become indistinguishable, whereas in large system environments the two roles are different. In some environments, the System Programmer has the right to examine, modify, recompile, and rebuild the TCB, whereas in 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 devices supported in the systems, and then rebuild the TCB. Whenever the System Programmer is allowed to modify, recompile, and rebuild the TCB, strict configuration management procedures should be followed at the installation site and evidence be gathered to demonstrate to the Accreditor that the system rating is maintained properly. Again, it should be noted that any modification to the evaluated TCB code or configuration may invalidate the system's rating.
The distinction between various Operator's and Administrator's functions are established by:
5.1. FUNCTIONS OF THE SECURITY ADMINISTRATOR Separation of Duties
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 discretionary access control functions.
5.1.1. The identification and authentication functions of the Security Administrator may include:[Seperation of Duties]
The setting of the authentication parameters; the Security Administrator functions may include those that carry out the following decisions:
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.);
[Note: The above decisions are made when the system is installed for a particular organization, 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:
The definition of group accounts and registration profile; this definition may include:
[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.]
5.1.2. The mandatory access control functions of the Security Administrator may include the following:[Separation of Duties]
Reclassification of objects; this includes:
5.1.3. The discretionary access control functions of the Security Administrator may include the following:
[Note: Since any change in group membership affects all discretionary access control decisions made by individual 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 whose privileges are accidentally deleted by the object's creators or owners.
Discretionary distribution, review, and revocation of privileges on behalf of object creators/owners in systems that do not allow individual users to distribute, review, and revoke privileges directly (i.e., where the control of object sharing is centralized ).
5.1.4. Additional functions of the Security Administrator are listed below. Specifically, the Security Administrator may:
Perform consistency checks to verify that:
Determine that the current system configuration is within the constraints established by configuration management and the System Programmer. This includes the verification of:
Cut off user/group accounts [access control](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:
[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 required for these modifications in class B2 systems, the trusted editor commands are part of the administrative interface commands that must be supported by all trusted systems. All actions of the Security 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 require system privileges. Thus, these functions require a high degree of trust. An Operator who executes security-relevant operations is called the Secure Operator. These functions of the Secure Operator may include the following:
[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 running. For example, shutting down for maintenance might require that the date be removed and the system cleared.]
The Operator performs the following routine maintenance operations:
It must be noted that the Operator should not have the privilege to modify file contents for file backup.
The Operator should be able to respond to the following user requests:
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 in 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:
5.4. FUNCTIONS OF THE AUDITOR
The Auditor role invokes processes that operate with system privileges. Thus, all functions of the Auditor require a high degree of 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 . Data generated by the Auditor must be classified at the System High level since 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 possible label. It would be beneficial, and possibly necessary, to create the System High level such that it is hierarchically higher than all the data levels used in the system. This approach has the benefit that the mandatory access controls provide additional protections for the audit data since only the Auditor would have authorization for this level.
Access to the audit databases may be performed only by individuals who can assume the Auditor role, using the commands defined for that role. 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 should be able to change the authorization of his processes between System 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 security labels in the system. In a sense, it is the lowest possible label.
The (security-relevant) functions of the Operator are defined below. Specifically, the Operator:
5.6. FUNCTIONS OF THE SYSTEM PROGRAMMER
The functions of the System Programmer role are the most security-sensitive functions of the system. They may affect the TCB configuration, distribution and maintenance. These functions are not necessarily audited and, thus, any error, omission, or malicious act, which affects the security of the entire system, may remain undetected. (However, some form of auditing, possibly off-line, is still necessary in some environments. Multiple Systems Programmers checking each others' actions may also be required in some environments for the execution of the System Programmer functions. Furthermore, a two-person rule may be instituted or built into the login procedure requiring that a System Programmer may not log in successfully unless another System Programmer is also logging in). Thus, the System Programmer functions should have the highest degree of trust in the system. The System Programmer functions may include the following:
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 imported 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 security level higher than his maximum clearance. All the Analyst's 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 databases.
5.8. RELATIONSHIP AMONG ADMINISTRATIVE ROLES
The fine-grained separation of administrative roles defined above permits the establishment of a hierarchical relationship among 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 role to change the attributes of objects and security profiles of users in other roles and, if necessary, to log in and take actions in that role.
Object attributes include:
Profile attributes include:
The above notion of role dominance can be useful because it provides both a measure of necessary trust (based on skills, on checking administrative users' background and interests, etc.) that should be invested in a role and a measure of vulnerability associated with that role. The most privileged role is that of the System Programmer. It dominates all other roles in the system and, consequently, it exhibits the highest degree of vulnerability. The Auditor role should be strictly separated from all other remaining roles defined in the system because it maintains sensitive information describing the behavior of all users, including the administrative ones. The Security Administrator dominates the Secure Operator, Account Administrator, Analyst, and user roles; however, the dominated roles are separated from each other. It must be 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 role. Figure 4 illustrates the relationship among the administrative roles defined above. The system could provide a "flat" set of roles, 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  and the Clark-Wilson model , could be used to guide the design of the above-mentioned roles and hierarchical relationships, as discussed below.
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 requirements or may choose to implement new protection mechanisms and policies. For example, the implementors of Security Administrator 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 same role, or with nonadministrative trusted processes. For example, the security label map file is private to the Security Administrator role, the audit log and the postprocessing audit files are private to the Auditor role, and the accounting files are private to the Account Administrator role. All such files are shared among all users of the same role. Other files, such as those containing the user and group registration, may be shared between processes of different roles. These files may be read and written by Security Administrator processes, and are read by Auditor, 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 which they would create and maintain private files (those not shared with others in the same role). Furthermore, other files are shared between processes of an administrative role and nonadministrative trusted processes. For example, the user password file is read and written by the 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 implementing role functions, which need to read and write files at all security levels (e.g., Accounting, Auditor, and Secure Operator processes), would need to bypass the mandatory access controls at least 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 specific programs implementing administrative functions with roles may require the implementation of restricted command processors, of restricted groups that cannot be modified by the Security Administrator, or of other more complex integrity mechanisms (discussed below). In all such cases, the design and implementation of trusted facility management functions should follow existing guidelines (see example,).
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 since any user can take the identity of other users of the same role and 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 processes that belong to their role, and that no other users or processes 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 design of a full (i.e., B3-A1) trusted-path mechanism.
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, ).
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 implementation of the trusted facility management functions.
6.3.1. Operational Assurance
The only relevant areas of operational assurance are the system architecture and the trusted recovery areas. The covert channel analysis area is not relevant here because (1) all users in security-relevant administrative roles have been screened for this position of trust and are therefore expected not to disclose information in 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 hardware and firmware operation.
The system architecture requirements impose major constraints on the design of trusted facility management. Because all the security-relevant and accountability functions of the administrative roles are part of a system's TCB, all requirements of TCB interface definition apply to the administrative interfaces. Similarly, all requirements of internal TCB structuring, such as those of modularity, abstraction, information 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 design of trusted processes is also required of the administrative processes of the TCB. Several specific design requirements should be observed here. First, the protection of the administrative databases should be performed at the granularity of individual files (or segments) 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 include 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 design alternatives are available in this area. For example, certain files should be associated only with certain processes. Privileged TCB calls, which can be represented by ring-gate descriptors [15,19], domain-entry capabilities , or per-process privilege vectors corresponding to specific calls [16,14], should be associated with processes only on an "as needed" basis. These associations can be 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 :
6.3.2. Life-Cycle Assurance
Most life-cycle assurance requirements apply to the processes and interfaces of trusted facility management as stated. For example, security testing, configuration management, and trusted distribution requirements of the TCB apply to trusted facility management to the degree of rigor commensurate with the chosen evaluation class. This is the case because the TCB code and interfaces include the security-relevant code and interfaces of trusted facility management.
In contrast, only some of the requirements of the design specification and verification area apply to the trusted facility management directly. For example, the need for accurate DTLSs for the TCB interfaces 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 design specification and verification area would apply to trusted facility management directly.
The documentation requirements of the TCSEC relevant to the trusted facility management area are the trusted facility manual requirements in section 3, the test documentation requirements, and some of the design documentation . In the design documentation area, only the requirements referring to the DTLSs, TCB internal structuring, and enforcement of the least privilege principle are relevant.
A specific type of interaction between a subject and an object that results in the flow of information from one to the other.
An administrative role or user assigned to maintain accounting files, tools, user accounts, and system statistics.
A user assigned to supervise all or a portion of an AIS.
See Administrative User.
The official authorization that is granted to an AIS 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 implementation and of the other system procedural, administrative, physical, TEMPEST, personnel, and communications security controls.
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.
The processes used to collect, review, and/or examine system activities.
Processing, under the control of authorized personnel, of specified events that had been recorded on the 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 a transaction from its inception to final results.
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.
An authorized individual, or role, with administrative duties, which include selecting the events to be audited on the system, setting up the audit parameters which enable the recording of those events, and analyzing the trail of audit events.
A user who has accessed an AIS with a valid identifier and authentication combination.
Automated Information System (AIS)
An assembly of computer hardware, software and/or firmware configured to collect, create, communicate, compute, disseminate, process, store, and/or control data or information.
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.
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.
An information transfer path within a system. May also refer to the mechanism by which the path is effected.
A communication channel that allows a process to transfer information 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 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., CPU time) in such a way that this manipulation affects the real response time observed by the second process.
Information with a specific physical representation.
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 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 must represent the initial state of a system, the way in which the system progresses from one state to another, and a definition of a "secure" state of the system. To be acceptable as a basis for a TCB, the model must be supported by a formal proof that if the initial state of the system satisfies the definition of a "secure" state and if all assumptions required by the model hold, then all future states of the system will be secure. Some formal modeling techniques include: state transition models, temporal logic models, denotational semantics models, 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.
The segment of security testing in which the advertised features of a system are tested, under operational conditions, for correct operation.
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 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.
A device that is used in a manner that permits it to process data simultaneously 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.
A class of system containing information with different sensitivities that simultaneously permits access by users with different security clearances and needs-to-know, but prevents users from obtaining access to information for which they lack authorization.
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, network nodes, etc.
The unique name that identifies and distinguishes a particular object from all other objects in a system. In a hierarchical file system, the object-unique name includes the associated directory names so users can use the same name for objects in different directories.
An administrative role or user assigned to perform routine maintenance operations of the AIS and to respond to routine user requests.
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.
A fundamental operation that results only in the flow of information from an object to a subject.
Read Access (Read Privilege)
Permission to read information.
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 label of a newly mount ed tape).
An administrative role (or user) responsible for the security of an Automated Information System and having the authority to 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 Administrator.
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).
The combination of a hierarchical classification and a set of nonhierarchical categories that represents the sensitivity of information.
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 how a system manages, protects, and distributes sensitive information.
Any event that attempts to change the security state of the system, (e.g., change discretionary access controls, change the security level of the subject, change user password, etc.). Also, any 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.).
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.
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 something.
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, programs, and interfaces implementing those functions, such that malicious or erroneous code in one function is prevented from affecting the code or data of another function.
An attempt to gain access to a system by posing as an authorized user. Also called masquerading or mimicking.
An active entity, generally in the form of a person, process, or device that causes information to flow among objects or changes the system state. Technically, a process/domain pair.
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 security level must always be dominated by the clearance of its associated user.
See Security Administrator.
The security label that dominates all other security labels in the system. In a sense, it is the highest possible label.
The lowest security level supported by a system at a particular time or in a particular environment.
An administrative role (or user) responsible for trusted system distribution, configuration, installation, and nonroutine maintenance.
Top-Level Specification (TLS)
A nonprocedural description of system behavior at the most abstract level; typically, a functional specification that omits all implementation details.
A hidden software or hardware mechanism that can be triggered to permit system protection mechanisms to be circumvented. It is activated in some innocent-appearing manner; e.g., a special "random" key sequence at a terminal. Software developers often introduce trap doors in their code to enable them to reenter the system and perform certain functions. Synonymous with back door.
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 or integrity.
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 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 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.
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.
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).
The process of comparing two levels of system specification for proper correspondence (e.g., security policy model with top-level specification, top-level specification with source code, or source code with object code). This process may or may not be automated.
A self-propagating Trojan horse, composed of a mission component, a trigger component, and a self-propagating component.
A weakness in system security procedures, system design, implementation, internal controls, etc., that could be exploited to violate system security policy.
A fundamental operation that results only in the flow of information from a subject to an object.
Write Access (Write Privilege)
Permission to write an object.