7/15

# 1 Introducing Oracle Audit Vault for Auditors

This chapter contains:

- How Do Auditors Use Oracle Audit Vault?

- General Steps for Using Oracle Audit Vault

- Database Requirements for Collecting Audit Data

- Starting the Oracle Audit Vault Console

- Ensuring That the Oracle Audit Vault Collectors Can Collect Data

## 1.1 How Do Auditors Use Oracle Audit Vault?

Oracle Audit Vault collects audit data from multiple databases and then consolidates this data in a set of audit reports. You can collect audit data from multiple instances of the following database products:

- Oracle Database (including Oracle Real Application Clusters and Oracle Data Guard)

- Microsoft SQL Server

- Sybase Adaptive Server Enterprise (ASE)

- IBM DB2

Before you, as an auditor, can use Oracle Audit Vault, an Audit Vault administrator must configure the Audit Vault Server to connect to your source databases. Oracle Audit Vault then collects the audit data that these databases generate, organizes the data, and provides it to you in a variety of reports. For Oracle databases, you can create policies and collect data from redo log files. For all four database products, you can create alerts to help you detect security threats to these databases. For example, an alert can notify you when a system administrator tries to view sensitive application data, such as employee salaries. In addition to the Oracle Audit Vault reports, you can design reports using another tool, such as Oracle Business Intelligence, or with third-party products. To manage Oracle Audit Vault policies, alerts, and reports, you use the Audit Vault Console.

The Oracle Audit Vault default reports are designed to satisfy standard compliance regulations, such as those mandated by the Sarbanes-Oxley Act. You can create user-defined versions of these reports for specific needs. For example, you can create reports to track activities that occur outside of normal office hours, or to track the activities of specific users.

The audit policies feature lets you manage audit policies for Oracle Database source databases. Because Oracle Audit Vault centralizes audit settings for Oracle Database, your job as an auditor is easier and more efficient. You can create, manage, and monitor audit information from one location. This also makes it easier to demonstrate the compliance policy of your company to outside auditors.

The audit data collected by Oracle Audit Vault is stored in its own secure data warehouse repository, where an administrator can use Oracle Database Vault and Oracle Advanced Security to prevent tampering with the audit data.

## 1.2 General Steps for Using Oracle Audit Vault

To use Oracle Audit Vault, follow these general steps:

- Step 1: Ensure That the Source Databases Are Collecting Audit Data

- Step 2: Create Audit Policies for Oracle Database Data

- Step 3: Optionally, Create and Monitor Alerts

- Step 4: View and Customize the Oracle Audit Vault Reports

- Step 5: Respond to Reports and Alerts

### 1.2.1 Step 1: Ensure That the Source Databases Are Collecting Audit Data

Check that auditing is enabled in the databases from which you want to collect audit data and that the Oracle Audit Vault collectors are working. For source databases, there are recommended audit settings that your database administrator should consider having in place. Your database administrator also should ensure that these databases are properly configured to send audit data to the Audit Vault Server.

See Section 1.3 and Section 1.5 for more information.

### 1.2.2 Step 2: Create Audit Policies for Oracle Database Data

You use the Audit Vault Console to manage audit policies for Oracle Database source databases. Section 1.4 explains how to start the Audit Vault Console.

You can create policies for the following kinds of data:

- SQL statements. You can audit statements that users use when attempting to query the database or modify data, such as `SELECT` or `UPDATE`.

- Database Schema Objects. You can audit actions that users may try to perform on database objects, tables, or views.

- Database Privileges. You can audit the use of a system privilege, such as `SELECT ANY TABLE`. In this kind of auditing, Oracle Audit Vault records SQL statements that require the audited privilege to succeed.

- Fine-grained audit conditions. You can audit specific activities that take place in the database, such as whether an IP address from outside the corporate network is being used, or if specific table columns are being modified.

- Redo log data. You can capture data from redo log files. The redo log files store all changes that occur in the database. Every instance of an Oracle database has an associated redo log to protect the database in case of an instance failure. In Oracle Audit Vault, the capture rule specifies DML and DDL changes that should be checked when Oracle Database scans the database redo log.

