What to audit, when to audit it, and where to store the files are factors to consider when enforcing your site's security goals while auditing more efficiently. For example, you might try:
Random auditing of only a certain percentage of users at any one time.
Real-time monitoring of the audit data for unusual behaviors. (You set up procedures to monitor the audit trail as it is generated for certain activities and to trigger higher levels of auditing of particular users or workstations when suspicious events occur.) See "To Read a Current Audit File" for an example.
Setting the public object flag on publicly accessible files or directories. This reduces the potential size of the audit trail while not compromising security, because the viewing of publicly accessible files and directories is not generally interesting for audit purposes. Files so marked do not generate audit records for the following audit events, even if the classes for those events are turned on for auditing:
AUE_ACCESS, AUE_STAT, AUE_LSTAT, AUE_READLINK, AUE_STATFS, AUE_FSTATFS, AUE_PATHCONF, AUE_OPEN_R, AUE_FGETCMWLABEL, AUE_GETCMWFSRANGE, AUE_GETCMWLABEL, AUE_GETFILEPRIV, AUE_LGETCMWLABEL, AUE_GETMLDADORN, AUE_GETSLDNAME, AUE_OSTAT, AUE_FUSERS, AUE_STATVFS, AUE_XSTAT, and AUE_LXSTAT. The list may not be exhaustive.
See "To Set Public Object Bit on Publicly Accessible Files" for the procedure.
Reducing the disk-storage requirements for audit files by combining, reducing, and compressing them (see "To Combine Selected Audit Files "), and developing procedures for storing them offline.