Skip Headers
Oracle® Audit Vault Administrator's Guide
10g Release 2 (10.2.2)

Part Number B25321-02
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

1 Introduction to Oracle Audit Vault

Oracle Audit Vault is a powerful enterprisewide audit solution that efficiently consolidates, detects, monitors, alerts, and reports on audit data for security auditing and compliance. Oracle Audit Vault provides the ability to consolidate audit data and critical events into a centralized and secure audit warehouse.

Why Use Oracle Audit Vault?

Compliance regulations and legislation such as the U.S. Sarbanes-Oxley Act (SOX), U.S. Gramm-Leach-Bliley Act (GLBA), U.S. Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry (PCI) Data Security Standard, Japan privacy laws, and European Union privacy directives require businesses to secure business and personal data related to customers, employees, and partners, and to demonstrate compliance with these regulations by auditing users, activities, and associated data.

Businesses use a wide variety of systems, databases, and applications that produce vast quantities of audit log data. Businesses must consolidate and monitor this data for a holistic view of enterprise data access. Auditors must analyze the audit log data in a timely fashion across disparate and heterogeneous systems. To facilitate the process, it is essential that audit data from all systems reside in a single audit data warehouse that is secure, scalable, reliable, and highly available.

Oracle Audit Vault solves these security and audit problems by:

1.1 Overview of Oracle Audit Vault

Historically, audit data has resided in silo across the enterprise with the possibility that the powerful system users can tamper with the audit data. Audit data can be a strong deterrent to information theft, unauthorized access, and tampering if it can be securely collected and consolidated from multiple databases and sources to generate the required compliance and security audit reports. Oracle Audit Vault enables organizations to collect and consolidate audit data from multiple sources, store it in a secure audit warehouse, detect conditions of interest, and produce reports.

Auditing plays a key part in protecting sensitive business information. Tackling the compliance and security challenges requires an enterprise audit solution. Audit trails in the enterprise must be consolidated into an enterprisewide audit trail. In this regard, Oracle Audit Vault accomplishes the following:

Oracle Audit Vault provides the mechanisms to collect audit data. Oracle Audit Vault supports the collection of audit data generated by Oracle9i Database release 2, Oracle Database 10g release 1, and Oracle Database 10g release 2. The audit data can be collected from the Oracle Database audit trail tables, database operating system audit files, and database redo logs to capture before or after value changes.

The consolidation of audit trails and audit data enables the provision of value-added audit services for all systems in the enterprise in a consistent manner. It also enables enterprisewide capabilities that are impossible or very difficult to provide without a consolidated audit solution.

The increasingly sophisticated nature of information theft and insider security threats requires businesses to not only protect sensitive information, but also monitor access to sensitive information by privileged and powerful users (such as database administrators (DBAs), developers, and managers). As privileged users have ongoing and direct access to sensitive data, it is critical to implement monitoring controls to ensure compliance.

Oracle Audit Vault provides valuable insight into who did what, to which data, and when, including privileged users who have direct access to the database. Understanding who accessed, altered, updated, deleted, or merely viewed sensitive data is essential to protecting data and satisfying compliance requirements. Oracle Audit Vault provides the capability to detect, monitor, alert, and report the history of privileged user changes, schema modifications, and even data-level access. Audit policies and settings can be defined and managed from Oracle Audit Vault for the audit sources throughout the enterprise. In addition to improving security, centralized audit policy management reduces the cost and complexity of auditing across the business.

Oracle Audit Vault can be configured to provide alerts relating to suspicious activities. It provides an alert management capability to mitigate the insider security threat. It can generate alerts for system-defined events and user-defined events when they occur. For instance, an alert can be sent whenever a privileged user creates a user without permission or attempts to view sensitive data. Oracle Audit Vault continuously monitors the data collected, and generates alerts for any anomalies or abnormal activities.

1.2 Oracle Audit Vault Architecture

Figure 1-1 shows an overview of the Oracle Audit Vault architecture. The architecture consists of a set of services and its collection system working within an enterprise. This set of services helps to facilitate storage management, policy enforcement, alerting, analysis, reporting, and activities. The collection infrastructure enables the utilization of audit collectors that function as adaptors between an audit source and Oracle Audit Vault Server.

