Skip Headers

Oracle® Audit Vault Administrator's Guide Release 10.2.3.1 Part Number E13841-02 |
Home | Book List | Contents | Index | Contact Us

Previous | Next
| View PDF

# 1 Introducing Oracle Audit Vault for Administrators

This chapter contains:

- How Do Administrators Use Oracle Audit Vault?

- General Steps for Administering Oracle Audit Vault

- Components of Oracle Audit Vault

- Administrative Tools for Managing Oracle Audit Vault

- Administrative Roles and Their Assigned Tasks

- Planning the Source Database and Collector Configuration

## 1.1 How Do Administrators Use Oracle Audit Vault?

By the time you begin to use this guide, you will have installed Oracle Audit Vault, and the databases (called source databases, or audit data sources) from which you want to extract audit data are ready to audit. This guide explains how to configure the source databases so that Oracle Audit Vault can collect their audit data. After you have completed this configuration, then auditors can generate and customize reports that describe this audit data.

An Oracle Audit Vault administrator is responsible for the following tasks:

- Ensuring that the source databases have auditing enabled

- Understanding the type of auditing that each source database uses

- Selecting the correct Oracle Audit Vault component, called a collector, to connect to the source database, based on the type of auditing that database uses

- Configuring this collector to connect Oracle Audit Vault to the source database

- Configuring and scheduling Audit Vault Server processes

- Ensuring that the collectors are collecting audit data from the source database

- Managing the day-to-day activities of Oracle Audit Vault, such as disk space and backup and recovery operations

- Managing security for Oracle Audit Vault

- Monitoring Oracle Audit Vault to ensure that it is consistently collecting audit data

Oracle Database administrators are responsible for running the Oracle Database audit trail cleanup procedures on the source database, which purge audit trail records from the Oracle source database after these records are archived.

## 1.2 General Steps for Administering Oracle Audit Vault

To administer Oracle Audit Vault, follow these steps:

- Step 1: Understand the Oracle Audit Vault Architecture

- Step 2: Plan the Oracle Audit Vault Source Database and Collector Configuration

- Step 3: Configure Collectors to Collect Audit Data

- Step 4: Monitor and Maintain the Audit Record Collection Process

### 1.2.1 Step 1: Understand the Oracle Audit Vault Architecture

In this chapter, Section 1.3 describes the main components of Oracle Audit Vault, and explains how these components work together. Section 1.4 describes the various tools that you use to administer Oracle Audit Vault. Section 1.5 describes the predefined roles that are created during the Oracle Audit Vault installation process. Understanding how these pieces fit together provides the foundation you need to administer Oracle Audit Vault.

### 1.2.2 Step 2: Plan the Oracle Audit Vault Source Database and Collector Configuration

Section 1.6 provides guidelines for selecting the correct Oracle Audit Vault collector (that is, the module that collects audit data from your source databases) based on the type of database from which you are collecting audit data. You must understand the audit settings and audit trail used in your source databases before you can select the correct collector.

### 1.2.3 Step 3: Configure Collectors to Collect Audit Data

After you have decided which collectors to use for your source database, you are ready to configure them. Chapter 2 explains how to register (configure) collectors for the source databases.

To accomplish the configuration, you can use the command-line utilities described in Section 1.4.

After you complete this step, Oracle Audit Vault is collecting audit data, which the auditors on your site can access by using the reporting tools described in Oracle Audit Vault Auditor's Guide.

### 1.2.4 Step 4: Monitor and Maintain the Audit Record Collection Process

After you have completed the configuration, you should monitor the audit collection activities to ensure that they are working properly. These tasks include the following:

- Perform common management tasks. For example, you may need to check whether the collectors are running, fine-tune how data is collected in the Oracle Audit Vault data warehouse, or modify the attributes of a source database. See the following chapters:

  - Chapter 3 describes common management tasks.

  - Chapter 4 provides advice on managing an Oracle Audit Vault installation on an Oracle Real Application Clusters environment, and what to do if you are concerned that your audit data will fill the default tablespace and disk space.

  - Chapter 5 describes common security tasks and how Oracle Advanced Security and Oracle Database Vault enhance the security of an Oracle Audit Vault system.

  - Chapter 12 describes optimum initialization parameter settings for the REDO collector.

