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 silos 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 (9.2)

• Oracle Database 10g release 2 (10.2)

• Oracle Database 11g release 1 (11.1)

• Microsoft SQL Server 2000

• Microsoft SQL Server 2005

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; and from Windows Event logs, Server-side Trace files, and C2 audit logs for SQL Server Databases.

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 Collection Agent provides run-time support for audit data collection by Audit Vault collectors. It also contains the audit data collectors for Oracle Database, and SQL Server Database sources. The DBAUD, OSAUD, and REDO collectors are provided for Oracle Database sources, and the MSSQLDB collector is provided for SQL Server Database sources.

Figure 1-2 shows a detailed overview of the Oracle Audit Vault architecture for the Audit Vault Server and Audit Vault Collection 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. Similarly, audit events captured in Windows Event logs, Server-side Trace files, and C2 audit logs for SQL Server Databases are all sent to the Audit Vault raw audit data store.

Figure 1-2 Audit Vault Architecture (Detailed View)

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

Audit Vault Server

Table 1-1 describes the Audit Vault Server components.

Table 1-1 Audit Vault Server Components

Components	Description
OC4J	Oracle container for Web applications consisting of: Audit Vault Administrator's Console – User interface to manage Audit Vault. Collection Agents, Collectors, and so forth Audit Vault Auditor's Console - User interface to manage Audit Vault. Audit Policy Manager, Reports, Alerts, 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 Collection Agent to start or stop collection agents and collectors, collect metrics, receive management commands from AVCTL, AVCA, AVORCLDB, and AVMSSQLDB command-line interfaces using HTTP protocol or HTTPS mutual certificate-based authentication (see Section 5.1). Audit Policy System – A service to retrieve and provision audit settings on the Oracle Database source; and a system to create and manage alerts raised by audit events from all sources 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, AVORCLDB, and AVMSSQLDB 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 (Oracle database audit setting and alerts defined for all incoming audit records).
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 partitioned table where audit records are inserted as rows Warehouse schema – Open schema of normalized audit trail records. This is a published data warehouse that 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 Collection Agents

Table 1-2 describes Audit Vault Collection Agent components.

Table 1-2 Audit Vault Collection Agent Components

Component	Description
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 an Oracle Database 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, AVORCLDB, and AVMSSQLDB command-line utilities
Logs	Informational and error messages for Audit Vault (see Section 6.1)
Collectors	Table 1-3 shows the type of collectors deployed by the Audit Vault Collection Agents and the audit trail from which audit records are extracted and collected.

OSAUD, DBAUD, and MSSQLDB 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 (see Section 5.2).

Table 1-3 Audit Vault Supported Collector Types by Audit Source and Audit Trail

Collector Type	Audit Source	Audit Trail
OSAUD	Oracle Database	On Linux and UNIX platforms: the operating system logs (audit logs) (SYS$AUD) (.aud) and XML (.xml) files) On Linux and UNIX-based platforms: the operating system logs or syslog On Windows platforms: the operating system Windows event log and operating system logs (audit logs) XML (.xml) files
DBAUD	Oracle Database	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
REDO	Oracle Database	Logical change records (LCRs) from the REDO logs
MSSQLDB	Microsoft SQL Server	C2 audit logs, Server-side trace logs, and Windows Event log

Audit Vault Sources

Table 1-4 shows the supported audit data sources from which audit records are extracted and collected from the audit trails described in Table 1-3.

Table 1-4 Audit Vault Supported Audit Data Sources

Audit Data Source	Releases Supported
Oracle Database	Releases 9.2.X, 10.1.X, 10.2.X, and 11.1.X for the OSAUD and DBAUD collector types. Enterprise Edition Releases 9.2.0.8, 10.2.0.3 and higher, 11.1.0.6, and higher for the REDO collector type.
Microsoft SQL Server Database	SQL Server 2000 and SQL Server 2005 on Windows 2000 Server and Windows 2003 Server (32 bit) platforms

Oracle Audit Vault Interfaces and Administrator Access

Oracle Audit Vault provides an Audit Vault Console and a set of command-line utilities (see Table 1-5) to manage the system.