Figure 1-1 Oracle Audit Vault Architecture Overview

Description of Figure 1-1 follows
Description of "Figure 1-1 Oracle Audit Vault Architecture Overview"

Audit Vault Server consists of:

An Audit Vault Agent provides run-time support for audit data collection by Audit Vault collectors. It also contains the audit data collectors for Oracle Database sources. The DBAUD, OSAUD, and REOD collectors are provided.

Figure 1-2 shows a detailed overview of the Oracle Audit Vault architecture for the Audit Vault Server and Audit Vault Agent components. As a source database, audit events captured in audit logs and tables for the Oracle Database are parsed into audit records and sent to the Audit Vault raw audit data store for storage and further analysis within a published data warehouse and from which reports can be generated.

Figure 1-2 Audit Vault Architecture (Detailed View)

Description of Figure 1-2 follows
Description of "Figure 1-2 Audit Vault Architecture (Detailed View)"

Audit Vault Server

Audit Vault Server consists of:

Audit Vault Agents

Audit Vault Agents consists of:

Audit Vault Source

The audit data source consists of Oracle Database audit trails stored in:

Oracle Audit Vault Interfaces and Administrator Access

Oracle Audit Vault provides an Audit Vault Console and a set of command-line utilities, the Audit Vault Configuration Assistant (AVCA) (see Appendix A), Audit Vault Control (AVCTL) (see Appendix B), and Audit Vault Oracle Database (AVORCLDB) (see Appendix C) to manage the system. These components provide the ability to manage and monitor agents and collectors, populate the data warehouse, and manage audit data storage.

Auditors, compliance, and information technology (IT) security can use built-in reports based on user access and activity such as failed login attempts, use of system privileges, and changes to database structures. The drill-down capability offered through the Oracle Audit Vault Console provides full visibility into the details of the what, where, when, and who of the audit events. In addition, the Audit Vault Console can be used to monitor the alerts and the audit events across the enterprise.

Audit Vault administrators are assigned different roles and gain access to Oracle Audit Vault to manage various components based on the role assigned. Table 1-1 describes the various Audit Vault administrator roles and the tasks permitted for each role.

Oracle Database Vault is used to protect the audit data warehouse from unauthorized access. See Chapter 2 and Oracle Database Vault Administrator's Guide for more information. Oracle Database Vault roles are essential for creating database user accounts and granting roles to Audit Vault administrators.

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

Role When Is Role Granted? Role Is Granted to Whom Description


During Server installation

Audit Vault administrator

Accesses Oracle Audit Vault services to administer, configure, and manage a running Oracle Audit Vault system. A user granted this role configures and manages audit sources, agents, collectors, the setup of the source with the agent, and the warehouse. A user is created and granted this role during the Audit Vault Server installation. Only the user granted the AV_ADMIN role can grant the appropriate role (AV_ADMIN, AV_AUDITOR, AV_AGENT, or AV_SOURCE) to other Audit Vault administrators.


During Server installation

Audit Vault auditor

Accesses 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 granted this role manages central audit settings and alerts. This user also uses the data warehouse services to further analyze the audit data to assist in looking for trends, intrusions, anomalies, and other items of interest. A user is created and granted this role during the Audit Vault Server installation.


Before Agent installation

Agent software component

Manages agents and collectors by starting, stopping, and resetting them. A user is created and granted this role prior to an agent installation. The Audit Vault Agent software uses this role at run time to query Oracle Audit Vault for configuration information.


Before source registration

Collector software component

Manages the set up of the sources for audit data collection. A user is created prior to source and collector configuration and granted this role upon adding a source to Audit Vault using the AVORCLDB add_source command. The collector software uses this role at run time to send audit data to Audit Vault.


Before archiving audit data

Audit Vault archiver

Archives and deletes audit data from Audit Vault and cleans up old unused metadata and alerts that have already been processed. A user granted this role can archive raw audit data.


During Server installation

Database Vault owner

Manages Oracle Database Vault roles and configuration.


During Server installation

Database Vault account manager

Manages database user accounts.