- For Oracle Database administrators, periodically archive and purge the Oracle Database audit trail for the Oracle source database. See the following:

  - Section 4.8 describes steps to follow for archiving and purging the Oracle Database audit trail.

  - Chapter 13 describes data dictionary views that you can query to ensure that your configuration settings are correct.

  - Chapter 14 describes the `DBMS_AUDIT_MGMT` package, which contains the calls you use to archive and purge the Oracle Database audit trail.

- Troubleshoot problems that arise. See the following:

  - Appendix A describes how to troubleshoot the Oracle Audit Vault system.

  - Appendix B explains how to resolve Oracle Audit Vault-specific error messages.

## 1.3 Components of Oracle Audit Vault

This section contains:

- Source Databases

- Oracle Audit Vault Server

- Audit Vault Collection Agent and Collectors

- How the Oracle Audit Vault Components Work Together

### 1.3.1 Source Databases

A source database is a database from which Oracle Audit Vault collects audit data. Oracle Audit Vault can collect this audit data from the internal audit trail tables and operating system audit trail files of a source database.

Table 1-1 lists the supported source database products.

Table 1-1 Supported Source Database Products

Database Product | Supported Versions
--- | ---
Oracle Database | Releases 9.2.x, 10.1.x, 10.2.x, and 11.x for the OSAUD and DBAUD collector types Enterprise Edition Releases 9.2.0.8, 10.2.0.3, 10.2.0.4, 11.1.0.6, and 11.1.0.7 and later for the REDO collector type
Microsoft SQL Server | SQL Server 2000 and SQL Server 2005 on Windows 2000 Server and Windows 2003 Server (32-bit) platforms
Sybase Adaptive Server Enterprise (ASE) | ASE 12.5.4 and ASE 15.0.2 on platforms based on Linux and UNIX, and on Microsoft Windows platforms
IBM DB2 | IBM DB2 Version 8.2 and Version 9.5 on platforms based on Linux and UNIX, and on Microsoft Windows platforms. If you are using Version 8.2, ensure that you have installed Fixpack 16.

### 1.3.2 Oracle Audit Vault Server

The Oracle Audit Vault Server contains the tools necessary to configure Oracle Audit Vault to collect audit data from your source databases. The Audit Vault Server also stores in an Oracle database, and makes it available to reporting tools through a data warehouse.

The Audit Vault Server consists of:

- Audit Data Store

- Oracle Audit Vault Console

- The following services:

  - Audit data collection and storage management

  - Alert management

  - Collector management and monitoring

  - Report management

  - Audit settings management to establish your policy management

  - Published data warehouse that can be used with reporting tools such as Oracle Business Intelligence Publisher to create customized reports

  Configuration services help define information about the source databases that connect to Oracle Audit Vault. Oracle Audit Vault stores information (metadata) about the sources of audit data and policy information (database audit settings).

Table 1-2 describes the Oracle Audit Vault Server components. See also Figure 1-2 to understand how these components work together.

Table 1-2 Oracle Audit Vault Server Components