Table 1-5 Audit Vault Command-Line Utilities

Command-Line Utility	Reference Information
Audit Vault Configuration Assistant (AVCA)	See Appendix A.
Audit Vault Control (AVCTL)	See Appendix B.
Audit Vault Oracle Database (AVORCLDB)	See Appendix C.
SQL Server Database (AVMSSQLDB)	See Appendix D.

These utilities provide the ability to configure and manage sources and collectors, manage and monitor collection 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 Auditor's 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-6 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 5 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-6 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, collection agents, collectors, the setup of the source with the collection 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 and AV_AUDITOR) 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	During Collection Agent registration	Collection Agent software component	Manages collection agents and collectors by starting, stopping, and resetting (stop and start) them. A user is created and granted this role (AVCA add_agent command) during collection agent registration. The Audit Vault Collection Agent software uses this role at run time to query Oracle Audit Vault for configuration information.
AV_SOURCE	During 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 add_source command. The collector software uses this role at run time to send audit data to Audit Vault.
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-6. 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-6 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.

Collect Usage Scenario

An Audit Vault source user is automatically created (the user granted AV_SOURCE role) to insert audit data from the audit trail data source into Audit Vault. This user is granted proxy connect privilege through the Audit Vault Agent user to accomplish this task.

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 Collection Agents and Collectors

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

Oracle Audit Vault communicates with the audit data source through its collector. A collection 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 collection agent to set up a connection with the Audit Vault service. Collection agents are also responsible for interacting with the management service to manage and monitor collectors. A collection 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.

Collection Agents – Provides run-time support for audit data collection by Audit Vault collectors. A collection 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 (stop and start), 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.

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 Audit Vault Deployment Options

This section describes Audit Vault Server and Audit Vault Collection Agent deployment options relative to the host system where the audited source database resides.

Audit Vault Server

The Audit Vault Server should be installed on its own host or a host that contains other repository databases such as Enterprise Manager Grid Control or the Oracle Recovery Manager (RMAN) repository database. This is done to ensure high availability of the Audit Vault Server system separate from the source data and to ensure a secure, consolidated audit trail.

For scalability and availability, the Audit Vault Server can optionally implement Real Applications Cluster (RAC) and Data Guard for disaster recovery.

Audit Vault Collection Agent

The Audit Vault Collection Agent can be installed:

• On the same host as the source database that is going to be audited

  This is the recommended deployment option. If the database audit trail destination is the operating system logs, the Audit Vault Collection Agent must be installed on the same hosts as those operating system files.

• On the Audit Vault Server host systems

  If the database audit trail destination is the database tables (SYS.AUD$, SYS.FGA_LOG$, or DVSYS.AUDIT_TRAIL$) then the Audit Vault Collection Agent can be installed on the Audit Vault Server host.

• On a host system separate from the Audit Vault Server and separate from the source database that is going to be audited

  If the database audit trail destination is the database tables, (SYS.AUD$, SYS.FGA_LOG$, or DVSYS.AUDIT_TRAIL$) then the Audit Vault Collection Agent may be installed on a different host from the audited database or Audit Vault Server.

In the case of Oracle RAC, decide on one instance to run the DBAUD and REDO collectors. The collection agent only needs to be installed on all instances if your are going to use the OSAUD collector and the audit files are local to that instance.

1.5 Selecting Sources and Deploying Collectors to Collect Audit Data

This section will help you select and deploy collectors based on the sources you select and the audit trails from which you want to collect audit data. Table 1-7 shows the supported sources, source types, and collector types for collecting audit data from these audit trails. See the database requirements for collecting audit data in Oracle Audit Vault Auditor's Guide for more information.

Table 1-7 Supported Sources, Source Types, Collector Types, and Audit Trails

Source	Source Type	Collector Types	Audit Trail
Oracle Database	ORCLDB	OSAUD (see Table 1-8) DBAUD (see Table 1-9) REDO (see Table 1-10)	Operating system logs Database Audit tables Redo logs
SQL Server Database	MSSQLDB	MSSQLDB (see Table 1-12)	C2 audit logs, server-side trace logs, Windows Event log

