System Administration Guide: Security Services

Chapter 21 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. The following is a list of the planning information in this chapter:

For an overview of auditing, see Chapter 20, BSM (Overview). For procedures to configure auditing at your site, see Chapter 22, Managing the BSM Service (Tasks).

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.

Issues Related to Audit Trail Storage	What You Need to Plan For
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. Determine 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

You want to be selective about what kinds of activities are audited, and you want to collect useful audit information. Audit files can quickly grow to fill the available space, so you should plan what to audit.

Issues Related to What to Audit	What You Need to Plan For
1. Determine the audit classes that 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 Classes and Their 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 class definitions, 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, or for both. Every machine in the installation should have the same audit flag settings in the machines' `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 disk space on an audit file system drops below the `minfree` percentage, the audit daemon switches to the next available audit directory. The daemon then 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. The script also runs when the daemon encounters a difficulty, such as a 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 determine the characteristics of the audit records for the local host. The policies are set by a startup script. The bsmconv script, which enables the auditing service, creates the /etc/security/audit_startup script. The audit_startup script executes the auditconfig command to establish audit policy. See the audit_startup(1M) man page.

The audit policies are disabled by default to minimize storage requirements and system processing demands. You can enable and disable audit policies dynamically with the auditconfig command. You can enable and disable the policies permanently with the audit_startup script. 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.

Table 21–1 Effects of Audit Policies


Policy Name	Description	Why Change the Policy?
`arge`	When disabled, this policy omits environment variables of an executed program script from the `exec` audit record. When enabled, this policy adds the environment variables of an executed program script to the `exec` audit record. The resulting audit records contain much more detail than when this policy is disabled.	The disabled option collects much less information than the enabled option. The enabled option makes sense when you are auditing a few users. The option is also useful when you have suspicions about the environment variables that are being used in `exec` programs.
`argv`	When disabled, this policy omits the arguments of an executed program script from the `exec` audit record. When enabled, this policy adds the arguments of an executed program script to the `exec` audit record. The resulting audit records contain much more detail than when this policy is disabled.	The disabled option collects much less information than the enabled option. The enabled option makes sense when you are auditing a few users. The option is also useful when you have reason to believe that unusual `exec` programs are being run.
`cnt`	When disabled, this policy blocks a user or application from running. The blocking happens when audit records cannot be added to the audit trail because no disk space is available. When enabled, this policy allows the event to complete without an audit record being generated. The policy maintains a count of audit records that are dropped.	The disabled option makes sense in an environment where security is paramount. The enabled option makes sense when system availability is more important than security.
`group`	When disabled, this policy does not add a groups list to audit records. When enabled, this policy adds a groups list to every audit record as a special token.	The disabled option usually satisfies requirements for site security. The enabled option makes sense when you need to audit which groups are generating auditable events.
`path`	When disabled, this policy records in an audit record at most one path that is used during a system call. When enabled, this policy records every path that is used in conjunction with an audit event to every audit record.	The disabled option places at most one path in an audit record. The enabled option enters each file name or path that is used during a system call in the audit record as a path token.
`public`	New in the Solaris 9 8/03 release. When disabled, this policy does not add read-only events of public objects to the audit trail when the reading of files is preselected. Audit flags that contain read-only events include `fr`, `fa`, and `cl`. When enabled, this policy records every read-only audit event of public objects if an appropriate audit flag is preselected.	The disabled option usually satisfies requirements for site security. The enabled option is rarely useful.
`seq`	When disabled, this policy does not add a sequence number to every audit record. When enabled, this policy adds a sequence number to every audit record. The `seq` token holds the sequence number.	The disabled option is sufficient when auditing is running smoothly. The enabled option makes sense when you are checking that audit files are being written correctly. In the case of file corruption, you might be able to spot bad records quickly. The sequence numbers might be out of order, or some numbers might be missing. A partially written audit record is an example of file corruption.
`trail`	When disabled, this policy does not add a `trailer` token to audit records. When enabled, this policy adds a `trailer` token to every audit record.	The disabled option creates a smaller audit record. The enabled option marks the end of each audit record clearly with a trailer token. The trailer token is often used in conjunction with the sequence token when debugging. In the case of file corruption , the `auditreduce` command resyncs faster on good records. A partially written audit record is an example of file corruption.

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 of Audit Data

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 is that the cost for single-user systems is usually small enough to ignore.

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. Cost also includes the time that is required to archive the records and keep the records in a safe place.

The fewer records that you generate, the less time that is required to analyze the audit trail. Upcoming sections, Cost of Storage of Audit Data and Auditing Efficiently, describe ways to audit efficiently. 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 of Audit Data

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, that is, with the all flag, fills up disks 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, the audit trail of a program of five files and 5000 lines would occupy many megabytes of disk space. You judiciously use the preselection features to reduce the volume of records that are generated. For example, by omitting the fr class, you can reduce the audit volume by more than two-thirds. Efficient audit file management is also important. After the audit records are created, file management reduces the amount of storage that is required.

Before you configure auditing, you should understand the audit flags. You should understand the types of events that the flags audit. Develop a philosophy of auditing for your site that is based on sensible measures. Such measures include the amount of security that your site requires, and the types of users that 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 the files. Develop procedures for archiving the files, for transferring the files to removable media, and for storing the files offline.
Monitor the audit data in real time for unusual behaviors. You can set up procedures to monitor the audit trail as the trail 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. The command yields a stream of audit records 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. The script should (4) also terminate outstanding tail processes when their files are no longer being written to.