Chapter 2. Planning Your System Security Policy

Before you begin general use of your system, define your needs and examine and classify the various types of information and applications that will reside on your system. Although it is always possible to reconfigure your system resources and practices, your installation will benefit from planning. A “dry run” of your trusted system is often beneficial before classified data and users are allowed access.

This chapter covers the planning necessary to ensure a trouble-free and efficient trusted system implementation. If you do not plan your system, you are likely to forget to implement some necessary security policies or labels. While the system is fully configurable at any time, it is inconvenient to have to search through your system and fix existing files and user accounts. Time spent in planning will be much shorter than time spent in repairing and updating.

Planning Your Administrative Accounts

An important difference between the Commercial Security Pak and earlier IRIX product offerings is the capabilities mechanism. This mechanism provides the Site Security Officer with the ability to configure the system so that the Superuser powers are divided and distributed among several individuals.

This represents a significant departure from traditional UNIX system administration practice. Because you can configure the system to have no omnipotent Superuser, administrative habits may have to be changed to accommodate the stricter controls. Dividing the traditional Superuser into a set of administrative accounts does not make system administration simpler. Several people must be well trusted, though no one need be trusted absolutely with the integrity of the system.

One case where the complexity is evident is the creation of new user accounts. The System Administrator is responsible for maintaining the /etc/passwd file, but does not maintain the /etc/capability or /etc/shadow files.

The administrative accounts are shown in Table 2-1.

Table 2-1. Commercial Security Pack Administrative Accounts

Account Name

Role

Capabilities

dbadmin

System Administrator

none

ops

Operator

none

sso

Site Security Officer

mac_read

mac_write

mac_relabel_open

mac_upgrade

mac_downgrade

dac_read_search

dac_write

fowner

setfpriv

audit_write

audit_control

kill

auditor

Auditor

audit_write

audit_control

kill

It is not uncommon for one person to have responsibility for more than one of these accounts, although it is desirable to have one person for each role. These people should also hold normal user accounts for other work. Each administrative account holds responsibility for some aspect of the system.

System Administrator

The System Administrator uses an account called dbadmin. The System Administrator is responsible for day-to-day maintenance tasks and for installing new software for the system.

The System Administrator is also responsible for maintaining the functional state of the system. This task includes, but it not limited to, maintaining these configuration database files:

/etc/aliases 

the configuration file for e-mail groups

/etc/exports 

the configuration file for directories exported using NFS™

/etc/fstab 

the configuration file for filesystems mounted both locally and via NFS

/etc/group 

the configuration file for group name-to-group ID mapping

/etc/hosts 

the configuration file for system-to-Internet address mapping

/etc/motd 

the login message file

/etc/networks 

the configuration file for network-to-Internet address mapping

/etc/passwd 

the configuration file for user name-to-user ID mapping

/etc/sendmail.cf  


the configuration file for the e-mail environment on this system

/etc/sys_id 

the file that holds the name of this system

The System Administrator is also responsible to the users for necessary assistance, services, and maintenance.

Auditor

The person responsible for reviewing the System Audit Trail is called the Auditor and uses an account named auditor. The Auditor is allowed sufficient capability to manipulate the audit trail and to terminate any process. This account and role are properly part of the duties of the Site Security Officer, and can be safely entrusted to that individual.

The Auditor reviews and analyzes the audit logs. When the Auditor finds cause to believe that a security breach has occurred, he or she should notify the Site Security Officer for action. The Auditor may choose to further process the data into a form that is appropriate for analysis and long-term storage, using the reduction tool sat_reduce(1M) and the formatting tool sat_interpret(1M) .

The Auditor should be responsible for suggesting changes to the security policies and should take the initiative in enhancing the auditing level when that action is deemed necessary.

Operator

The Operator is responsible for day-to-day system state changes. This primarily includes making backups. The Operator does not determine or maintain system policies.

Site Security Officer

The Site Security Officer is responsible primarily for initiating, monitoring, and approving changes to the system. This individual should implement the security policies. For example, the Site Security Officer should monitor and maintain the password generation and change system and ensure that all users comply with the password policy.

