Trusted Solaris Audit Administration

Planning What to Audit

Trusted Solaris 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 Appendix A, Event-to-Class Mappings for a list of provided audit classes. The list shows per audit class, each audit event's corresponding system call or user command, and points you 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 system. 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 Steps Step 1 and Step 2 for the other audit classes for the class na.

The decisions you have made in Steps Step 3 and Step 4 you will enter in the audit_control file when establishing auditing on the first workstation.

To audit these events, you will enter their flag on the flags: line of the audit_control file, just as you entered the na flag in the naflags: line.

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.

Be consistent.

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

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

All workstations in a Trusted Solaris network should have identical audit_user files.

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). For a discussion of the costs, see "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.