You can use the following decision tree to help choose which sources and collector types to register with Audit Vault to ensure you collect audit data from all necessary audit trails.

1. From what audit source do you want to collect audit records? (Oracle Database or SQL Server Database)

   1. If collecting from an Oracle Database source, you want to register this source. Continue to (2).

   2. If collecting from a SQL Server Database source, you want to register this source. Continue to (3).

   If collecting from two or more different sources, repeat this source selection process for each different source.

2. Oracle Database Source

   From which Oracle Database audit trail do you want to collect audit data:

   
   a. Operating system logs? See Table 1-8 for information about this audit trail.
   b. Database tables? See Table 1-9 for information about this audit trail.
   c. Redo logs? See Table 1-10 for information about this audit trail.

   Each table (Table 1-8, Table 1-9, and Table 1-10) provides an overview of the Oracle Database audit trails, their respective audit settings at the source, the audited operations that can be implemented, and other important comments to help you choose from which audit trails to collect audit data.

   Table 1-8 Oracle Database Source (Source Type ORCLDB) and the OSAUD Collector

   Audit Trail	Audit Trail Settings	Audited Operations	Comments
   Operating System LogsFoot 1			More secure from privileged users
   Linux and UNIX-based Platforms (.aud)	os	SELECT, DML, DDL. Success and Failure, SQL Text (for SYS), SYS Auditing, separation of duties. Set AUDIT_SYS_OPERATIONS parameter to TRUE to perform administrator auditing.	None
   Linux and UNIX-based Platforms (.xml)	xml, extended	SELECT, DML, DDL. Success and Failure, SQL Text (for SYS), SYS Auditing, separation of duties. Set AUDIT_SYS_OPERATIONS parameter to TRUE to perform administrator auditing.	Extended lets SQL TEXT and SQL Bind to be written to the audit trail
   Linux and UNIX-based Platforms (syslog)	os	SELECT, DML, DDL. Success and Failure, SQL Text (for SYS), SYS Auditing, separation of duties. Set AUDIT_SYS_OPERATIONS parameter to TRUE to perform administrator auditing. Set AUDIT_SYSLOG_LEVEL parameter to valid facility.level. Records action code for operations performed or attempted, system privileges used to perform the action, and completion codes or the results of the attempted operation (0=success, otherwise Oracle error code).	More secure than audit records stored in operating system audit trail.
   Windows Platform Windows Event log	os	SELECT, DML, DDL. Success and Failure, SQL Text (for SYS), SYS Auditing, Separation of duties. Set AUDIT_SYS_OPERATIONS parameter to TRUE to perform administrator auditing.	None
   Windows Platform Operating System XML files (.xml)	xml, extended	SELECT, DML, DDL. Success and Failure, SQL Text (for SYS), SYS Auditing, Separation of duties. Set AUDIT_SYS_OPERATIONS parameter to TRUE to perform administrator auditing.	Extended lets SQL TEXT and SQL Bind to be written to the audit trail.

   
   

   ^Footnote 1 There is a 2 GB audit file size limit for the OSAUD collector to be able to collect audit records from audit trails stored in files, which includes the SYSLOG, .AUD, and .XML files. If a file size greater than 2 GB is encountered, the OSAUD collector will ignore all audit records beyond 2 GB. To control the size of the operating system audit trail and select the audit trail type to set, set the DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE property and the DBMS_AUDIT_MGMT.AUDIT_TRAIL_TYPE type by using the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY PL/SQL procedure. See Section 4.4 for tutorial information and Appendix G for reference information.

   Table 1-9 Oracle Database Source (Source Type ORCLDB) and the DBAUD Collector

   Audit Trail	Audit Trail Setting	Audited Operations	Comments
   Database Audit Tables			Collects by default from all database audit tables.
   SYS.AUD$	db, extended, or xml, extended	SELECT, DML, DDL, Success and Failure, SQL Text	Extended lets SQL TEXT and SQL Bind to be written to the audit trail
   SYS.FGA_LOG$	db, extended, or xml, extended	SELECT, INSERT, UPDATE, DELETE operations on a table; target specific columns and rows	Tracks very specific audited conditions; collect FGA data
   DVSYS.AUDIT_TRAIL$		Oracle Database Vault audit activity	Tracks Database Vault audit activity; as specified by audit_options on realms, command_rules, and so forth.

   
   

   Table 1-10 Oracle Database Source (Source Type ORCLDB) and the REDO Collector

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

   
   

   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.

   Select one or more options in Table 1-11. The options you select determine which collectors you must register with Audit Vault to match the audit trails from which you plan to collect audit records.

   Table 1-11 Choosing the Collector to Match the Oracle Database Audit Trail

   Option	Audit Trail	Collector Type	Comments
   a.	Operating system logs	OSAUD	This is the recommended collector to use. It is more secure from privileged users.
   b.	Database audit tables	DBAUD
   c.	Redo logs	REDO

   
   

   If you are collecting from two or more audit trails, register a collector for each audit trail from which you want to collect audit data. For example, if you want to collect audit data from all three Oracle Database audit trails, you must register the source and register an OSAUD, DBAUD, and REDO collector type for that source with Audit Vault.

   See Section 2.2 for steps to register the Oracle Database audit source and its collectors.

