Audit Planning
This chapter describes how to set up auditing for your Solaris installation. In particular, the chapter covers issues that you need to consider before you enable the auditing service. This chapter covers the following:
Handling the Audit Trail
File space for the audit trail is one of the biggest issues with auditing. Each host should have several audit directories that are configured for audit files. You should decide how to configure the audit directories as one of the first steps before you enable auditing on any hosts. The following table lists the issues that should be resolved when you plan for audit trail storage.
Issue | Description |
|---|---|
1. Determine how much auditing your site needs | Balance your site's security needs against the availability of disk space for the audit trail. For guidance on how to reduce space requirements while still maintaining site security, as well as how to design audit storage, see "Controlling Auditing Costs" and "Auditing Efficiently". |
2. Determine which systems are to be audited and which systems are to store audit files | Decide which hosts in your network need to be audited. Make sure to create at least one local audit directory for each host that is to be audited. Then, decide which hosts are to hold most of the audit trail. |
3. Determine the names and locations of the audit directories | Create a list of all the audit directories that you plan to use. |
4. Plan which hosts are to use which audit directories | Create a map that shows which host should use which audit directory. This step helps you to balance the auditing activity. |
Deciding Who and What to Audit
Novice system administrators tend to start out wanting to collect as much information as possible about user and system actions. However, audit files can quickly grow to fill the available space, so it makes sense to be selective about what kinds of activities are audited.
Issue | Description |
|---|---|
1. Determine which audit classes you need for your site | The best time to add audit classes or to change the default classes is before you start the auditing service. See "Audit Flags" for information about auditing classes. |
2. Determine event-to-class mappings | In many situations, the default mapping is sufficient. However, if you have added new classes or have changed them, you might also need to move an event to a different class. |
3. Decide what classes should be audited for all users on all machines | The system-wide audit flags in the audit_control file apply to all users and processes. Audit flags determine whether an audit class is audited for success, for failure, and for both. Every machine in the installation should have the same audit flag settings in their audit_control file. |
4. Determine user exceptions to the installation-wide audit settings | If you decide that some users should be audited differently from the system-wide settings, modify the users' entries in the audit_user file on each machine. For more information see "How to Change Users' Audit Characteristics". |
5. Determine the minimum free disk space (minfree) that should be available on an audit file system before a warning is sent | When the amount of disk space on an audit file system drops below the minfree percentage, the audit daemon switches to the next available audit directory and sends a warning that the soft limit has been exceeded. For more information, see "Example -- Changing the Soft Limit for Warnings". |
6. Decide which audit policies your site needs | The policy variable is a dynamic kernel variable, so its value is not saved when the system is brought down. Therefore, you should set the desired policy by using an appropriate startup script. For more information, see "How to Enable or Disable an Audit Policy". |
7. Decide how to manage the audit_warn mail alias | The audit_warn script is run by the auditd daemon whenever the daemon switches audit directories or encounters difficulty (such as lack of disk space). By default, the audit_warn script sends mail to an audit_warn alias and sends a message to the console. You need to either modify the alias, or change the script to send the message to a different alias. For more information, see "How to Configure the audit_warn Alias". |
8. Decide what to do when all the audit directories are full | To permit the system to continue functioning in the event of an audit trail overflow, you can enable the cnt policy. For a cnt policy example, see "Example -- Setting the cnt Policy". Alternatively, you can create an account that can log in and work without being audited. See "Example -- Creating an Audit Admin Login" for an audit account example. |
Determining Which Audit Policies to Use
Audit policies refer to the auditing options that are enabled or disabled for a particular configuration. You can inspect, enable, or disable the current audit policy with the auditon system call at the program level. Or, to do the same task you can run the auditconfig command.
By default, all audit policies are disabled. You need to enable any audit policies that you want to use.
The audit policies are disabled by default to minimize storage requirements and system processing demands. You can enable audit policies, and disable them dynamically. Use the following table to determine if the needs of your site justify the additional overhead that results from enabling one or more audit policies.
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
Cost of storage of audit data
Cost of Increased Processing Time
The cost of increased processing time is the least significant of the costs of auditing. The first reason is that auditing generally does not occur during computation-intensive tasks, such as image processing, complex calculations, and so forth. The other reason that processing cost is usually insignificant is that the cost for single-user systems is usually small enough to ignore.
Cost of Analysis
The cost of analysis is roughly proportional to the amount of audit data that is collected. The cost of analysis includes the time it takes to merge and review audit records, and the time it takes to archive them and keep them in a safe place.
The fewer records that you generate, the less time it takes to analyze them. Upcoming sections, "Cost of Storage" and "Auditing Efficiently", describe how you can reduce the amount of data that you collect, while still providing enough coverage to achieve your site's security goals.
Cost of Storage
Storage cost is the most significant cost of auditing. The amount of audit data depends on the following:
Number of users
Number of machines
Amount of use
Degree of security that is required
Because these factors vary from site to site, no formula can determine in advance the amount of disk space to set aside for audit data storage.
Full auditing (with the all flag) fills up disks quickly. Even a simple task such as compiling a program of modest size (for example, 5 files, 5000 lines total) in less than a minute could generate thousands of audit records, occupying many megabytes of disk space. Therefore, it is very important to use the preselection features to reduce the volume of records that are generated. For example, by omitting the fr class instead of all classes, you can reduce the audit volume by more than two-thirds. Efficient audit file management is also important after the audit records are created, to reduce the amount of storage that is required.
Before you configure auditing, you should understand the audit flags and the types of events they flag. Develop a philosophy of auditing for your site that is based on the amount of security your site requires, and the types of users you administer.
Auditing Efficiently
The techniques in this section can help you achieve your organization's security goals while auditing more efficiently:
Randomly audit only a certain percentage of users at any one time
Reduce the disk-storage requirements for audit files by combining, reducing, and compressing them. Develop procedures for archiving them, transferring them to removable media, and storing them offline.
Monitor the audit data in real time for unusual behaviors. You can set up procedures to monitor the audit trail as it is generated for certain activities. You can write a script to trigger an automatic increase in the auditing of certain users or certain machines in response to detection of unusual events.
For example, write a script that (1) monitors the creation of audit files on all the audit file servers, and (2) processes them with the tail command (see the tail(1) man page). Pipe the output of tail -0f through the praudit command to yield a stream of audit records as soon as the records are generated. This stream can be analyzed for unusual message types or other indicators, and delivered to the auditor. Or, the script can be used to trigger automatic responses.
In addition, the script should include code that (3) constantly monitors the audit directories for the appearance of new not_terminated audit files, and (4) terminates outstanding tail processes when their files are no longer being written to.