It is important to protect and ensure the integrity of the audit trail data against modification and tampering. Either external or internal intruders might try to "cover their tracks" by modifying audit trail records. Oracle Audit Vault delivers a "locked-down" audit warehouse that has been designed for the sole purpose of protecting and securing audit data. Access to the Oracle Audit Vault is only allowed for the predefined roles described in Table 1-1. All other roles, including the database administrator (DBA), are denied access to the audit data.

Figure 1-3 shows a detailed view of the various Audit Vault usage scenarios for which each of the Oracle Audit Vault administrator roles described in Table 1-1 plays an important role.

Audit Vault usage scenarios can be grouped as follows:

Monitor, Detect, Alert, and Report Usage Scenario

An auditor (the user granted AV_AUDITOR role) creates, views, and manages both internal and external, detail and summary types of reports for compliance purposes. A security officer inspects and further evaluates system-generated alerts logged to the alerts table raised by events that meet specific alert conditions. An auditor administrator also sets and views Audit Vault audit policies.

Archive Usage Scenario

An audit archiver (the user granted AV_ARCHIVER role) configures and manages the data life cycle to automate audit data life-cycle management on an ongoing basis as part of the archiving operation.

Collect Usage Scenario

A source user must first be created (the user granted AV_SOURCE role) before an Audit Vault administrator (user granted AV_ADMIN role) can add the source and collector to Audit Vault.

Administration and Management Usage Scenario

An Audit Vault administrator (the user granted AV_ADMIN role) oversees the monitoring and management of the audit data consolidation operation. This user also performs audit data collection tasks, configuring collectors (adding sources and collectors) to Oracle Audit Vault. This user monitors overall Oracle Audit Vault system security.

Figure 1-3 Usage Scenario Showing Important Roles of Audit Vault Administrators

Description of Figure 1-3 follows
Description of "Figure 1-3 Usage Scenario Showing Important Roles of Audit Vault Administrators"

1.3 Oracle Audit Vault Agents and Collectors

This section describes Oracle Audit Vault agents and collectors, the audit service, and the types of tasks performed by these services.

Agent – Provides run-time support for audit data collection by Audit Vault collectors. An agent loads the collectors, provides them with a connection to the Audit Vault audit service for sending audit data, handles calls from the Audit Vault management service and routes them to the appropriate collectors, and sends the Audit Vault management service run-time metrics on the collectors.

Collectors – Starts and stops the primary collection component between the audit source and Audit Vault. The collector will read or interpret native log records and send them to Audit Vault through the audit service. On startup or on a reset, the collector reads the audit configuration object provided by the audit service, which contains the recovery information, configuration information, and policy information sent to it from Oracle Audit Vault.

Oracle Audit Vault communicates with the audit data source through its agent. An agent is a program that runs on the Audit Vault Server system, on the system that hosts an audit data source, or on another independent system, and manages audit data collectors on behalf of the Audit Vault Server. Collectors rely on their agent to set up a connection with the Audit Vault service. Agents are also responsible for interacting with the management service to manage and monitor collectors. An agent reads the audit data from the audit data source, parses the data into audit records, and sends it to the raw audit data store within Audit Vault.

The management and monitoring service manages all collectors. It provides the ability to stop and start collectors based on a schedule, and stores metrics for each collector.

1.4 Selecting the Right Collector for Audit Data

Audit Vault implements an Oracle Database source type and three collector types that pull audit data from the database. The source type is called ORCLDB, and the three collector types are called DBAUD, OSAUD, and REDO. Each collector type retrieves audit records from different locations in the source Oracle database (see Figure 1-2). Table 1-2 lists the characteristics of the audit trail locations to help you determine for each Oracle Database source where to write the audit trail and which collector(s) should be deployed to move the audit data into the Audit Vault audit data repository.

Table 1-2 Characteristics of Oracle Database Audit Trail Locations

Audit Operation Operating System Log Database Audit Table Redo Log

Select statements




Data manipulation language (DML)




Data definition language (DDL)




Before and after values




Successes and failures




SQL text

Yes (for SYS)



SYS auditing




Other considerations

Separation of duties

Fine-grained audit data

