Trusted Computer System Evaluation Criteria

With the National Computer Security Center (NCSC) of the National Security Agency (NSA), the US Government sets standards for trusted systems and performs evaluations of systems submitted by vendors. During the evaluation process, the systems are subjected to detailed analysis and testing of both operational features and security features.

The Department of Defense's Trusted Computer System Evaluation Criteria (TCSEC) describes a graded classification of trusted systems (levels A, B, C, and D) and specifies the criteria that distinguishes each class. Each class offers increased security features so that level D is the least strict and level A assures maximum, verified protection.

Systems are evaluated using the criteria specified in the TCSEC. Based on the result of the evaluation, a system earns an overall rating showing the degree of trust that can be placed in the evaluated system.

The TCSEC defines two types of requirements for each of the classes defined: features and assurance. These requirements have to be addressed during the design, implementation, and testing of a trusted system.

Features are visible functions that carry out the security policy of a system.
Assurances are tasks that the system implementor must complete to guarantee that the system meets specifications.

HP-UX complies with (and in many instances exceeds) the TCSEC requirements for the C2 class. Table 1-1 “TCSEC C2-Level System Features” summarizes the TSCEC features and assurances that must be satisfied by a C2-level trusted system. The sections that follow describe each of these requirements in greater detail and summarize the impact of these requirements on administrator responsibilities.

Table 1-1 TCSEC C2-Level System Features

Requirement	Description
Discretionary access control (DAC)	An owner of an object containing data must be able to allow or deny access to that object based on a need-to-know basis.
Object reuse	When an object is initially assigned, allocated, or reallocated to a subject, that object must not contain any data that the subject is not authorized to access.
Identification and authentication	Individuals must identify themselves to the system to use it, and the system must be able to authenticate users' identities.
Audit	Users must be accountable for their actions. The system records an audit trail of each security-related event and who caused the event.
System architecture	The system must isolate areas that require protection via access control and auditing.
System integrity	The system needs to include features that allow periodic validation of the hardware and firmware.

Discretionary Access Control

Using discretionary access control (DAC), owners of objects containing data can allow or deny access to these objects at their own discretion, on a need- to-know basis. Objects are things such as files, devices, or interprocess communications mechanisms that another user or the user's process is attempting to access.

Users of standard HP-UX systems protect objects, such as files, by establishing read, write, and access permissions to these objects. The owner can set permissions on objects so that the owner of the object is allowed different accesses from other group members; group members can have different access to an object than the rest of the user community. The owner can change these protection attributes so they are more restrictive (controlled access) or more permissive (open access).

The TCSEC requires the C2-level of trust to have discretionary controls on an object that are capable of including or excluding access to the granularity of a single user. In other words, the owner of a file must be able to specify that one user is authorized to access a file in a certain way, or that one user is denied access to a file while all others are allowed access.

Access control lists (called ACLs), used with standard HP-UX protections make it possible to define a highly customized access to specify objects. The ACL of an object contains entries that control types of access permitted. Individual users create and maintain ACLs at their own discretion using the chacl(1), lsacl(1), and getaccess(1) commands.

For more information on ACLs, refer to the chacl(1), lsacl(1), and getaccess(1) man pages and to "Managing Access to Files and Directories" in Chapter 12 of HP-UX System Administration Tasks.

Object Reuse

The system ensures that an object that is assigned, allocated, or reallocated does not contain data (from a previous use) that the new user is not authorized to access. Object reuse security prevents information from being disclosed inadvertently when storage is released by one user and made available to another.

The C2-level of trusted HP-UX uses standard HP-UX mechanisms to clear newly allocated disk blocks and memory pages. It extends standard mechanisms for authentication to clear buffers containing passwords immediately after they are encrypted.

Identification and Authentication

The TCSEC requires users to identify themselves to the TCB before performing any actions that the TCB must mediate. The TCB will maintain data to verify the identity of individual users, thus authenticating each user. Stringent identification and authentication requirements are necessary on a trusted system. The purpose of these requirements is to ensure users are held accountable for their actions.

On a standard HP-UX system, the user logs in by entering a user name and password. The system searches /etc/passwd for the user name and authenticates the user by comparing the entered password with the encrypted version of the password in /etc/passwd. HP-UX includes more stringent password authentication through a password management mechanism that is designed to meet the objectives and recommendations of the DoD Password Management Guideline, CSC-STD-002-85. Several security databases protect and control the following:

Passwords
Terminal access
System defaults
Device assignments

You and the entire administrative staff must take responsibility for maintaining the authentication information stored by the system for each user. Tasks include creating new user accounts and changing account information as users enter and leave the HP-UX system.

Audit

In a trusted system, all users are held accountable for their actions. That is, any security-relevant action must be traceable to a particular responsible user. Some features of standard HP-UX make accountability difficult because some actions (such as those performed by pseudo-user accounts like lp or cron) cannot be traced to a specific user.

The HP-UX C2-level auditing subsystem logs security-related events to ensure user accountability. An audit trail records security-relevant events, such as instances of access by subjects to objects, and allows detection of any attempts to bypass the protection mechanism. You can examine the audit trail to identify the users responsible for system changes. You can also selectively audit the actions of any user.

You must perform the following tasks for auditing maintenance:

Configure the audit subsystem and control the events and users that are audited
Set auditing parameters appropriately for reliable, efficient performance.
Determine how much information to collect in the audit trail and maintain the information once it has been collected
Analyze the audit trail to monitor system activities.

You can administer the auditing subsystem in two ways:

Using the "Auditing and Security" window in sam(1M), the System Administration Manager. Only the character version of sam(1M) can be used.
Using several HP-UX commands including audsys(1M), audusr(1M), audevent(1M), audisp(1M), and audomon(1M).

In summary, the auditing subsystem acts as a deterrent against system abuses and exposes potential security weaknesses in the system. However, it is still your responsibility as the system administrator to turn on auditing, monitor appropriate system activities, detect, and report any unauthorized or suspect activity.

System Architecture

The system needs to be organized in such a way that the areas requiring protection can be isolated from the rest of the system. In this way, access to these areas can be controlled, monitored, audited, and protected from unauthorized access.

System Integrity

The enforcement of security must be extended to system hardware and software features so that correct operation of the system can be verified. This provides an assurance that the security policy is implemented correctly and that the system security features accurately enforce the control objectives.