When you create your own audit class, you can place into it just those audit events that you want to audit for your site. This strategy can reduce the number of records that are collected and reduce noise in your audit trail.
When you add the class on one system, copy the change to all systems that are being audited. Best practice is to create audit classes before the first users log in.
For information about the effects of modifying an audit configuration file, see Audit Configuration Files and Packaging.
Before You Begin
Choose free bits in the upper 8 bits for your unique entry. Verify which bits are available for customer use in the /etc/security/audit_class file.
You must become an administrator who is assigned the solaris.admin.edit/etc/security/audit_class authorization. By default, only the root role has this authorization. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.
# cp /etc/security/audit_class /etc/security/audit_class.orig
Each entry has the following format:
For a description of the fields, see the audit_class(4) man page. For the list of existing classes, read the /etc/security/audit_class file.
This example creates a class to hold administrative commands that are executed in a role. The added entry to the audit_class file is as follows:
The entry creates the new pf audit class. Example 16, Mapping Existing Audit Events to a New Class shows how to populate the new audit class.
If you have customized the audit_class file, make sure that any audit flags that are assigned directly to users or rights profiles are consistent with the new audit classes. Errors occur when an audit_flags value is not a subset of the audit_class file.