Components | Description
--- | ---
Oracle Container for Java (OC4J) | Oracle Database container for Web applications. It hosts the following components: Audit Vault Console. User interface for administrators to administer Oracle Audit Vault. Oracle Audit Vault auditors also can use this interface to generate reports, create alerts, and create Oracle Database audit policies. Oracle Enterprise Manager Database Control console. User interface to manage the raw audit data store or audit repository database Management Framework. Internal tool that sends management commands to the Audit Vault collection agent to start or stop collection agents and collectors, collect metrics, receive management commands from the Oracle Audit Vault command-line tools using HTTP protocol or HTTPS mutual certificate-based authentication. Section 1.4 lists the Oracle Audit Vault command-line tools. Audit Policy System. Internal service that retrieves and provisions audit settings on the Oracle Database source. It also enables users to create and manage alerts raised by audit events from all source databases as they are stored in the audit event repository.
Database Client | Infrastructure to communicate to the audit repository, consisting of: Oracle Wallet. Contains credentials to authenticate Oracle Audit Vault users Configuration files. Files used by Oracle Audit Vault for networking, preferences, and so on.
Configuration and Management Tools | Utilities used to configure and manage Oracle Audit Vault, which are described in detail in Section 1.4. They let you define and configure information about what source databases are known to Oracle Audit Vault.
Logs | Informational and error messages for Oracle Audit Vault. See Section A.1 for more information.
Audit repository | Oracle database to consolidate and manage audit trail records, consisting of: Raw audit data store. A partitioned table where audit records are inserted as rows Warehouse schema. Open schema of normalized audit trail records. This is a published data warehouse that auditors can use with reporting tools such as Oracle Business Intelligence Publisher to create customized reports. Job scheduler. Database jobs used to populate and manage the warehouse Alerts. Queue that maintains auditor-created alerts

### 1.3.3 Audit Vault Collection Agent and Collectors

A collector retrieves the audit trail data from a source database and sends it to the Audit Vault Server. The collection agent manages the collectors. The collectors send both valid and invalid audit records, get configuration information, and send error records using Oracle Call Interface (OCI) and JDBC password-based authentication. If the collection agent is stopped, then the source database will still create an audit trail (assuming auditing is enabled). The next time you restart the collection agent, Oracle Audit Vault retrieves the audit data that had been accumulating since the agent was stopped.

Table 1-3 lists the components of the collection agent. To understand how the collection agent fits in with the Oracle Audit Vault process flow, see Figure 1-2.

Table 1-3 Oracle Audit Vault Collection Agent Components

Component | Description
--- | ---
OC4J | Oracle container for Web applications. It hosts the following components: Audit Vault Collector Manager. Receives management commands from the Audit Vault Server to start and stop collectors, collect and return metrics, and so on Audit Settings Manager. Receives commands from Oracle Audit Vault to extract audit settings from an Oracle Database source
Database Server | Infrastructure to communicate to the audit repository, consisting of: Oracle Wallet. Contains credentials to authenticate Audit Vault users Configuration Files. Files used by Oracle Audit Vault for networking, preferences, and so on
Configuration and Management Tools | Utilities used to configure and manage Oracle Audit Vault. These are the `AVCA`, `AVCTL`, `AVORCLDB`, `AVMSSQLDB`, `AVSYBDB`, and `AVDB2DB` command-line utilities.
Logs | Informational and error messages for Oracle Audit Vault (see Section A.1)
Collectors | Table 1-4 shows the type of collectors deployed by the Oracle Audit Vault collection agents and the audit trail from which audit records are extracted and collected.

Table 1-4 lists the types of collectors.

Table 1-4 Oracle Audit Vault Collector Types and Audit Trails

Audit Source | Collector Type | Audit Trail
--- | --- | ---
Oracle Database | DBAUD | Collects from the following audit trails: Oracle Database audit trail, where standard audit events are written to the `SYS.AUD$` dictionary table Oracle Database fine-grained audit trail, where audit events are written to the `SYS.FGA_LOG$` dictionary table Oracle Database Vault audit trail, where audit events are written to the `DVSYS.AUDIT_TRAIL$` dictionary table
Oracle Database | OSAUD | Collects from the following audit trails: On Linux and UNIX platforms: The operating system logs (audit logs) (`SYS.AUD$`) (`.aud`) and XML (`.xml`) files), or syslog On Windows platforms: The operating system Windows event log and operating system logs (audit logs) XML (`.xml`) files
Oracle Database | REDO | Collects from logical change records (LCRs) from the REDO logs. If you plan to use the REDO collector, you can define the data to audit by creating capture rules for the tables from which the REDO collector will capture audit information. See Oracle Audit Vault Auditor's Guide for more information.
Microsoft SQL Server | MSSQLDB | Collects from C2 audit logs, server-side trace logs, and Windows event logs
Sybase ASE | SYBDB | Collects from system audit tables (`sysaudits_01` through `sysaudits_08`) in the `sybsecurity` database
IBM DB2 | DB2DB | Collects from ASCII text files extracted from the binary audit log (`db2audit.log`). These files are located in the `security` subdirectory of the DB2 database instance.

