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:

• Consolidating audit information from multiple systems across the enterprise

• Detecting data changes associated with regular and privileged users

• Protecting audit data from modification and tampering

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:

• Consolidates audit trails by mapping various audit data to a common audit format

• Secures all audit data across the enterprise

• Offers centralized audit policy management

• Enables analysis of audit data, including timely detection of violations

• Facilitates regulatory compliance

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 Oracle Audit Vault Architecture Overview"

Audit Vault Server consists of:

• Audit Data Store

• Audit Vault Console

• The following services:

  • Collector management and monitoring

  • Report management

  • Alert management

  • Audit settings management to establish your policy management

  • Published data warehouse that can be used with reporting tools like Oracle Business Intelligence Publisher to create customized reports

  • Audit data collection and storage management

  Configuration services assist in defining information about what sources are known to Oracle Audit Vault. Oracle Audit Vault stores information (metadata) about the sources of audit data and policy information (database audit settings).

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 Audit Vault Architecture (Detailed View)"

Audit Vault Server

Audit Vault Server consists of:

• OC4J: Oracle container for Web applications consisting of:

  • Audit Vault Console – User interface to manage Audit Vault. Reports, Audit Policy Manager, and so forth

  • Oracle Enterprise Manager Database Control console – User interface to manage the raw audit data store or audit repository database

  • Management Framework – Sends management commands to the Audit Vault Agent to start or stop agents and collectors, collect metrics, receive management commands from AVCTL, AVCA, and AVORCLDB command-line interfaces using HTTP protocol or HTTPS mutual certificate-based authentication (see Section 2.1).

  • Audit Policy System – A service to retrieve and provision audit settings on the source; and a system to create and manage alerts raised by audit events 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 Audit Vault users

  • Configuration Files – Files used by Audit Vault for networking, preferences, and so forth.

• Configuration and Management Tools – Utilities used to configure and manage Oracle Audit Vault, such as the AVCA, AVCTL, and AVORCLDB command-line utilities. They let you define and configure information about what sources are known to Oracle Audit Vault. Oracle Audit Vault stores information (metadata) about the sources of audit data and policy information (database audit settings and alerts).

• Logs: Informational and error messages for Oracle Audit Vault (see Section 6.1)

• Audit repository: Oracle database to consolidate and manage audit trail records, consisting of:

  • Raw audit data store – A table space with a single data file where audit records are inserted as rows into a set of partitioned tables

  • Warehouse schema – Open schema of normalized audit trail records. This is a published data warehouse that can be used with reporting tools like Oracle Business Intelligence Publisher to create customized reports

  • Job scheduler – Database jobs used to populate and manage the warehouse

  • Alerts – Queue maintains alerts

  • Apply – Process used by the REDO collector to insert before or after values of data

Audit Vault Agents

Audit Vault Agents consists of:

• OC4J: Oracle container for Web applications consisting of:

  • Audit Vault Collector Manager – Receives management commands from Audit Vault Server to start and stop collectors, collect and return metrics, and so forth

  • Audit Settings Manager – Receives commands from Oracle Audit Vault to extract audit settings from a source.

• Database Client: Infrastructure to communicate to the audit repository, consisting of:

  • Oracle Wallet – Contains credentials to authenticate Audit Vault users

  • Configuration Files – Files used by Audit Vault for networking, preferences, and so forth.

• Configuration and Management Tools: Utilities used to configure and manage Audit Vault, such as the AVCA, AVCTL, and AVORCLDB command-line utilities

• Logs: Informational and error messages for Audit Vault (see Section 6.1)

• Collectors: The type of collectors deployed by the Audit Vault Agents include:

  • OSAUD – Collector (for Linux and UNIX platforms) to extract to audit records from the operating system files (audit logs)

    Note:

    XML files are not supported in the OSAUD collector.

  • OSAUD – Collector (for Windows platforms) to collect audit records from the event logs. This EVTLOG collector type collects audit data only from the source installed on the same system where the Windows agent and this collector type are running.

  • DBAUD – Collector to extract audit records from the Oracle Database SYS.AUD$ dictionary table and SYS.FGA_LOG$ dictionary table

  • REDO – Collector using Oracle Streams technology to retrieve logical change records from the REDO logs

  OSAUD and DBAUD collectors send valid and invalid audit records, get configuration information, get and send recovery context, and send error records using OCCI/JDBC password-based authentication or certificate-based authentication (see Section 2.2).