3. SQL Server Database Source

   From which SQL Server database audit trail do you want to collect audit data:

   
   a. C2 audit logs? See Table 1-12 for information about this audit trail.
   b. Server-side trace logs? See Table 1-12 for information about this audit trail.
   c. Windows Event log? See Table 1-12 for information about this audit trail.

   Table 1-12 provides an overview of the three SQL Server audit trails, their respective audit settings in the source, the audited operations, and other important comments to help you choose from which audit trails to collect audit data.

   Table 1-12 Microsoft SQL Server Database Source (Source Type MSSQLDB) and its 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 everything.
   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. They are lost 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

   
   

   By default, when you register the MSSQLDB collector with Audit Vault using the AVMSSQLDB add_collector command, the MSSQLDB collector collects audit records from all three audit trails. To change the default settings, select one or more options in Table 1-13 and specify the desired MSSQLDB collector attribute setting in a subsequent AVMSSQLDB alter_collector command.

   Table 1-13 Configuring the MSSQLDB Collector to Collect from the SQL Server Audit Trails

   Option	Audit trail	Which Collector Attributes to Specify for the Selected Audit Trail in the AVMSSQLDB alter_collector command	Default Setting
   a.	C2 Audit logs	AUDIT_C2_FLAG=1 C2_TRACE_FILPATH=path	1
   b.	Server-side trace logs	AUDIT_SERVERSIDE_TRACES_FLAG=1 SERVERSIDE_TRACE_FILPATH=path	1
   c.	Windows Event log	AUDIT_EVENT_LOG_FLAG=1	1

   
   

   For example, if collecting from two or fewer audit trails, alter the MSSQLDB collector attributes that represent the audit trails from which you do not plan to collect audit records by specifying a value of 0 (zero) for the flag values. For example, to not collect audit trail records from the server-side trace logs, specify the attribute AUDIT_SERVERSIDE_TRACES_FLAG=0 in the AVMSSQLDB alter_collector command.

   Thus, the options you select determine how you will configure and register the MSSQLDB collector to match the audit trails from which you plan to collect audit data.

   See Section 2.3 for steps to register the SQL Server Database audit source and the MSSQLDB collector.

1.5.1 Further Considerations for Selecting Oracle Database Collectors

This section emphasizes some considerations regarding selection of Oracle Database collectors.

Depending on the type of audit information generated and required to be maintained, you may deploy one or all three of the collectors for each Oracle Database audit source.

DBAUD Collector for Oracle Databases

If the audit settings are set as specified in Table 1-8, the DBAUD collector collects audit records from the Oracle Database database standard audit trail dictionary table SYS.AUD$, the fine-grained audit trail dictionary table SYS.FGA_LOG$, and the Oracle Database Vault audit trail database dictionary table DVSYS.AUDIT_TRAIL$. However, it is not possible to collect audit activity for SYS users using this collector because this activity is always written to operating system audit log files.

OSAUD Collector for Oracle Databases (Recommended)