For SQL statements, objects, privileges, and fine-grained auditing data, you create audit policies. For redo log data, you create a capture rule.

Chapter 2, "Creating Oracle Audit Vault Policies and Alerts" describes how to create audit policies and capture rules.

### 1.2.3 Step 3: Optionally, Create and Monitor Alerts

You can create either warnings or critical alerts that are triggered when certain events occur in an Oracle Database, SQL Server, Sybase ASE, or IBM DB2 database. You can configure the e-mail notifications or trouble tickets in response to the alert. Oracle Audit Vault alerts enable you to detect threats, which helps keep systems in compliance with internal and external policies. After you create the alerts, you can monitor them in the Audit Vault Console.

Section 2.12 explains how you can configure e-mail and trouble ticket notifications, and create and monitor alerts.

### 1.2.4 Step 4: View and Customize the Oracle Audit Vault Reports

Oracle Audit Vault automatically populates its reports with the audit data from your source databases. You can view this data by selecting from the reports provided in the Audit Vault Console Default Reports, Compliance Reports, and User-Defined Reports pages. The reports are organized by commonly used categories, including categories for compliance regulations.

You can perform the following actions with the reports:

- Create user-defined reports to filter specific data.

- Send the report to other users as a PDF file.

- Schedule the report to be generated at specific times and then sent to users as a PDF file. You can create an e-mail distribution list, called a profile, to be used specifically for different types of reporting and alert activities.

Oracle Audit Vault has an open data warehouse schema, which you can use to build custom reports using Oracle Application Express, business intelligence tools such as Oracle Business Intelligence Publisher, or third-party business intelligence tools.

Chapter 3, "Using Oracle Audit Vault Reports" explains how to view and customize Oracle Audit Vault reports.

### 1.2.5 Step 5: Respond to Reports and Alerts

At this stage, the Oracle Audit Vault reports and alerts are generating as Audit Vault monitors your source databases.

When you review an Audit Vault report, you can annotate and attest the report, which is described in Section 3.7.

When you are notified of an alert, you can take the following actions:

- Notify other users of the alert so that they can take the appropriate actions.

- Log a trouble ticket if one is necessary. In this release, you can log trouble tickets to the BMS Remedy Service Management trouble ticketing system. You can design trouble ticket templates to be used for different types of trouble ticket scenarios.

- View notes that other users may have created for the alert report.

- Set a status for the alert, such as `NEW` or `CLOSED`.

Section 2.13 explains how to respond to an alert.

## 1.3 Database Requirements for Collecting Audit Data

This section contains:

- Requirements for Oracle Database

- Requirements for SQL Server, Sybase ASE, and IBM DB2 Databases

### 1.3.1 Requirements for Oracle Database

This section contains:

- Ensuring That Auditing Is Enabled in the Source Database

- Using Recommended Audit Settings in the Source Database

#### 1.3.1.1 Ensuring That Auditing Is Enabled in the Source Database

Before Oracle Audit Vault can collect audit data from the source databases, auditing must be enabled in those databases. A database administrator can check the type of auditing your database uses by logging in to SQL*Plus and running the appropriate command.

For example, to check if standard auditing is enabled:

    SQL> SHOW PARAMETER AUDIT_TRAIL

    NAME                   TYPE        VALUE
    ---------------------- ----------- -----------
    audit_trail            string      DB

This output shows that standard auditing is enabled and audit records are being written to the database audit trail.

For fine-grained auditing, you can query the `AUDIT_TRAIL` column of the `DBA_AUDIT_POLICIES` data dictionary view to find the audit trail types that are set for the fine-grained audit policies on the database. For more information, see Oracle Database Security Guide.

Table 1-1 describes the audit trail types and their corresponding Audit Vault collectors.

Table 1-1 Oracle Database Audit Trail Types and Corresponding Collectors