Supplemental logging for all values

Table 1-3 shows the audit data sources for the Oracle Database source, the audit settings to initiate Oracle Database auditing, what is being audited, and the collectors that collect this audit data.

Table 1-3 Audit Data Sources for the Oracle Database Source Type

Audit Data Sources of Oracle Database Source Type Oracle Database Settings to Initiate Auditing What Is Being Audited Collector Name

Redo logs

Check output of AVORCLDB verify command on REDO collector at the agent for any recommended initialization parameter settings.

Committed data definition language (DDL) and data manipulation language (DML) statements, SYS privilege, before and after values, successes only


Database audit trail, where standard audit events are written to the database dictionary table SYS.AUD$

Set initialization parameter audit_trail=db, extended.

DDL and DML statements, SQL text, successes and failures


Fine-grained audit trail, where audit events are written to the database dictionary table SYS.FGA_LOG$

Set initialization parameter audit_trail=db, extended.

Value-based audit policies audit SELECT and DML statements (UPDATE, DELETE, or INSERT) on tables and views; allows monitoring data access based on content


Operating system files, where mandatory audit records are written and optionally, where Database audit trail (standard audit events) and fine-grained audit trail audit events are written to operating system audit logs

Set initialization parameter AUDIT_TRAIL parameter to OS and AUDIT_FILE_DEST parameter to the desired file in the directory specification.

DDL and DML statements, SYS privilege, successes and failures


Operating system-specific audit trails (system audit trail), where database audit trail records are written to Windows event log on Microsoft Windows systems or to a syslog on Linux systems

Set initialization parameters AUDIT_SYS_OPERATIONS to TRUE and AUDIT_FILE_DEST to the desired file in the directory, and on Linux systems AUDIT_SYSLOG_LEVEL to the valid <facility>.<level>.

DDL and DML statements, SYS privilege, successes and failures


See Also:

"Overview of Database Auditing" and "Fine-Grain Auditing" in the Database Security chapter in Oracle Database Concepts for an overview of database auditing. The Database Auditing: Security Considerations chapter in Oracle Database Security Guide for more detailed information about database auditing.

Each database collector and channel type for the Oracle Database source type works as explained in the following sections.

Collector for Oracle Database OS Audit Logs (OSAUD Collector) for Linux and UNIX Platforms

Audit Vault invokes the OSAUD collector agent program on the client system where the source database is running. The OSAUD collector reads and parses the operating system log files generated by the source Oracle database and sends the audit records generated to the raw audit data store (see Figure 1-2).

Collector for Oracle Database OS Event Logs (OSAUD Collector) for Windows Platforms

Audit Vault invokes the OSAUD collector agent program on the client system where the source database is running. The OSAUD collector reads and parses the operating system (OS) event log files generated by the source Oracle database and sends the audit records generated to the raw audit data store (see Figure 1-2). The mode for this collector type is EVTLOG.

Collector for Oracle Database DB Audit Logs: AUD$ and FGA_LOG$ (DBAUD Collector)

Audit Vault uses the DBAUD collector to retrieve audit records from an Oracle database audit trail stored in the SYS.AUD$ dictionary table and the fine-grained audit trail stored in the SYS.FGA_LOG$ dictionary table (see Figure 1-2). The collector opens an Oracle Call Interface (OCI) connection to the source database, periodically retrieves new audit records from these tables, and sends these records to the raw audit data store.

Collector for Oracle Database Redo Logs (REDO Collector)

Oracle Audit Vault also provides a REDO collector. The REDO collector uses Oracle Streams technology to retrieve logical change records (LCRs) from the REDO logs. It then converts these LCRs into audit records and sends them to Audit Vault. On the source database, a Streams capture process uses LogMiner to extract new LCRs from the REDO logs based on capture rules that are defined by the user. A Streams propagate process then forwards the LCRs to Audit Vault over a database link. On the Audit Vault side, a specially written apply handler converts these LCRs into audit records and stores them in the raw audit data store (see Figure 1-2).

1.5 Oracle Audit Vault Event Categories