Use the OSAUD collector to collect audited SYS user events from audit log files.

Oracle recommends using the operating system as your as your primary audit trail location and deploying the OSAUD collector as the operating system has the least amount of performance overhead on the database. Audit records stored in operating system files can be more secure than database-stored audit records because access can require file permissions that DBAs do not have. Greater availability is another advantage to operating system storage for audit records, in that they remain available even if the database is temporarily inaccessible.

REDO Collector for Oracle Database Redo Logs

The REDO collector is used to track before and after changes to sensitive data columns, such as salary. Also SYS user audit activity can be collected using this 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.6 Oracle Audit Vault Audit Event Categories, Attributes, Event Names, and Event IDs

This section describes where to find information about the Oracle Audit Vault audit event categories, the attributes for each category, and the associated audit events and event IDs for supported audit sources. This information is useful for understanding the audit events that are mapped to each Audit Vault event category for each audit source. For example, LOGON and LOGOFF audit events are both grouped into the USER SESSION audit event category for the Oracle Database audit source.

Oracle Audit Vault audit event category information is available in:

• The audit event appendixes (see, for example, Oracle Database Audit Events) in the Oracle Audit Vault Auditor's Guide for each supported audit source. Information about attributes for each audit event category and the associated event names and event IDs are listed there.

• The Audit Vault Administrator's Console.

  1. Log in to the Audit Vault Console as the Audit Vault Administrator.

  2. Click the Configuration tab.

  3. Click Audit Event Category.

  4. On the Audit Event Category Management page, source type options ORCLDB, and MSSQLDB can be selected. By default, the ORCLDB audit source type is selected. Select an audit event category, for example, select Account Management, then click View.

  5. On the View Audit Event Category page, by default you can view attribute names, their data type, and their origin, generic or source-specific. Click Audit Events.

  6. On the View Audit Event Category page, audit events and the associated source event ID display for the Account Management audit event category.

1.7 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 Oracle Database 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 for all audit data sources that is especially useful when audit data must be monitored on a real-time basis for particularly sensitive systems within the enterprise. 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), an Audit Vault Oracle Database (AVORCLDB), and an Audit Vault Microsoft SQL Server Database (AVMSSQLDB) for configuration and management tasks. Oracle Audit Vault provides an the Audit Vault Console that mandates a separation of duties to facilitate administration, management, 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.8 Getting Started

After installing the Audit Vault Server and Audit Vault Collection 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, the Audit Vault Collection Agent, and the audit data source (see Chapter 2).

   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 the coraenv script (for the C shell) and the oraenv script (for the Bourne, Bash, or Korn shell) 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 Collection Agents. In the Audit Vault Collection Agent shell, you must set these environment variables manually using the setenv command (see Chapter 2).

   Set the LANG environment variable to the locale category for native language of choice when using the AVMSSQLDB command-line utility in the Audit Vault Server shell and in the Audit Vault Collection Agent shell. This ensures the locale language specified appears as expected in all translated information. The NLS_LANG environment variable is Oracle specific and while effective with the AVORCLDB command-line utility has no effect on the AVMSSQLDB command-line utility; while the LANG environment variable is the standard way of setting the locale category for native language.

   Check and set environment variables in the shell in which you will be interacting with the audit data source. You can run the coraenv script (for the C shell) or the oraenv script (for the Bourne, Bash, or Korn shell) located in the /usr/local/bin directory to set these environment variables.

2. Get started by adding a source and collectors (see Chapter 2).

   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 and MSSQLDB collectors, verifying that the source is compatible for the collector type in the Audit Vault Collection Agent home, adding sources, adding collectors, setting up the database link from the Oracle Database source to the collection agent, and verifying the connection.

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

   Additional configuration tasks can include adding, changing, and dropping collection 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. Perform these tasks initially to configure Audit Vault and thereafter only as components are reconfigured.

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

4. Securing management communications between Audit Vault Server and the collection agents (see Chapter 5).

   An important security task includes securing management communication between the Audit Vault Server and collection agents. Before you go into production, Oracle recommends that you perform this task to secure management communications.

1.9 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:

  https://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