Trusted Solaris Audit Administration

Planning Auditing at Your Site

When the system administrator and security administrator configure the first system for the Trusted Solaris operating environment, auditing is enabled and a limited number of audit records are collected to a default audit location, system_name:/var/audit. The security administrator needs to plan what to audit and whether to customize site-specific event-to-class mappings. The system administrator plans disk space (local and remote) for the audit files, an audit administration server, and the order of installation.

Planning auditing for a non-networked system is a bit simpler. For a single system, customizing event-to-class mappings may not be worth the time. Your most important task is to ensure that auditing does not slow down your work. Planning the size and locations of auditing partitions can prevent work slowdown, and a regular maintenance schedule can automatically back up and free up the audit partition for more audit records.

Planning What to Audit

Trusted Solaris auditing collects user actions and non-attributable (in the class na, non-attribute) events into audit classes. It is these audit classes, each of which holds a number of events, that are audited for success, for failure, or for both.

Before configuring auditing, understand the audit flags and the types of events they flag. Develop a philosophy of auditing for your organization that is based on the amount of security your site requires and the types of users you administer.

Unless the process audit preselection mask is modified dynamically, the audit characteristics in place when a user logs in are inherited by all processes during the login session, and, unless the databases are modified, the process preselection mask applies in all subsequent login sessions.

See Audit Events Listed by Audit Class for a list of provided audit classes. Each audit class is listed in its own table, where each audit event's corresponding system call or user command points to its audit record format.

The security administrator plans what to audit based on the site security policy. You can configure a system-wide setup and user exceptions/additions.

Decide if non-attributable events should be audited.

The audit flag na represents the non-attributable class of events. For example, accessing the PROM, booting, and remote mounting are non-attributable events. See Events in Audit Class na for a list of the events in the default non-attribute class.

When you audit a class, you audit all events in that class. If you want to customize the non-attributable class, see Planning a Site-Specific Event-to-Class Mapping.

To audit non-attributable events, you will enter the na flag on the naflags: line of the audit_control file.

Decide whether to audit them for success, for failure, or for both.

To audit non-attributable events for success, the naflags: line of the audit_control file would look like:
```
naflags:+na
```
To audit non-attributable events for failure:
```
naflags:-na
```
To audit non-attributable events for both:
```
naflags:na
```

Decide if all events will be audited.

Note –
The class all includes all auditable events in the Trusted Solaris software environment. While unusual circumstances may dictate use of this class, typically you would avoid auditing all events.

If you are not going to audit all events, repeat Step 1 and Step 2 for the other audit classes as you did for the class na.

You enter your auditing decisions in the audit_control file when establishing auditing on the first system. The na flag goes on the naflags: line. All other class flags go on the the flags: line of the audit_control file.

Determine if there are particular users or roles that should be audited slightly differently than the system-wide setup.

You will enter user exceptions to the system setup in the audit_user file. In the Trusted Solaris 8 4/01 release, the security administrator does not edit the audit_user file directly. The Audit tab on a user's account in the Solaris Management Console (SMC) handles each user's audit flags as part of the account. The SMC distributes the user information using the site's name service.

Be consistent.

All hosts in a Trusted Solaris network should have identical naflags: entries in their audit_control files.

All hosts in a Trusted Solaris network should have identical flags: entries in their audit_control files.

All hosts in a Trusted Solaris network should have identical audit_user files. The Solaris Management Console will distribute user audit information using the site's name service.

Considerations When Planning What to Audit

What is audited at your site is based on your site policy and the costs of auditing (time, efficiency, disk space), as discussed in Controlling Audit Costs . The following are factors to consider when using auditing as it is implemented in the Trusted Solaris environment.

Every audit record stands alone, so records can quickly fill up disk space.

Therefore, you might want to start with a small amount of auditing and see how the audit partitions fill. You can then make more educated estimates of disk requirements and an audit archiving schedule. You can refine audit classes as you get an estimate of the size of the audit trail.
The number of events in an audit class does not necessarily correlate to how many records are generated.