The Site Security Officer also checks all new programs and files for security violations before they enter the TCB. It should be noted here that sites that wish to run the security-evaluated configuration must never add any new software to the TCB, although new software can be safely added if it is not made part of the TCB. The Site Security Officer must make a determination as to whether adding a program to the TCB is worth the risk involved with having a system that no longer matches the evaluated configuration.

Superuser

IRIX supports a least privilege mechanism through the implementation of POSIX capabilities, described in the section titled “Capabilities” in Chapter 4. The Superuser privileges have been broken out into a set of distinct capabilities, which can be granted and relinquished through a set of inheritance rules. The several versions of IRIX support three capability styles.

Traditional Superuser  


In the traditional Superuser style, privilege is defined by having an effective userid of 0 (root). This style is best suited to friendly, cooperative, and open environments.

Augmented Superuser 


In the augmented Superuser style, a process with an effective user ID of 0 (root) is privileged. It is also possible to grant processes distinct capabilities, even if they do not have Superuser privilege. This style is best suited to open environments in which individuals require the ability to perform actions such as reserving system resources, rebooting the system, or setting the clock, but not some of the other powers normally associated with the Superuser, such as reading other people's mail.

No Superuser 

In the no Superuser style, an effective user ID of 0 (root) has no privilege implications. Only the presence of capabilities provides privilege.

In all cases, root is the owner of most system administrative databases. System startup is done under this user ID as well, so even if you choose the no Superuser style, do not delete the root account.

How the Administrative Accounts Work Together

When all of your administrative accounts and roles are used properly, you have created a system to guard against failure of your security policy.

For example, to add a new user, the site manager or project manager requests the new user account from the Site Security Officer. When the request is approved, the auditor, dbadmin, ops, and root are notified so that the auditing can be changed if necessary, the user's account created, and the Superuser notified of the change in system usage. The process should happen in this manner:

  1. The SSO approves the account request.

  2. The System Administrator creates the account using the System Manager.

  3. When the account is created, the System Administrator notifies the Site Security Officer of the new account. The SSO notifies the Auditor (if they are different people).

  4. The Auditor sets up any ordinary or special auditing required by the Site Security Policy.

  5. The Site Security Officer checks the work of the System Administrator and Auditor and then notifies the user that the account is open.

As another example, the same process applies when adding a new program to the TCB. The Site Security Officer reviews the program for security violations, the auditor arranges to audit the program's activity, dbadmin actually installs the approved program, and root alters the system configuration for the new program.

If a user is found in violation of the security policies or an intruder is discovered, a user or the auditor notifies the Site Security Officer, who first notifies dbadmin to lock the account or security hole and then notifies root to repair the damage to the system. The auditor also increases the auditing of the suspect or violated area to increase security.

To remove a user or finish a project, the Site Security Officer determines the changes necessary to the system configuration and instructs the other administrative users to take the appropriate action to remove the user account and to make changes to the auditing process and the system configuration.

Creating Security Policies

You must establish an overall security policy for your site, called a Site Security Policy. A security policy is a series of official statements regarding the rules for the use of the system. The purpose of the policy is to create a clear code to ensure the safe use of the system. This policy should be clearly articulated in a written document available to all users. Each person involved with the secure system should know his or her own security guidelines and responsibilities. At some sites, the security policy itself may be classified.

In 1987, the U.S. Computer Security Act mandated that secure computing sites are responsible for the integrity and confidentiality of their resources and information. Computer systems with sensitive information have long been a favorite attack point for malicious and mischievous intruders. Because of the nature of computers, intruders can do much of their work without direct contact with a human being. Damage done to computers and the information they store can come in many forms. Sometimes the damage is severe, when irreplaceable information is lost or corrupted. Sometimes the damage is a case of theft, when a business competitor seeks advance knowledge of product development. Occasionally, users themselves damage the system, either accidentally or with malice.

A total security policy has a number of segments. Among these are the physical security policy, the procedural security policy, and the system security policy. Take care to ensure that your security policies are concordant and similar in approach to one another. If possible, for consistency, the same person or group should draft all security policies. Avoid complexity in your policies; it can cause users to become confused or to circumvent policy.

Physical Security Policy

