Managing Auditing in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014

How to Plan Who and What to Audit

Before You Begin

If you are implementing non-global zones, review Planning Auditing in Zones before using this procedure.

  1. Determine the audit policy.

    By default, only the cnt policy is enabled.

  2. Determine whether you want to modify event-to-class mappings.

    In almost all situations, the default mapping is sufficient. However, if you add new classes, change class definitions, or determine that a record of a specific system call is not useful, you might want to modify event-to-class mappings.

    For an example, see How to Change an Audit Event's Class Membership.

  3. Determine which audit classes to preselect.

    The best time to add audit classes or to change the default classes is before users log in to the system.

    The audit classes that you preselect with the –setflags and –setnaflags options to the auditconfig command apply to all users and processes. You can preselect a class for success, for failure, or for both.

    For the list of audit classes, read the /etc/security/audit_class file.

  4. Determine user modifications to the system-wide preselections.

    If you decide that some users should be audited differently from the system, you can modify the audit_flags security attribute for individual users or for a rights profile. The user preselection mask is modified for users whose audit flags are explicitly set or who are assigned a rights profile with explicit audit flags.

    For the procedure, see How to Configure a User's Audit Characteristics. For which audit flag values are in effect, see Order of Search for Assigned Rights in Securing Users and Processes in Oracle Solaris 11.2 .

  5. Decide how to manage the audit_warn email alias.

    The audit_warn script is run whenever the audit system detects a situation that requires administrative attention. By default, the audit_warn script sends email to an audit_warn alias and sends a message to the console.

    To set up the alias, see How to Configure the audit_warn Email Alias.

  6. Decide in which format and where to collect audit records.
  7. Determine when to warn the administrator about shrinking disk space.

    Note -  This step applies only to the audit_binfile plugin.

    When disk space on an audit file system drops below the minimum free space percentage, or soft limit, the audit service switches to the next available audit directory. The service then sends a warning that the soft limit has been exceeded.

    To see how to set a minimum free space percentage, see Example 4–7.

  8. Decide what action to take when all the audit directories are full.

    Note -  This step applies only to the audit_binfile plugin.

    In the default configuration, the audit_binfile plugin is active and the –cnt policy is set. In this configuration, when the kernel audit queue is full, the system continues to work. The system counts the audit records that are dropped but does not record the events. For greater security, you can disable the –cnt policy and enable the –ahlt policy. The –ahlt policy stops the system when an asynchronous event cannot be placed in the audit queue.

    However, if the audit_binfile queue is full, and the queue for another active plugin is not full, then the kernel queue will continue to send records to the plugin that is not full. When the audit_binfile queue can again accept records, the audit service will resume sending records to it.

    For a discussion of the –cnt and –ahlt policy options, see Audit Policies for Asynchronous and Synchronous Events. To see how to configure these policy options, see Example 3–10.

    Note -  The –cnt or –ahlt policy is not triggered if the queue for at least one plugin is accepting audit records.