Audit Trail Type | How Enabled | Corresponding Collector
--- | --- | ---
Database audit trail | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `DB` or `DB, EXTENDED`. 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`. | DBAUD
Operating system audit trail | For standard audit records: The `AUDIT_TRAIL` initialization parameter is set to `OS`, `XML`, or `XML, EXTENDED`. For syslog audit trails, `AUDIT_TRAIL` is set to `OS` and the `AUDIT_SYS_OPERATIONS` parameter is set to `TRUE`. In addition, the `AUDIT_SYSLOG_LEVEL` parameter must be set. 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`. | OSAUD
Redo log files | The table that you want to audit must be eligible. See "Creating Capture Rules for Redo Log File Auditing" for more information. | REDO

#### 1.3.1.2 Using Recommended Audit Settings in the Source Database

After your database administrator checks that auditing is enabled, Oracle recommends that the following areas of the database have auditing enabled:

- Database schema or structure changes. Use the following `AUDIT` SQL statement settings:

  - `AUDIT ALTER ANY PROCEDURE BY ACCESS;`

  - `AUDIT ALTER ANY TABLE BY ACCESS;`

  - `AUDIT ALTER DATABASE BY ACCESS;`

  - `AUDIT ALTER SYSTEM BY ACCESS;`

  - `AUDIT CREATE ANY JOB BY ACCESS;`

  - `AUDIT CREATE ANY LIBRARY BY ACCESS;`

  - `AUDIT CREATE ANY PROCEDURE BY ACCESS;`

  - `AUDIT CREATE ANY TABLE BY ACCESS;`

  - `AUDIT CREATE EXTERNAL JOB BY ACCESS;`

  - `AUDIT DROP ANY PROCEDURE BY ACCESS;`

  - `AUDIT DROP ANY TABLE BY ACCESS;`

- Database access and privileges. Use the following `AUDIT` SQL statements:

  - `AUDIT ALTER PROFILE BY ACCESS;`

  - `AUDIT ALTER USER BY ACCESS;`

  - `AUDIT AUDIT SYSTEM BY ACCESS;`

  - `AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS;`

  - `AUDIT CREATE SESSION BY ACCESS;`

  - `AUDIT CREATE USER BY ACCESS;`

  - `AUDIT DROP PROFILE BY ACCESS;`

  - `AUDIT DROP USER BY ACCESS;`

  - `AUDIT EXEMPT ACCESS POLICY BY ACCESS;`

  - `AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS;`

  - `AUDIT GRANT ANY PRIVILEGE BY ACCESS;`

  - `AUDIT GRANT ANY ROLE BY ACCESS;`

  - `AUDIT ROLE BY ACCESS;`

### 1.3.2 Requirements for SQL Server, Sybase ASE, and IBM DB2 Databases

Ensure that auditing is enabled in these databases. You also should ensure that they are correctly configured to send audit data to the Audit Vault Server. A database administrator can check these requirements for you. For more information, check the documentation for these three products and Oracle Audit Vault Administrator's Guide.

## 1.4 Starting the Oracle Audit Vault Console

To start the Audit Vault Console:

1. From a browser, enter the following URL:

       http://host:port/av

   In this specification:

   - `host` is the server where you installed Oracle Audit Vault

   - `port` is the Audit Vault Console HTTP port number

   For example:

       http://192.0.2.1:5700/av

   If you are unsure of the URL, from the terminal window that you use for the Audit Vault Server, enter the following command, which displays the URL that starts the Audit Vault Console:

       $ avctl show_av_status

2. In the Login page, enter your user name and password. From the Connect As list, select AV_AUDITOR. Then click Login.

   The Dashboard page appears and displays information about configured alerts and audit trail activity.

   Description of the illustration dashboard.gif

   From the Dashboard page, you can do the following:

   - View audit data from a range of dates. To view the audit data, which includes data such as the top five objects accessed and failed logins, specify the range you want, and then click the Go button. To automatically refresh the data every 60 seconds, click the Refresh every 60 seconds check box, or manually refresh it by clicking the Refresh button.

   - Check alerts. The Dashboard page displays recently raised alerts, as well as all warning and critical alerts.

   - Check attestation actions. The Dashboard page displays a list of reports that you may need to attest.

   - Create Oracle Database audit policies and alerts. Chapter 2, "Creating Oracle Audit Vault Policies and Alerts" explains how to create policies and alerts for an Oracle database.

   - Access audit reports. You can view audit information that has been collected in the Oracle Audit Vault reports. Optionally, you can control the display of data and create user-defined reports. See Chapter 3, "Using Oracle Audit Vault Reports" for more information.

   - Ensure that the Oracle Audit Vault collection agents are working. Section 1.5 explains how to ensure that these agents are collecting audit data.

## 1.5 Ensuring That the Oracle Audit Vault Collectors Can Collect Data

This section contains:

- About Oracle Audit Vault Data Collection

- Checking the Status of the Source Database Collection Agents

- What Happens if the Source Database Collection Agents Were Not Active?

### 1.5.1 About Oracle Audit Vault Data Collection

The Oracle Audit Vault collection agents are responsible for the connection between the source database and the Audit Vault Server while collectors collect the audit data. In the Audit Vault Console, you can check the status of the collection agents and collectors. If you cannot access Oracle Database audit policies, or if the Oracle Audit Vault default reports do not show any information, then the collection agents may not be working, or the source database has been shut down. See also Oracle Audit Vault Administrator's Guide for additional troubleshooting tips for the reports.

### 1.5.2 Checking the Status of the Source Database Collection Agents

To check the status of the source database collection agents:

1. Log in to the Audit Vault Console as a user who has been granted the `AV_AUDITOR` role.

   Section 1.4 explains how to log in to the Audit Vault Console.

2. Click the Settings tab.

3. Click the Collection Status secondary tab.

The Collection Status page shows the following information for collectors:

- Source name. The name of the audit source database where the audit data is being collected

- Collector Name. Name of the collector

- Agent Name. The name of the agent with which this collector is associated

- Bytes Per Sec. Number of bytes per second it takes to retrieve the audit data

- Records Per Sec. Number of audit records that are being retrieved per second

- Is Alive. Whether the collector is running or not. When the collector is up, a green up arrow indicator is displayed. When the collector is down, a red down arrow indicator is displayed. When there is a problem, an error is displayed. If the collector is not working, then contact your Oracle Audit Vault administrator.

Table 1-2 summarizes the database collector types.

Table 1-2 Database Collector Types Provided by Oracle Audit Vault

Database | Collectors | Description
--- | --- | ---
Oracle | DBAUD | Collector that performs the following: Extracts audit records from the Oracle Database audit trail. For the standard audit trail, it extracts records from the `SYS.AUD$` system table. For fine-grained auditing, it extracts audit events from the `SYS.FGA_LOG$` system table. Extracts audit records from the Oracle Database Vault audit trail `DVSYS.AUDIT_TRAIL$` table
Oracle | OSAUD | Collector that performs the following: For Linux and UNIX platforms: Extracts audit records from the operating system files (audit logs) and XML (`.xml`) files) For Linux and UNIX platforms: SYSLOG Collector to extract audit records from the system audit trail where database audit trail records are written to a syslog file For Microsoft Windows: EVTLOG Collector to extract audit records from the system audit trail where database audit trail records are written to the Event Log
Oracle | REDO | Collector using Oracle Streams technology to retrieve logical change records from the redo logs.
SQL Server | MSSQLDB | Collector (for Windows platforms) to extract audit records from Microsoft SQL Server databases from the Windows Event logs, Server-side trace files, and C2 auditing logs.
Sybase ASE | SYBDB | Collector to extract audit records from the Sybase databases audit trail logged in audit tables in the `SYBSECURITY` database.
IBM DB2 | DB2DB | Collector to extract records from the ASCII text file in which IBM DB2 generates audit data.

### 1.5.3 What Happens if the Source Database Collection Agents Were Not Active?

If the collection agents were not active, then no audit data is lost, as long as the source database continues to collect the audit data. When you restart the collection agent, it captures the audit data that the source database had collected during the time the collection agent was inactive.