8/23

# 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

- Default Oracle Audit Vault Roles

- 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 the Oracle Audit Vault Server and the Oracle Audit Vault collection agent, to prepare for the collection of audit data from your databases (called source databases, or audit data sources). 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 usage 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.10 describes steps to follow for archiving and purging the Oracle Database audit trail.

  - Oracle Database SQL Reference describes data dictionary views that you can query to ensure that your configuration settings are correct. These views are as follows:

    `DBA_AUDIT_MGMT_CONFIG_PARAMS`

    `DBA_AUDIT_MGMT_LAST_ARCH_TS`

    `DBA_AUDIT_MGMT_CLEANUP_JOBS`

    `DBA_AUDIT_MGMT_CLEAN_EVENTS`

  - Oracle Database PL/SQL Packages and Types Reference describes the `DBMS_AUDIT_MGMT` package, which contains the procedures and functions that 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

- Oracle Database Vault

- 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 | For the OSAUD and DBAUD collector types: Releases 9.2.x, 10.1.x, 10.2.x, and 11.x For the REDO collector type: Enterprise Edition Releases 9.2.0.8, 10.2.0.3, 10.2.0.4 and later, 11.1.0.6 and later, and 11.2 for the REDO collector type
Microsoft SQL Server | SQL Server 2000 and SQL Server 2005 on Windows 2000 Server and Windows 2003 Server platforms. SQL Server 2008. Only the Event Log, C2 and server-side trace audit trails are supported.
Sybase Adaptive Server Enterprise (ASE) | ASE 12.5.4 through ASE 15.0 on platforms based on Linux and UNIX, and on Microsoft Windows platforms
IBM DB2 | IBM DB2 Version 8.2 through 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 contains an Oracle database, and makes it available to reporting tools through a data warehouse.

This section contains:

- General Oracle Audit Vault Server Components

- Default Oracle Audit Vault Server Port Numbers

#### 1.3.2.1 General Oracle Audit Vault Server Components

The Audit Vault Server consists of:

- Audit data store (a repository containing the audit data that is collected by the Audit Vault collectors)

- Oracle Audit Vault Console

- The following services:

  - Audit data collection and storage management

  - Alert management

  - Collector management and monitoring

  - Report management

  - User entitlement management reports

  - 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.

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. Also, Oracle Audit Vault auditors 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, and 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 from the Oracle Database source. It also enables users to create and manage alerts raised by audit events from all source databases while they are being stored in the audit event repository. User Entitlement System. Internal service that retrieves user entitlement information from an Oracle Database source. PDF scheduling and printing subsystem. Internal service that schedules and generates Oracle Audit Vault reports in PDF format. SMTP integration system. Internal service that manages e-mail notifications for Oracle Audit Vault reports and alerts. Remedy trouble ticket integration system. Internal service that manages the Remedy trouble ticket service for Oracle Audit Vault reports and alerts.
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 (Release 10.2.0.4) to consolidate and manage audit trail records. It has the following components: Raw audit data store. A partitioned table where audit records are inserted as rows Warehouse schema. An 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. A queue that maintains auditor-created alerts

#### 1.3.2.2 Default Oracle Audit Vault Server Port Numbers

Table 1-3 describes the ports that the Audit Vault Server uses. To find the port numbers that were used when you installed Oracle Audit Vault, check the `portlist.ini` file, which is in the `$ORACLE_HOME/install` directory. Be aware that if you change the port numbers later on, the `portlist.ini` file does not reflect the changes. If you need to change the port numbers, see Section 4.9.

Table 1-3 Oracle Audit Vault Server Ports

Component | Default Port NumberFoot 1 | Required to be Open | Finding the Current Port Number
--- | --- | --- | ---
SQL*Net listener | 1521 | Yes | At a command line, enter the following command:
    lsnrctl status
Enterprise Manager Database Control HTTP (OC4J) | 1158, 5500 | Yes, if you want to use Database Control with the Audit Vault Console | At a command line, enter the following command:
    emctl status dbconsole
Oracle Audit Vault Console HTTP | 5700 | Yes | At a command line, enter the following command:
    avctl show_av_status
OC4J RMI | 5522 | No | Search for `rmi-server` port in the following file in the Audit Vault Server: `$ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_``hostname_SID``/config/rmi.xml`
OC4J JMS | 5542 | No | Search for `jms-server port` in the following file in the Audit Vault Server: `$ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_``hostname_SID``/config/jms.xml`
Oracle Audit Vault Reports HTTP | 5707 | Yes | In SQL*Plus, run the following query:
    SELECT DBMS_XDB.GETHTTPPORT FROM DUAL;