A physical security policy is simply the security measures that protect the computer hardware from damage or unauthorized access. Damage in this sense can come from intruders or from aspects of the location, such as water damage or electrical power fluctuations. All physical components of your system, such as the central processing unit (CPU), any storage media, wiring, and remote terminals need to be governed by the physical security policy. Guidelines for effective physical security are as follows:

  • Set the PROM password on your system. Instructions for this can be found in your Owner's Guide or in the IRIX Admin: System Configuration and Operation guide.

  • Keep the system physically secure at all times, such as in a locked or guarded room.

  • Restrict access to the room to those with immediate need to use the system.

  • Request that all users clear the video screen upon finishing work.

  • Maintain reasonable security against unauthorized and unrecorded entrance to the entire building or site where a trusted system is used. Such security can be in the form of keyed entry or other clear identification for authorized users.

  • Shield and protect all wiring and cables, especially network connections and terminal lines. The lines should be physically covered and unavailable. In no case should any part of the wiring be connected to unsecure systems or any area outside the secure site.

  • Keep physically secure all archive media and other data stored on magnetic media. Store it in a locked or guarded media library room. Segregate all media according to the classification of the information contained.

  • Restrict access to the media library or libraries to the System Administrator.

  • Remove, erase, or destroy obsolete data as soon as possible.

  • Shred or otherwise destroy paper output when it is no longer needed.

The most secure software is of no use if your physical hardware is vulnerable. Therefore, when you are planning your system, take note of the location of the hardware. The computer itself should be located behind locked doors, and the number of people with access to the room should be strictly limited. Only users, System Administrators, and other responsible people should be allowed in the room at any time. This security should never be relaxed. The power source for the computer should always be protected so that the computer is not subject to power surges or momentary power outages. The location of the computer should have a limited number of windows or be totally enclosed.

Beyond this, any coaxial cable connections to other computers on the secure system should be within the same restricted area. If it is necessary to connect to another computer outside the restricted area, the coaxial cable should be routed in such a manner as to avoid convenient points where the cable may be tapped by an intruder.

Peripheral hardware you attach to your system must likewise be protected from intruders. If you use a storage media device such as a cartridge tape drive, you must store the cartridge tapes after use with as much attention, if not more, to security as any other portion of the system. If a cartridge tape falls into the hands of an intruder, it is a simple matter to extract all the information onto a different system. Printers must also be closely monitored, because once information has been printed, it is available to anyone who can read it. Information import and export devices are the weakest link in your trusted system.

System (PROM) Passwords

Silicon Graphics workstations and servers support system passwords. These are also often called PROM passwords, since the firmware that supports the passwording is stored in PROM chips on the system's CPU board. It is strongly recommended that all systems make use of PROM passwords.

These passwords are demanded of the user attempting to access any part of the system while the operating system is not running. For example, with most computers, if you press the hardware reset button, the computer offers you a chance to perform system maintenance before the system reboots. Or in some cases, if you insert an installation tape or floppy disk, the system boots from that media instead of booting the usual operating system. Once this has been accomplished, it is a trivial matter for the intruder to mount the disk or disks and gain access to all your files. Since the system password is required before the system does anything but boot the usual operating system, overall security is increased.

The methods for setting the PROM password differ from system to system. To set the system password, see your system's owner's guide, or the IRIX Admin: System Configuration and Operation guide. The owner's guide can also instruct you on procedures to follow to remove the password if you forget it.

Procedural Security Policy

The procedural policy is the segment of the security policy that dictates how the system is used. It should cover the responsibilities of each administrative user, such as the Site Security Officer (sso), Auditor (auditor), System Administrator (dbadmin), and the Superuser (root), and the responsibilities of ordinary users. Guidelines for procedural policy should list decisions concerning:

  • Who may use the trusted system and what operations each person is allowed to perform. Keep the number of users as small as possible.

  • What system information is available, and through what mechanisms it is available. For example, it is wise to limit the amount of sensitive data that may be printed on paper.

  • How information is to be handled at all times.

  • How to dispose of old information. Bear in mind that technology exists to read “erased” information from magnetic media. All physical copies of sensitive information should be destroyed rather than simply erased.

  • How the system-provided security features are used. For example, you should decide how thorough the auditing of user activities must be, and how often the auditor reviews the audit logs. The responsibilities of the auditor are described later in this chapter.

  • How often and at what level system backups are to occur.

  • A procedure and schedule for storage, archiving, retrieval, and disposal of system data.

  • A procedure for retiring user accounts for discontinued users.

