Auditing overview

Auditing versus diagnostics

Security Access Manager provides ways to collect events that you 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. You can write recorded events to one or a combination of the following files or devices:

• Log file.
• Standard output (STDOUT) device.
• Standard error (STDERR) device.

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 by using the native Security Access Manager support.

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

Use the following guidelines for defining the auditing configuration:

• For audit events, define logcfg entries in the [aznapi-configuration] stanza of the server configuration file.
• For HTTP request events, define entries in the [aznapi-configuration] and [logging] stanzas of the WebSEAL configuration files for HTTP events that you want to record.

Diagnostic events

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

To configure diagnostic events, you 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 more 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:

• Sarbanes-Oxley (SOX) Act.
• The Health Insurance Portability and Accountability Act (HIPAA).
• The Basel II international banking accord.

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:

• Trend reports provide summarized audit data that you can use to assess whether there is any long-term rise or fall in questionable activity. Trend reports can help provide a "security pulse" for an organization.
• Operational reports allow a detailed review of audit data to help determine the cause of a security incident.

Audit records for HTTP access

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

• Generate events for unsuccessful HTTP accesses only.
• Selectively disable the generation of events by using attached protected object policies (POPs).

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

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