Audit records are grouped into event categories based on the meaning of events (see Table 1-4). Similar events are grouped into the same category. For example, LOGON and LOGOFF events are both grouped into the USER SESSION category.

Table 1-4 Audit Vault Event Categories

Name Sample Events Description

Account Management

Create User, Alter User

Management of user accounts and profiles

User Session

Login, Alter Session

Creation and use of user sessions on the system

Object Management

Create Table, Drop Index, Alter Index

Creation and management of data items and resource elements

System Management

Create Tablespace, Shutdown Database, Install Service, Alter System

Management of services that are system level

Application Management

Create Procedure, Alter Package, Drop Java

Management of applications or code on a system

Role and Privilege Management

Create Role, Grant Privilege

Management of roles and privileges granted to users or services

Data Access

Insert into Table, Select from View

Association with a data item or resource for its content or services

Service and Application Access

Execute Procedure, Import/Export

Use of service or applications

Peer Association

Create a database link

Management of association with peer systems

Audit Command

Audit Actions, Audit Privileges, Change Audit Policy

Management of audit service


Network Error, System Error

Error conditions or exceptional events


Not applicable

Anything that does not belong to the previously mentioned categories

Invalid Record

Invalid audit records

Any audit records that are found to be invalid

1.6 Summary of Oracle Audit Vault Capabilities

Oracle Audit Vault has the following features that facilitate the task of managing audit data across an enterprise:

1.7 Getting Started

After installing the Audit Vault Server and Audit Vault Agents, you should complete the following general sets of tasks in this order:

  1. For Linux and UNIX platforms only: Check and set environment variables in the shells in which you will be interacting with the Audit Vault Server and the Audit Vault Agent (see Chapter 3).

    Check and set environment variables for ORACLE_HOME, ORACLE_SID, PATH, LD_LIBRARY_PATH (for Linux x86, Linux x86-64, and Solaris SPARC_64), SHLIB_PATH (for HP-UX), or LIBPATH (for AIX), as applicable in the shell in which you will be interacting with the Audit Vault Server. In the Audit Vault Server shell, you can run coraenv and oraenv scripts located in the /usr/local/bin directory to set these environment variables. Check and set environment variables for ORACLE_HOME, LD_LIBRARY_PATH, and PATH in the shell in which you will be interacting with the Audit Vault Agent.s In the Audit Vault Agent shell, you must set these environment variables manually using the setenv command. (see Chapter 3).

  2. Set up Audit Vault security (see Chapter 2).

    Security tasks include securing management communication between the server and agents, understanding Audit Vault roles, and encrypting network traffic between the server and client system. Before you go into production, Oracle recommends that you perform these tasks to secure management communications.

  3. Get started by configuring and managing Audit Vault components (see Chapter 3).

    Initial required configuration and management tasks include creating source users and giving them privileges to perform policy management for the OSAUD and DBAUD collectors and to work with the REDO collector, creating an Audit Vault source user and granting proxy connect privilege to this user through the Audit Vault agent user, verifying that the source is compatible for the collector type in the Audit Vault Agent home, adding sources, adding collectors, setting up the database link from the source to the agent, and verifying the connection using the wallet.

  4. Configure and Manage Audit Vault components (see Chapter 4).

    Additional configuration tasks can include adding, changing, and dropping agents, collectors, and audit data sources, scheduling data warehouse operations, setting up audit data storage management operations, and globally disabling and enabling alert processing for data warehouse load operations from an archive. Data warehouse scheduling tasks include setting the audit data refresh and purge schedules, as well as scheduling the reloading of archived audit data. Alert processing must be disabled when audit data is reloaded from an archive so that alerts are not reissued again and then enabled again when the warehouse is refreshed with fresh audit data. Perform these tasks initially to configure Audit Vault and thereafter only as components are reconfigured.

    Agents and collectors must be managed, such as stopping and starting them for maintenance purposes. Audit Vault administrators should view the history of refreshing, purging, and loading of the data warehouse with audit data. They can invoke immediate refresh, purge, and reload operations as needed. Audit Vault administrators should view the error message information and to monitor the general well-being of the system. These tasks are performed as needed.

1.8 Additional Resources

For more information about Oracle Audit Vault, see the following resources: