Go to main content

Managing Auditing in Oracle® Solaris 11.3

Exit Print View

Updated: April 2019
 
 

Controlling Auditing Costs

    Because auditing consumes system resources, you must control the degree of detail that is recorded. When you decide what to audit, consider the following costs of auditing:

  • Cost of increased processing time

  • Cost of analysis of audit data

If you are using the default plugin, audit_binfile, you must also consider the storage cost of audit data.

Cost of Increased Processing Time of Audit Data

The cost of increased processing time is the least significant of the costs of auditing. Auditing generally does not occur during computation-intensive tasks, such as image processing, complex calculations, and so forth. Also, if you are using the audit_binfile plugin, audit administrators can move the post-selection tasks from the audited system to systems that are dedicated to analyzing audit data. Finally, unless kernel events are preselected, the audit service has no measurable impact on system performance.

Cost of Analysis of Audit Data

The cost of analysis is roughly proportional to the amount of audit data that is collected. The cost of analysis includes the time that is required to merge and review audit records.

For records that are collected by the audit_binfile plugin, cost also includes the time that is required to archive the records and their supporting name service databases, and to keep the records in a safe place. Supporting databases include groups, hosts, and passwd.

The fewer records that you generate, the less time that is required to analyze the audit trail. The sections Cost of Storage of Audit Data and Auditing Efficiently describe ways to audit efficiently. Efficient auditing reduces the amount of audit data while still providing enough coverage to achieve your site's security goals.

Cost of Storage of Audit Data

    If you are using the audit_binfile plugin, storage cost is the most significant cost of auditing. The amount of audit data depends on the following:

  • Number of users

  • Number of systems

  • Amount of use

  • Degree of traceability and accountability that is required

    Because these factors vary from site to site, no formula can predetermine the amount of disk space to set aside for audit data storage. Use the following information as a guide:

  • Understand the audit classes

    Before you configure auditing, you should understand the types of events that the classes contain. You can change the audit event-class mappings to optimize audit record collection.

  • Preselect audit classes judiciously to reduce the volume of records that are generated.

    Full auditing, that is, with the –all class, fills disk space quickly. Even a simple task such as compiling a program could generate a large audit file. A program of modest size could generate thousands of audit records in less than a minute.

    For example, by omitting the –file_read audit class, fr, you can significantly reduce audit volume. By choosing to audit for failed operations only, you can at times reduce audit volume. For example, by auditing for failed file_read operations, -fr, you can generate far fewer records than by auditing for all file_read events.

  • If you are using the audit_binfile plugin, efficient audit file management is also important. For example, you can compress a ZFS file system that is dedicated to audit files.

  • Develop a philosophy of auditing for your site.

    Base your philosophy on measures such as the amount of traceability that your site requires, and the types of users that you administer.