For example, the file read class contains about the same number of events as the login or logout class. Enabling the file read class for success is likely to generate many more records than enabling the login or logout class for success.
Auditing for failure locates abnormal events; auditing for success monitors system use.

If site policy requires monitoring of system use, you will want to set aside more space for the audit trail than if you are auditing for abnormal events.
Auditing for failure may generate many fewer records than auditing for success.

For example, auditing for failure of file read events in a Trusted Solaris system of sophisticated users can generate many fewer records than turning on the file read class for success.
Configuring the audit classes differently, or setting up new audit classes for audit events can more efficiently satisfy your site requirements. By excluding audit events that site policy does not require to be audited, the audit trail is smaller.

For example, you may want to create a class de for devices. When configuring devices, audit the class for success to generate a record of what devices have been set up and tested. When all devices have been configured, you may want to audit the class for failure.
Configuring some classes to be audited intermittently may satisfy your site requirements.

For example, you may want to audit the audit class you created, de, intermittently. A cron job, or the command auditconfig(1M), enable you to turn auditing on and off for particular classes and set other audit flags dynamically.

Planning a Site-Specific Event-to-Class Mapping

Optional: Skip this section if you are using the default event-to-class mappings provided in the Trusted Solaris environment. Do not skip this section if you have decided to rearrange what events are assigned to what classes, or to create new classes or new events.

Trusted Solaris software handles up to 32 audit classes, including the class all. Your site may add classes until the total number is 32.

The security administrator plans site-specific mappings. To plan site-specific mappings:

Decide what classes are needed.

Decide what events belong in what classes.
1. Decide what events should be copied to another class or classes.
  
  An audit event can belong to more than one class. For example, the audit event AUE_RENAME belongs to the classes file create and file delete in the default event-to-class mapping.
2. Decide what events should be moved to another class or classes.
3. Decide what events should be added to a class or classes.

For each class, decide whether to audit it for success, for failure, or for both.

When new software programs include audit events not provided by Trusted Solaris software, add the events to existing classes or create a new classes for the new events.

Considerations When Changing Event-to-Class Mappings

The following are factors to consider when changing the contents of default audit classes and creating new ones in the Trusted Solaris environment.

This document, Trusted Solaris Audit Administration, reports the default auditing configuration.

Document your site's modifications to the auditing defaults, and make the document available to the administrators handling audit administration.
If you are networked, you must change the auditing configuration files on all the systems when you change the files on one system.

A network of Trusted Solaris systems should behave like one system. When auditing is enabled, it should be enabled on every host, and every host should be audited for the same classes, with the same defaults, the same user exceptions, and the same event-to-class mappings as every other Trusted Solaris host in the network.

Planning Space on a Non-Networked Systems

Storing audit records on a non-networked system involves setting up at least two local partitions dedicated to audit records, one primary and one backup, and planning a maintenance schedule.

On a non-networked system, plan the size of a disk partition to hold audit records. For efficiency, it is best to place the audit records on a separate disk. For safety, you may want to create two audit partitions on that disk, one as the primary storage area and the other as a backup when the first partition gets full. Set filesystem security attributes to set on the audit directory to prevent snooping on the audit trail.

Estimate the volume of auditing between audit record backups.

Balance your security needs against the availability of disk space for audit trail storage.

A rule of thumb is to assign 200 MB of space per system. However, the disk space requirements for the system are based on how much auditing you perform and may be far greater than this figure.

Controlling Audit Costs and Auditing Efficiently provide guidance on how to reduce storage requirements.

Decide at what point the audit file system sends a warning that it is filling up.

You will specify what is called the minfree limit for audit partitions in the audit_control file. This is the percentage of disk space remaining when the audit administrator is sent an email message (by the audit_warn alias) that the disk is getting full. The default is to send the warning when there is 20% disk space remaining. This percentage is tunable.

