Audit overview

Audit is the process of maintaining detailed and secure logs of critical activities in a business environment.

These activities can be related to security, content management, business transactions, or other such activities.

For example, the following activities can be audited:

Use the method provided in Native Security Verify Access auditing to manage audit events with the native Security Verify Access approach.

For information about managing statistical events, see Working with statistics. For information about WebSEAL HTTP events, see WebSEAL HTTP logging.

Audit versus diagnostics

ISAM provides ways to collect events that we can use for diagnostic and auditing purposes of the servers. Events for diagnostics and auditing pertain to the operations of the servers.

To enable diagnostics and auditing, define which types of events to capture. We can write recorded events to one or a combination of the following files or devices:

Beyond these destinations, when events are captured, they can be redirected to a remote authorization server or redirected to an application for processing.

Audit events

For auditing purposes, define which audit, statistic, or other type of events to capture.

You can use events to create snapshots of various server activities. You can record audit events using the native Security Verify Access support.

To configure auditing events, define stanza entries in the configuration files. Depending on your approach, we define different stanza entries in different configuration files.

Use the following guidelines for defining the auditing configuration:

Diagnostic events

For diagnostic information, define which message events and which trace events to capture. These events can help us troubleshoot problems.

To configure diagnostic events, we must define statements in the server-specific routing files. Each server has an associated routing file. The statements in these routing files are for both message events and trace events. You define the statements for message events by severity level. You can define the statements for trace events by trace level and optionally by component.

For information about message and trace events, see the Troubleshooting topics in the IBM Knowledge Center.

Audit trails

IT organizations can use information that is contained in audit trails to help them show compliance with government regulations such as the following regulations:

For these reasons, such audit trails must be sometimes maintained for years.

Audit trails are useful to check enforcement and effectiveness of IT controls, for accountability and vulnerability, and for risk analysis. IT organizations can also use auditing of security-related critical activities to aid in forensic investigations of security incidents.

When a security incident occurs, audit trails enable analysis of the history of activities that occurred before the security incident. This analysis might answer questions such as who did what, when, where, and how. Based on this analysis, appropriate corrective actions can be taken. For these reasons, audit trails must be archived and accessible for years.

Audit trails can be established in relational databases that are easily queried to generate reports. When audit trails are written to relational databases, reporting tools can be used to display reports. Reports can fall into the following categories:

Audit records for HTTP access

The generation of audit records for HTTP access to WebSEAL can use large quantities of disk space quickly. We can reduce the volume of audit events generated using the following strategies:

For details about reducing records by generating events for unsuccessful accesses only, see Native auditing if we are using native Security Verify Access auditing.

For details about using POPs to selectively disable the generation of audit events, see Disable resource access events.

Parent topic: Audit