Footnote 1 The default port number can vary, depending on your installation. When you install Oracle Audit Vault, Oracle Universal Installer uses a range of port numbers. If another process is using the first default port number it finds, then it checks for the next free port number.

### 1.3.3 Oracle Database Vault

Oracle Database Vault is included in the Audit Vault Server. Database Vault protects the Audit Vault Server data, including restricting the audited data from administrative access. By default, Database Vault is enabled.

For more information about how Oracle Database Vault is integrated with Oracle Audit Vault, see Section 5.5.

### 1.3.4 Audit Vault Collection Agent and Collectors

This section contains:

- What Are Collection Agents and Collectors?

- General Audit Vault Collection Agent and Collector Components

- Default Audit Vault Collection Agent and Collector Port Numbers

#### 1.3.4.1 What Are Collection Agents 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, then Oracle Audit Vault retrieves the audit data that had been accumulating since the agent was stopped.

You configure one collection agent for each host and one or more collectors for each individual source database. For example, if a host contains four databases, then you would configure one collection agent for that host and one or more collectors for each of the four databases. The number of collectors that you configure and the collection agent that you use to manage them depends on the source database type and the audit trails that you want to collect from it.

The collector that you configure for each source database is based on the type of audit trail the source database is configured to use. For example, if an Oracle source database is configured to write the audit trail to the database audit trail, then it uses the DBAUD collector.

You can create the collection agent on one computer and manage multiple collection agents from there. For example, suppose you have 25 source databases on 25 servers. You must configure a collector for each of these source databases, but you do not need to configure a collection agent of each of the 25 servers. Instead, just create one collection agent to manage the 25 collectors. Be aware, however, that for Oracle databases, you cannot use a remote collection agent to collect audit data from users who have logged in with the `SYSDBA` or `SYSOPER` privilege.

#### 1.3.4.2 General Audit Vault Collection Agent and Collector Components

Table 1-4 describes the components of the collection agent.

Table 1-4 Oracle Audit Vault Collection Agent Components

Component | Description
--- | ---
OC4J | Oracle container for Web applications. It contains the Audit Vault Collector Manager, which receives management commands from the Audit Vault Server to start and stop collectors, collect and return metrics, and so on.
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-5 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-5 describes the types of collectors and their corresponding audit trail types.

Table 1-5 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 data from the following audit trails: On Linux and UNIX platforms: The Oracle database audit files written to the operating system (`.aud`) files, and syslog files (but not compressed syslog files) On Windows platforms: The operating system Windows Event Log and operating system logs (audit logs) XML (`.xml`) files
Oracle Database | REDO | Collects audit data 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 audit data from C2 audit logs, server-side trace logs, and Windows Event Logs
Sybase ASE | SYBDB | Collects audit data from system audit tables (`sysaudits_01` through `sysaudits_08`) in the `sybsecurity` database
IBM DB2 | DB2DB | Collects audit data 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.3 Default Audit Vault Collection Agent and Collector Port Numbers

Table 1-6 describes the default port numbers that the Audit Vault agent uses. To find the port numbers that were used when you installed Oracle Audit Vault, check the `portlist.ini` file, which is in the `$ORACLE_HOME/install` directory. Be aware that if you change the port numbers later on, the `portlist.ini` file does not reflect the changes. If you need to change the port numbers, see Section 4.9.

Table 1-6 Oracle Audit Vault Agent Ports

Component | Default Port NumberFoot 1 | Required to be Open | Finding the Current Port Number
--- | --- | --- | ---
OC4J RMI | 3101 | Yes | Search for `rmi-server port` in the following file in the Audit Vault Agent home directory: `$ORACLE_HOME/oc4j/j2ee/home``/config/rmi.xml`
OC4J JMS | 3201 | No | Search for `jms-server port` in the following file in the Audit Vault Agent home directory: `$ORACLE_HOME/oc4j/j2ee/home``/config/jms.xml`
Agent HTTP | 7010 | Yes | Search for `web-site port` in the following file in the Audit Vault Agent home directory: `$ORACLE_HOME/oc4j/j2ee/``home/config/http-web-site.xml`

Footnote 1 The default port number can vary, depending on your installation. When you install Oracle Audit Vault, Oracle Universal Installer uses a range of port numbers. If another process is using the first default port number it finds, then it checks for the next free port number.

### 1.3.5 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 for the Oracle Audit Vault components 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 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, as well as send e-mail notifications and trouble ticket alerts.

   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.

The details of the process flow for the Audit Vault components 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 Default Oracle Audit Vault Roles

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

