Planning and Setting Up Auditing

Before you set up auditing for your site, you need to:

• Decide which classes of events to audit, including any new classes or events you wish to add to your site.

• Plan where to store the auditing information.

• Define the audit configuration files.

Audit Classes

You need to decide which events you want to audit. You can capture user actions or non-attributable events (that is, events such as interrupts which cannot be attributed to specific users). For the user actions, you can separate successful and failed transactions. Auditing events are organized into classes in Trusted Solaris. The auditing classes for files fall into these general areas:

• Open for reading

• Open for writing

• Attribute changes

• Creations

• Deletions

You can also create your own classes and events as needed and can rearrange the mapping of classes to events. Other classes keep track of such items as process operations, network events, window operations, IPC operations, administrative actions, logins, logouts, application-defined events, ioctl system calls, program executions, Xserver operations, and miscellaneous events. Because auditing information can take up a lot of disk space, you need to decide carefully which events to auditand select only the classes that contain events necessary for your site's security policy.

Public Objects

One way to reduce the amount of auditing information collected is to specify certain files and directories to be public objects. A public object typically contains read-only information, is not modifiable by normal users, and has no implications on security, eliminating the need to track who accesses the object. The system clock is a good example of a public object. When you set the public object flag, any other auditing flags specifying the object are ignored.

Audit Information Storage

The large amount of disk space needed for auditing requires that you plan carefully where the information is going will be collected.

If your site uses individual non-networked workstations, it is recommended that each workstation have a dedicated disk for audit records. The dedicated disk should have at least two partitions:

• a primary storage area

• a partition for holding overflow records

For a network of workstations, you should dedicate at least one separate server for collecting audit information and a second server for administering and analyzing the audit data.

In any case, you should set MAC and DAC protections on the audit files and directories to preserve their integrity and prevent snooping.

Audit Configuration Files

The specifications for auditing at a site are stored in these configuration files, which reside in the /etc/security subdirectory:

• audit_control(4)--stores audit control information used by the audit daemon, including the preferred order of directories where audit information is stored (the audit daemon uses a directory until the minimum free space warning limit is reached, at which point it stores audit records in the next directory in the list), minimum free space warning limit, system-wide audit flags indicating classes to be audited, and special audit flags for events that cannot be attributed to specific users. The audit flags set in this file are applied to all users. Any exceptions to these flags are set on a per-user basis and specified in the audit_user file, which is modified using the User Accounts tool in SMC.

• audit_user(4)--stores auditing criteria for users who are exceptions to the auditing specifications in audit_control. This information includes user name, events that are always to be audited, and events that are never to be audited.

• audit_class(4)--stores audit class definitions, including the class mask (that is, the filter that determines which classes are to be tracked), class name, and description.

• audit_event(4)--stores audit event information, including event number, event name, description, and audit flags identifying the audit class.

If you are setting up auditing for a network, there must be identical versions of the audit_class, and audit_event files on each workstation. Use the SMC to update the audit_user site-wide NIS maps and NIS+ tables..