Audit retention and storage

Storage cost is the most significant operational cost of auditing. The amount of audit data depends on the site policy for the following major factors: different number of users; different usage of the system or system loads (web or application server, timesharing system, workstation); degree of traceability and accountability that is required. As you plan for the storage of audit logs, remember the following:

You must set aside more disk space for the audit trail if auditing is done for monitoring of system use than auditing for abnormal events.

You can reduce storage cost by reducing the amount of audit data generated. Define pre-filtering rules, using the AudFilter product, that reduce the potential size of the audit trail while not compromising security. You can define filtering rules for events that are not generally interesting for audit purposes. For example, any read-only operations on world-readable objects, operations on non-existing files, any operation on files owned by the user on /home.

If you expect the audit data volume to be high, configure audit trails on a logical volume consisting of multiple physical disks and multiple physical I/O cards. Use the -Noption with audsys command to split the audit trail into multiple files.

Frequently accessed data, such as production data, must be available on-line. Data not requiring as frequent or ready access such as back-up data can be stored off-line. You can use the auditdp command to filter on-line data to remove unnecessary information. This enables you to keep the audit file at a manageable size and keep the less interesting information in off-line, backup storage. For example, use auditdp to filter only login and logout events from one month’s audit trail. If you need to access other records, you can recover them from off-line backup tapes.

To keep audit files at a manageable size, you can invoke the audomon daemon. This monitors the capacity of the current audit trail and the file system on which the audit trail is located. If either capacity limit is reached, audit recording automatically switches to an alternative audit trail and backs up the current audit trail to a secondary storage".

Deploying a log management solution is better than storing audit data distributed across systems because it facilitates access to logged data collected from across the organization and unifies searching, reporting, alerting, and analysis across any type of enterprise log data.

Ensure that when the required data retention period has ended, the logs are retired by destroying them according to the organization's data destruction policies.

Audit log analysis

The cost of analysis is roughly proportional to the amount of audit data collected. The cost of analysis includes the time it takes to review audit records, and the time it takes to archive them and keep them in a safe place. The following best practices address the need to make analysis easier, enabling the organization to extract the wealth of information logs can provide:

Regular review and analysis helps to identify late hours login, login failures, failed access to system files, and failed attempts to perform security-relevant tasks. Depending on the systems, risk environment, and other requirements, logs must be reviewed in real-time, daily, monthly, or every 90 days.

Automation can significantly improve analysis because it takes much less time to perform and produce more valuable results.

Analyzing logs using a log management solution is better than analyzing logs separately in different systems because attacks usually involve multiple assets.

You can analyze logs by extracting useful reports from the audit trail by using the following tools:

– Audit Record Display (audisp) in HP-UX 11i v2.

21