Table 1-7 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.5. In a default Oracle Audit Vault installation, this account name is based on the default Oracle Audit Vault `AV_ADMIN` user account, with `dva` appended. For example, if during the installation you created `avadmin` as the `AV_ADMIN` user, then the `DV_ACCTMGR` account name is `avadmindva`.
`DV_OWNER` | During Audit Vault Server installation | Database Vault owner | Manages Oracle Database Vault roles and configuration. In a default Oracle Audit Vault installation, this account name is based on the default Oracle Audit Vault `AV_ADMIN` user account, with `dvo` appended. For example, if you created `avadmin` as the `AV_ADMIN` user, then the `DV_OWNER` account name is `avadmindvo`.

## 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. The agent for the OSAUD collector must reside on the same server as the source database. Table 1-8 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. The agent for the DBAUD collector must reside on a computer in which SQL*Net can communicate with the source database. Table 1-9 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. The agent for the REDO collector must reside on a computer in which SQL*Net can communicate with the source database. On Oracle RAC installations, the REDO collector can reside on just one database instance, because REDO logs are usually stored in a shared location. Table 1-10 shows more information about redo logs.

   To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Configuration tab, and then click Agent to display the Agent page. This page lists the agent, host (source database), port, and user.

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-8 lists the Oracle Database operating system audit settings that use the OSAUD collector.

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

Audit Trail | Audit Trail Setting | Comments
--- | --- | ---
Linux and UNIX-based platforms (`.aud`) | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `OS`. For fine-grained audit records: Not applicable. | None
Linux and UNIX-based platforms (`.xml`) | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `XML` or `XML, EXTENDED`. For fine-grained audit records: The `audit_trail` parameter of the `DBMS_FGA.ADD_POLICY` procedure is set to `DBMS_FGA.XML` or `DBMS_FGA.XML + DBMS_FGA.EXTENDED`. | `EXTENDED` writes SQL text and SQL bind information to the audit trail.
Linux and UNIX-based platforms (syslog) | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `OS`, and the `AUDIT_SYSLOG_LEVEL` parameter is set. For fine-grained audit records: Not applicable | More secure than audit records stored in operating system audit trail. Note: You cannot collect from compressed syslog files
Windows platform Windows Event Log | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `OS`. For fine-grained audit records: Not applicable | None
Windows platform Operating system XML files (`.xml`) | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `XML` or `XML, EXTENDED`. For fine-grained audit records: The `audit_trail` parameter of the `DBMS_FGA.ADD_POLICY` procedure is set to `DBMS_FGA.XML` or `DBMS_FGA.XML + DBMS_FGA.EXTENDED`. | `EXTENDED` writes SQL text and SQL bind information to the audit trail.

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

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

Audit Trail | Audit Trail Setting | Audited Operations | Comments
--- | --- | --- | ---
`SYS.AUD$` | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `DB` or `DB, EXTENDED`. For fine-grained audit records: Not applicable | `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$` | For standard audit records: Not applicable For fine-grained audit records: The `audit_trail` parameter of the `DBMS_FGA.ADD_POLICY` procedure is set to `DBMS_FGA.DB` or `DBMS_FGA.DB + DBMS_FGA.EXTENDED`. | Very specific user-defined audited conditions, such as the time a user modified a table column | None
`DVSYS.AUDIT_TRAIL$` | Not applicable. The Oracle Database Vault audit trail collects data even if Oracle Database auditing is disabled. | Oracle Database Vault audit activity specified by audit options on realms, command rules, and so on | None

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

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

Audit Trail | Audit Trail Setting | Audited Operations | Comments
--- | --- | --- | ---
Redo logs | Audit Vault capture rule (see Oracle Audit Vault Auditor's Guide | 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 instance configuration:

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

   See the Microsoft SQL Server product documentation for more information.

2. Ensure that the agent for the MSSQLDB collector was installed on the same computer as the Microsoft SQL Server source database. To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Configuration tab, and then click Agent to display the Agent page. This page lists the agent, host (source database), port, and user.

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

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

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

Table 1-11 describes the SQL Server audit trail.

Table 1-11 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-12 shows the Sybase ASE audit trail setting information.

3. Ensure that the agent for the SYBDB collector was installed on a computer in which SQL*Net can communicate with the source database. To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Configuration tab, and then click Agent to display the Agent page. This page lists the agent, host (source database), port, and user.

4. Configure the SYBDB collector to collect audit data from the Sybase ASE database, as described in Section 2.5.

Table 1-12 describes the Sybase ASE audit trail.

Table 1-12 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-13 shows the IBM DB2 audit trail setting information.

3. Ensure that the agent for the DB2DB collector was installed on the same computer as the IBM DB2 source database. To find the names and source database locations of existing agents, log in to Audit Vault Console, click the Management tab, and then click Collectors to display the Collectors page.

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

Table 1-13 describes the DB2DB audit trail.

Table 1-13 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 times that 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