Trusted Solaris Audit Administration

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.

  1. 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.

  2. 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

  3. 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.


  4. 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.

  5. 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.

  6. 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.