Planning Space on a Network of Hosts

Storing audit records for a network of hosts involves setting up a local (backup) partition dedicated to audit records, plus a network of audit servers with partitions for remote (primary) audit storage, and plus an audit administration server from which the entire audit trail can be monitored. The audit trail is every audit file (audit files hold audit records generated on a system) created by every system on the network.

A networked system should include audit servers to store audit files for users' systems, an audit administration server for central audit analysis and backup, and a local audit partition on every host. You may want to set filesystem security attributes on the directories and mount points to prevent snooping on the audit trail. Create a worksheet to record your auditing plan, or use another mechanism that helps you track the auditing network that you set up.

Determine how much auditing your site needs to do.

Balance your site's security needs against the availability of disk space for audit trail storage.

A rule of thumb is to assign 200 MB of space for each host that will be on the distributed system, but remember that the disk space requirements at your site is based on how much auditing you perform and may be far greater than this figure per host. If you are able to dedicate a local and a remote disk for auditing, one way to set up audit partitions is to divide each disk into two partitions.

Controlling Audit Costs and Auditing Efficiently provide guidance on how to reduce storage requirements while still maintaining site security.

Decide at what point each audit file system for the system sends a warning that it is filling up.

You will specify what is called the minfree limit for audit partitions in the audit_control file. This is the percentage of disk space remaining when the audit administrator is sent an email message (by the audit_warn alias) that the disk is getting full. The default is to send the warning when there is 20% disk space remaining. This percentage is tunable.

Determine which hosts will be audit servers.

The install team will install these systems before installing the audit client systems.

Plan a local audit partition for each system.

The local partition provides a backup in cases where the audit server's partitions are full or when the network is unreachable.

Determine which clients will use which audit file systems on which audit server.

Lay out the auditing network. The following figure shows an audit server, egret, with file systems /etc/security/audit/egret[.n]/files available to store remote hosts' audit records.

Figure 2–1 Audit Server egret's Audit File Systems

Follow the naming conventions for audit file systems.

As illustrated in the figure, the convention for naming the audit file systems on a system is:
```
/etc/security/audit/system_name/files
/etc/security/audit/system_name.1/files
/etc/security/audit/system_name.2/files
/etc/security/audit/system_name.3/files …
```
For an explanation of the naming scheme, see Audit Storage.

Planning the Rollout

Rolling out the auditing plan to the systems is a job coordinated by the system administrator, who sets up the disks and the network of audit storage, and the security administrator, who decides what is to be audited and enters the information in the audit configuration files. Together, you want to set up an audited network of systems where:

From one host, the audit analyst is able to read every audit file on every host in the network, and the system operator is able to back up every audit file on every host on the network.

How: Create an administration server, and mount all audit directories on the server.
The audit trail is not available for snooping.

How: Protect audit directories with appropriate discretionary access controls and mandatory access controls. You may want to audit directory access.
Each host in a Trusted Solaris distributed system is writing records to the audit trail from the first time it is in multiuser mode, and thereafter.

How: Create audit servers before you create user systems. On all systems, create a dedicated audit partition during installation.
Every system is audited identically.

How: Create a central location for all audit configuration files that are not controlled by the Solaris Management Console: audit_event, audit_class, audit_control, audit_startup, and audit_warn. The examples use the directory /export/home/tmp on the NIS+ master. Copy these files to a tape or diskette that is copied to every system.
When an end user's system is configured, it is able to immediately send its audit records to an audit server.

How: Create the audit servers and configure them for receiving audit records before the end user systems are set up. Create a procedure to copy the system-wide audit configuration files to each host and to modify the audit_control file for the audit storage locations for that host.
End user's systems are not slowed down by writing audit records.

How: Regular archiving of the audit trail frees up audit server disk space. Placing the local audit storage on a separate or little-used disk will enable the end user to work quickly when audit records are stored locally.