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.
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.
Decide what events should be moved to another class or classes.
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.
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.