Procedures used at your site for day-to-day activities can make or break your system security. If procedures are followed, your system security policy is much more likely to succeed than if procedures are lax.

System Security Policy

The system security policy is closely related to both the physical security policy and the procedural security policy. It draws on both the physical and procedural policies to create a total policy for the system. Some guidelines for an effective system security policy are given below:

  • Uniquely identify all users. In no instance should a user be allowed to share an account or any identification with any other person.

  • Authenticate each login attempt with a password. Each user account must have a unique password. This password is required for every login.

  • Change each user's password frequently. Facilities exist within the Commercial Security Pak to generate sound passwords that are difficult for a potential intruder to guess or discover through systematic trial and error.

  • Authorize each user to perform only those tasks and to view only the information that he or she needs to complete his or her work, and no more. By reducing the scope of each user account, you reduce the possibility of general damage by an intruder who gains access to a single account.

  • Adequately audit each user during every login session. Determine the amount of audit recording necessary to ensure a reasonable knowledge of system activity at all times. Events such as login time, logout time, the creation, modification, and deletion of files, and the invocation of TCB programs should always be audited.

  • Educate your users, System Administrators, and those who are present at your site but who are not users of the trusted system. Everyone, not only the managers and System Administrators, can take responsibility for security.

  • Publish the security policies if possible, and make everyone at the site aware of security issues.

  • Review the security policies regularly and make necessary changes. As your system works and changes, modifications to the policy may become necessary. A breach of security may necessitate tighter controls and changes to the policy. However, excessively tight controls may deny access and encourage misuse of the system.

  • If possible, publish each change to the security policy clearly to all persons at the secure site.

  • To ensure compliance, make certain that all levels of management understand and approve each policy.

  • Assign a Site Security Officer who is the central figure responsible for security issues.

  • Keep the security policy consistent with the goals and standards of your company.

  • Do not make the security policies more rigid than necessary. A policy that is unrealistic is likely to be ignored or circumvented by unhappy users.

System security provides for the entire trusted system. The trusted system includes not only the hardware and software but each individual and the group as a whole. All of these combine to form a secure system for the safe development and storage of your sensitive information.

Planning for Users

During preinstallation planning, determine how many user accounts will be necessary for the people who will work on your system. You need to know how many users to expect and how much disk and memory space they require in order to make informed decisions regarding hardware resources.

Plan the capabilities required to access key system executable files, and which users can access those files. The users with these capabilities are those who have been selected to perform the system administration roles described in “Planning Your Administrative Accounts.” Plan Access Control Lists in working and home directories at this time as well. Information on Access Control Lists can be found in the section titled “Access Control Lists (ACLs)” in Chapter 4.

Examine your hardware at this time to determine how much disk space the users and information are likely to need. Planning adequate disk allocation at the beginning saves having to reinstall later if your system needs to grow. Include provisions for system audit requirements in system planning. The Audit Trail requires disk space. The specific amount required depends on the level of auditing configured and the amount of system activity. Audit Trail requirements are discussed in detail in Chapter 5, “Administering the System Audit Trail.”

Planning for Auditing

While you are planning your system, plan to use the System Audit Trail features effectively. Decide what kinds of events you wish to audit and how much information you wish to store. If disk space is limited, you may wish to restrict auditing to events such as file removal, attempts to access the system, and denial of service. You must also budget the time of the Auditor to review and reduce the audit log to evaluate the security status of your system.

Installation Notes

Installation of the Commercial Security Pak is similar to installing any software option. Installation instructions are found in the IRIX Admin: Software Installation and Licensing guide and in the release notes for this release.

Deactivating a System

When the time comes to deactivate a particular computer from your system, or perhaps deactivate your entire site, you should take certain steps to ensure that information is not inadvertently disclosed:

  • All magnetic media not being maintained in a secure manner must be thoroughly erased or destroyed. Except for project records and results that must be maintained, destroy all backup media and other records that might be salvaged if they were merely discarded.

  • All accounts on all systems must be thoroughly deactivated.

  • All disks on all systems must be reformatted or destroyed.