### 1.3.4 How the Oracle Audit Vault Components Work Together

Figure 1-1 provides a high-level overview of how the Oracle Audit Vault components work together.

Figure 1-1 Overview of the Oracle Audit Vault Components

Description of "Figure 1-1 Overview of the Oracle Audit Vault Components"

The process flow works as follows:

1. The source databases, Oracle Database, SQL Server, Sybase ASE, and IBM DB2, have all been configured to use their respective collectors:

   - Oracle Database uses the REDO, DBAUD, and OSAUD collectors.

   - SQL Server uses the MSSQLDB collector.

   - Sybase ASE uses the SYBDB collector.

   - IBM DB2 uses the DB2DB collector.

   As Figure 1-1 shows, you can configure multiple databases from different database product families using the same Audit Vault collection agent to connect to the same Audit Vault Server.

2. The collectors listed in Step 1 retrieve the audit data from their source databases and send this data to the Audit Vault Server.

3. The Audit Vault Server collects and stores this data it in the database, and then makes it available in the warehouse.

   The data warehouse organizes this data into a set of internal dimension tables. The Audit Vault Server stores other information as well, for both the auditor and the administrator.

4. Once the audit data is in the data warehouse dimension tables, an auditor can retrieve this data to generate and customize reports. Any settings that you, the administrator, create, such as security settings, are contained in this server. The Audit Vault Server stores all the tools that you need to configure the Audit Vault components and source databases.

Figure 1-2 shows a detailed view of the Oracle Audit Vault architecture.

Figure 1-2 Detailed View of the Oracle Audit Vault Components

Description of "Figure 1-2 Detailed View of the Oracle Audit Vault Components"

The process flow works as follows:

1. The OC4J components in the Audit Vault Server and Audit Vault collection agent connect using HTTP or HTTPS.

   The OC4J is a container for Web applications that consists of the Audit Vault Console, the Oracle Enterprise Manager Database Control console, the Audit Vault internal tools (management framework), and the audit policy system used to retrieve and make available the audit settings. The HTTP (or HTTPS) connection is used for starting and stopping agents, managing metrics, and running commands related to policy retrieval.

   The Audit Vault Server contains its own database server, and an Oracle wallet containing the administrator's credentials. It also stores configuration information from utility settings (such as `AVCA`, `AVCTL`, and the command-line utilities used for the four database products) and log files that store operational information, such as broken database connections and missing files.

   In addition to its HTTP or HTTPS connection, each collector in the Oracle Audit Vault collection agent maintains an OCI and a JDBC connection to the Audit Vault Server using the credentials from the client wallet.

2. The collectors retrieve audit records from the source databases and send this data to the audit repository, which contains the Audit Vault data warehouse.

   The data warehouse organizes this data into a set of dimension tables. Oracle Audit Vault Auditor's Guide describes the data warehouse dimension tables in detail. In addition to the data warehouse, the audit repository contains auditor-created alert information.

3. Oracle Audit Vault receives data from the Oracle Database redo logs using a database link. The Oracle Database redo logs bypass the collectors.

## 1.4 Administrative Tools for Managing Oracle Audit Vault

You can use the following tools to administer Oracle Audit Vault:

- Audit Vault Console. This graphical user interface provides most of the functionality that you need to administer Oracle Audit Vault.

- Audit Vault Configuration Assistant (AVCA) command-line utility. Use `AVCA` to perform operations such as adding, deploying, and dropping agents, or managing wallets. See Chapter 6 for more information.

- Audit Vault Control (AVCTL) command-line utility. Use `AVCTL` to load, refresh, start, and stop Oracle Audit Vault collection agents and collectors. You also can load and purge data in the Oracle Audit Vault data warehouse with this utility. See Chapter 7 for more information.