Audit Vault Source

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

• SYS.AUD$ dictionary table and SYS.FGA_LOG$ dictionary table that are collected by the DBAUD collector

• Operating system audit trail files stored on Linux and UNIX-based systems and event logs stored on Windows systems that are collected by the OSAUD collector

• Redo logs containing logical change records of before and after values in which a REDO collector using Oracle Streams technology utilizes a Capture process to read the data and a Propagate process to transmit it.

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
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 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.
AV_AUDITOR	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.
AV_AGENT	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.
AV_SOURCE	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.
AV_ARCHIVER	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.
DV_OWNER	During Server installation	Database Vault owner	Manages Oracle Database Vault roles and configuration.
DV_ACCTMGR	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 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	Yes	Yes	Yes
Data manipulation language (DML)	Yes	Yes	Yes
Data definition language (DDL)	Yes	Yes	Yes
Before and after values	No	No	Yes
Successes and failures	Yes	Yes	No
SQL text	Yes (for SYS)	Yes	No
SYS auditing	Yes	No	Yes
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	REDO
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	DBAUD
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	DBAUD
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	OSAUD
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	OSAUD

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
Exception	Network Error, System Error	Error conditions or exceptional events
Uncategorized	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:

• Oracle Audit Vault provides the ability to create audit policies (audit settings) and provision the policies to the various audit sources within the enterprise. This feature, controlled by the user granted the AV_AUDITOR role, enables you to efficiently create and apply audit settings for compliance and security requirements.

• Oracle Audit Vault uses an alert mechanism that is especially useful when audit data must be monitored on a real-time basis for particularly sensitive systems. This capability, also controlled by the user granted the AV_AUDITOR role, provides the ability to configure and apply rule conditions for these types of systems when an alert action occurs, raise alerts, and enqueue alert records for prompt notice and processing. The alerting mechanism raises the level of early detection of problems, which enables administrators to act promptly rather than after the fact.

• Users granted the AV_ADMIN role schedule the refreshing, purging, and reloading from archives of audit data in the data warehouse for reporting and analysis purposes. Users granted the AV_AUDITOR role can then generate standard (out-of-the-box) reports on a regular basis to meet compliance guidelines. In addition, this same user can create specialized or custom reports to meet specific requirements.

• Oracle Audit Vault employs a highly secure model for its audit data warehouse, thus restricting access to audit trail and audit data to all system administrators. Oracle Database Vault is used to protect the audit data warehouse. Oracle Audit Vault allows only those very few select and trusted Audit Vault administrators access, as designated by their Audit Vault administrative role.

• Oracle Audit Vault provides command-line utilities: Audit Vault Configuration Assistant (AVCA), Audit Vault Control (AVCTL), and an Audit Vault Oracle Database (AVORCLDB) for configuration and management tasks. Oracle Audit Vault also provides an Audit Vault Console that mandates a separation of duties to facilitate administration and configuration tasks. Audit Vault provides administrators with an easy-to-learn interface to configure and manage Audit Vault. As an additional option during Oracle Audit Vault installation, an administrator granted the AV_ADMIN role can be granted the AV_AUDITOR role and manage the entire system.

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:

• See Oracle Audit Vault Best Practices for specific information and recommendations at the Oracle Audit Vault Web site

  http://www.oracle.com/technology/products/audit-vault/index.html
  
  

• See OracleMetaLink at the Web site:

  http://metalink.oracle.com
  
  

  If you do not have a current Oracle Support Services contract, then you can access the same information at

  http://www.oracle.com/technology/support/metalink/content.html
  

• See the Oracle Audit Vault Discussion Forums at the Web site

  http://forums.oracle.com/forums/forum.jspa?forumID=391