- Audit Vault Oracle Database (AVORCLDB) command-line utility. Use `AVORCLDB` to configure Oracle Database source databases with Oracle Audit Vault. See Chapter 8 for more information.

- Microsoft SQL Server Database (AVMSSQLDB) command-line utility. Use `AVMSSQLDB` to configure SQL Server source databases with Oracle Audit Vault. See Chapter 9 for more information.

- Sybase ASE Database (AVSYBDB) command-line utility. Use `AVSYBDB` to configure Sybase ASE source databases with Oracle Audit Vault. See Chapter 10 for more information.

- IBM DB2 Database (AVDB2DB) command-line utility. Use `AVDB2DB` to configure IBM DB2 source databases with Oracle Audit Vault. See Chapter 11 for more information.

## 1.5 Administrative Roles and Their Assigned Tasks

A default Oracle Audit Vault installation provides a set of administrative roles that you can use to manage Oracle Audit Vault. These roles provide separation-of-duty tasks.

Table 1-5 describes the various Oracle Audit Vault administrator roles and the tasks permitted for each role. See also Table 5-1 for a listing of the roles and privileges that are granted to these administrator roles.

Table 1-5 Oracle Audit Vault Administrator Roles and Their Assigned Tasks

Role | When Is the Role Granted? | Role Is Granted to Whom? | Description
--- | --- | --- | ---
`AV_ADMIN` | During Server installation | Audit Vault administrator | Accesses Oracle Audit Vault services to administer, configure, and manage a running Oracle Audit Vault system. A user who is granted this role configures and manages metadata for audit source databases, collection agents, collectors, the configuration of the source database with the collection agent, and the data warehouse. The installation process creates and grants a user account with this role. Only the user granted the `AV_ADMIN` role can grant the `AV_ADMIN` role to other Oracle Audit Vault administrators. You can consider the `AV_ADMIN` role a super-user account for Oracle Audit Vault, except that a user who has been granted this role cannot view, update, or delete audit data.
`AV_AUDITOR` | During Server installation | Audit Vault auditor | Accesses Oracle Audit Vault reporting and analysis services to monitor components, detect security risks, create and evaluate alert scenarios, create detail and summary reports of events across systems, and manage the reports. A user who is granted this role manages central audit settings and alerts. This user also uses the data warehouse services to further analyze the audit data to look for trends, intrusions, anomalies, and other items of interest. The installation process creates and grants a user account with this role. However, during installation, you optionally can bypass creating this user account. In that case, the roles and privileges normally granted to `AV_AUDITOR` are granted to `AV_ADMIN` instead. Typically, one user is granted an `AV_ADMIN` role and one user is optionally granted an `AV_AUDITOR` role as part of installing the Audit Vault Server.
`AV_AGENT` | During collection agent registration | Collection agent software component | Manages collection agents and collectors by starting and stopping them. Oracle Audit Vault creates this role for internal use only.
`DV_ACCTMGR` | During Audit Vault Server installation | Database Vault account manager | Manages database user accounts. Be aware that the inclusion of Oracle Database Vault in the Audit Vault Server prevents users `SYS` and `SYSTEM` from creating, altering, or dropping user accounts. See Oracle Database Vault Administrator's Guide for more information about how Oracle Database Vault affects user privileges. See also Section 5.3.
`DV_OWNER` | During Audit Vault Server installation | Database Vault owner | Manages Oracle Database Vault roles and configuration.

## 1.6 Planning the Source Database and Collector Configuration

This section contains:

- About Planning the Source Database and Collector Configuration

- Planning the Oracle Source Database and Collector Configuration

- Planning the Microsoft SQL Server Source Database and Collector Configuration

- Planning the Sybase ASE Source Database and Collector Configuration

- Planning the IBM DB2 Source Database and Collector Configuration

### 1.6.1 About Planning the Source Database and Collector Configuration

This section provides guidelines for selecting the correct Oracle Audit Vault collector for the source databases from which you want to extract audit data. In brief, for Oracle Database, the type of collector that you select depends on the type of auditing that you have enabled in the source database. The Microsoft SQL Server, Sybase ASE, and IBM DB2 databases each use one collector specific to each of these database products.

After you understand which collector to choose, you are ready to register the source database and collector with Oracle Audit Vault.

### 1.6.2 Planning the Oracle Source Database and Collector Configuration

To plan the Oracle Database source database and collector configuration:

1. Ensure that auditing has been enabled, and find the type of auditing that the Oracle source database uses.

   See Oracle Audit Vault Auditor's Guide for more information about the Oracle Database requirements.

2. Based on the audit trail setting, determine which collector to use.

   The type of auditing that has been enabled determines the collector you will choose. The types of collectors available are as follows:

   - OSAUD collector. Use this collector if the audit trail is being written to operating system files. Table 1-6 lists the operating system audit trail settings that use the OSAUD collector.

   - DBAUD collector. Use this collector if the audit trail is being written to the database audit trail. Table 1-7 lists of the database audit trail settings that use the DBAUD collector.

   - REDO collector. Use this collector if the database is collecting audit data from the redo logs. Table 1-8 shows more information about redo logs.

3. Register the Oracle source database and the appropriate collector with Oracle Audit Vault, as described in Section 2.3.

The OSAUD operating system audit settings capture the following activities:

- `SELECT` statements

- Data definition language (DDL) and data manipulation language (DML) statements

- Succeeded and failed actions

- `SYS` operations (Set the `AUDIT_SYS_OPERATIONS` initialization parameter to `TRUE` to perform administrator auditing. SYS auditing collects SQL text information.)

Table 1-6 lists the Oracle Database operating system audit settings that use the OSAUD collector.

Table 1-6 Oracle Database Operating System Audit Settings for the OSAUD Collector

Audit Trail | Audit Trail Settings | Comments
--- | --- | ---
Linux and UNIX-based platforms (`.aud`) | `OS` | None
Linux and UNIX-based platforms (`.xml`) | `XML, EXTENDED` | `EXTENDED` writes SQL text and SQL bind information to the audit trail.
Linux and UNIX-based platforms (syslog) | `OS` | More secure than audit records stored in operating system audit trail
Windows platform Windows event log | `OS` | None
Windows platform Operating system XML files (`.xml`) | `XML, EXTENDED` | `EXTENDED` writes SQL text and SQL bind information to the audit trail.

Table 1-7 lists the Oracle Database database audit trail settings, which must use the DBAUD collector.

Table 1-7 Oracle Database Audit Trail Settings for the DBAUD Collector

Audit Trail | Audit Trail Setting | Audited Operations | Comments
--- | --- | --- | ---
`SYS.AUD$` | `DB` or `DB, EXTENDED` | `SELECT`, DML, DDL, success and failure, SQL text, SQL bind | `EXTENDED` writes SQL text and SQL bind data to the audit trail.
`SYS.FGA_LOG$` | Not applicable. To enable fine-grained auditing, use the `DBMS_FGA` PL/SQL package. | Very specific user-defined audited conditions, such as the time a user modified a table column | None
`DVSYS.AUDIT_TRAIL$` | Not applicable | Oracle Database Vault audit activity specified by audit options on realms, command rules, and so on | None

Table 1-8 shows the redo log audit trail setting that uses the REDO collector.

Table 1-8 Oracle Database Redo Log Setting for the REDO Collector

Audit Trail | Audit Trail Setting | Audited Operations | Comments
--- | --- | --- | ---
Redo logs | Audit policy: capture rule | DML, DDL, before and after values | Tracks before and after changes to sensitive data columns.

### 1.6.3 Planning the Microsoft SQL Server Source Database and Collector Configuration

To plan the Microsoft SQL Server source database configuration:

1. Ensure that auditing has been enabled in the SQL Server source database.

   See the Microsoft SQL Server product documentation for more information.

2. Understand the audit trail settings used for SQL Server databases.

   Table 1-9 lists the SQL Server audit trail settings.

3. Configure the MDDSQLDB collector to collect audit data from the SQL Server database, as described in Section 2.4.

Table 1-9 describes the SQL Server audit trail.

Table 1-9 Microsoft SQL Server Source Database Audit Settings for the MSSQLDB Collector

Audit Trail - Audit Logs | Audit Trail Settings | Audited Operations | Comments
--- | --- | --- | ---
C2 audit logs | Configure SQL Server security properties through SQL Server Enterprise Manager. | Auditing compliant with C2 certification Records both failed and successful attempts to access statements and objects Uses all or nothing approach to auditing | Records all actions
Server-side trace logs | Run stored procedures to start and stop tracing, to configure and filter traces. | Records fine-grained security-related activity Can choose exactly which events to audit and what information about each event to record Trace configuration information is not persistent. It is deleted when you restart SQL Server. | Records specific activity Traces can be configured to record only specific activity. Results can be filtered to record only activity that matches a certain pattern, such as a SQL verb (for example, `SELECT`, `INSERT`, `UPDATE`, `DELETE`), or that involve a particular object (for example, a specific table).
Windows event log | Running by default. | Provides a standard, centralized way for applications (and the operating system) to record important software and hardware events. | None

### 1.6.4 Planning the Sybase ASE Source Database and Collector Configuration

To plan the Sybase ASE source database configuration:

1. Ensure that auditing has been enabled in the Sybase ASE source database.

   See the Sybase ASE product documentation for more information.

2. Understand the audit trail setting information used for Sybase ASE databases.

   Table 1-10 shows the Sybase ASE audit trail setting information.

3. Configure the SYBDB collector to collect audit data from the SQL Server database, as described in Section 2.5.

Table 1-10 describes the Sybase ASE audit trail.

Table 1-10 Sybase ASE Database Audit Setting for the SYBDB Collector

Audit Trail - Audit Logs | Audit Trail Setting | Audited Operation | Comments
--- | --- | --- | ---
System audit table logs | Run system procedures to set global audit options, and then to enable, disable, or restart auditing. | Records standard to fine-grained audit and security-related activity Can choose exactly what to audit Can choose to audit everything or just very specific events | Implement your best practices for Sybase ASE database auditing

### 1.6.5 Planning the IBM DB2 Source Database and Collector Configuration

To plan the IBM DB2 source database configuration:

1. Ensure that auditing has been enabled in the IBM DB2 source database.

   See the IBM DB2 product documentation for more information.

2. Understand the audit trail information used for IBM DB2 databases.

   Table 1-11 shows the IBM DB2 audit trail setting information.

3. Configure the DB2DB collector to collect audit data from the DB2 database, as described in Section 2.6.

Table 1-11 describes the IBM DB2 audit trail.

Table 1-11 IBM DB2 Database Audit Setting for the DB2DB Collector

Audit Trail - Audit Logs | Audit Trail Setting | Audited Operation | Comments
--- | --- | --- | ---
ASCII text files | Run the `DB2AUDIT` command to enable auditing, disable auditing, and set auditing operations. | Audit (AUDIT). Changes to audit records or when the audit log is accessed Authorization Checking (CHECKING). Authorization checking during attempts to access or manipulate DB2 database objects or functions Security Maintenance (SECMAINT). Grants or revokes to object or database privileges or to the `DBADM` privilege; also modification of the `SYSADM_GROUP`, `SYSCTRL_GROUP`, or `SYSMAINT_GROUP` configuration parameters Object Maintenance (OBJMAINT). Creating and dropping data objects System Administration (SYSADMIN). Operations requiring `SYSADM`, `SYSMAINT`, or `SYSCTRL` privileges User Validation (VALIDATE). Authentication of users or retrieval of system security information Operation Context (CONTEXT). Database operation context performed. Helps when interpreting the audit log file. See the IBM DB2 documentation for more information about how the operation context of a DB2 database is audited. In addition to these categories, you can audit successes, failures, or both. | Implement your best practices for IBM DB2 database auditing