Skip Headers
Oracle® Audit Vault Auditor's Guide
Release 10.2.3
Part Number E11058-01
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
View PDF

1 Introducing Oracle Audit Vault for Auditors

This chapter contains:

1.1 What Is Oracle Audit Vault?

Oracle Audit Vault collects audit data from multiple databases and then consolidates this data in a set of audit reports. You can collect audit data from multiple Oracle (including Real Application Clusters and Oracle Data Guard) and Microsoft SQL Server databases.

To use Oracle Audit Vault, an administrator configures the Audit Vault server to connect to your database sources. Oracle Audit Vault then collects the audit data that these databases generate, organizes the data, and then provides it to you in a variety of reports. For Oracle databases, you can create policies and collect data from redo log files. For both database products (Oracle and SQL Server), you can create alerts. In addition to the Oracle Audit Vault reports, you can design reports using a third-party tool, such as Oracle Business Intelligence. To manage Audit Vault policies, alerts, and reports, you use the Audit Vault Console.

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

The policies and alerts features help you to detect security threats to an Oracle database. For example, an alert can notify you when a system administrator tries to view sensitive application data, such as employee salaries.

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

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

1.2 General Steps for Using Oracle Audit Vault

To use Oracle Audit Vault, follow these general steps:

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

Check that the databases from which you want to collect audit data have auditing enabled and that the Oracle Audit Vault collectors are working. Some database administrators may disable auditing for performance reasons, so you cannot always assume that auditing will be enabled. For Oracle Database, there are recommended audit settings that your database administrator should consider having in place. Your database administrator also should ensure that these databases are properly configured to send audit data to the Oracle Audit Vault server.

See Section 1.3 and Section 1.5 for more information.

1.2.2 Step 2: Create Audit Policies for Oracle Database Data

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

You can create policies for the following kinds of data:

  • SQL statements. For example, you can audit statements that users use when attempting to query the database or modify data, such as SELECT or UPDATE.

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

  • Database Privileges. You can audit the use of a system privilege, such as SELECT ANY TABLE. In this kind of auditing, SQL statements that require the audited privilege to succeed are recorded.

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

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

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

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

1.2.3 Step 3: Optionally, Create and Monitor Alerts

Optionally, you can create either warning or critical alerts that are triggered when certain events occur in an Oracle or a SQL Server database. Oracle Audit Vault alerts enable you to detect threats, which helps in keeping systems in compliance with internal and external policies.

After you create the alerts, you can monitor them by using the Home page (under the Home secondary tab) in the Audit Vault Console.

Section 2.11 explains how you can create and monitor alerts.

1.2.4 Step 4: View and Customize the Audit Vault Reports

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

You can create user-defined custom reports to filter specific data if you want. Oracle Audit Vault has an open data warehouse schema, which you can use to build custom reports using Oracle Application Express, business intelligence tools such as Oracle BI Publisher, or third-party business intelligence tools.

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

1.3 Database Requirements for Collecting Audit Data

This section contains:

1.3.1 Requirements for Oracle Database

This section contains:

1.3.1.1 Ensuring That Auditing Is Enabled in the Source Database

Before Oracle Audit Vault can collect audit data from the source databases, auditing must be enabled in those databases. In Oracle Database, a database administrator can check if auditing has been enabled by using either of the following methods:

  • Ensuring that standard auditing is enabled. Log in to SQL*Plus with administrative privileges and then check the value of the AUDIT_TRAIL initialization parameter, which enables or disables auditing.

    For example:

    sqlplus SYSTEM
Enter password: password
Connected.

SQL> SHOW PARAMETER AUDIT_TRAIL

NAME                   TYPE        VALUE
---------------------- ----------- -----------
audit_trail            string      NONE

    This example shows that the AUDIT_TRAIL parameter has been set to the NONE setting. If the AUDIT_TRAIL parameter has been set to NONE and if the database is not using fine-grained auditing, then no auditing can occur. A database administrator with the SYSDBA privilege can enable standard auditing, and then an administrator with the SYSOPER privilege can restart the database.

    For example, to set AUDIT_TRAIL to DB (which enables auditing and sends audit data to the SYS.AUD$ system table), and then restart the database, log in to SQL*Plus and enter the following:

    SQL> CONNECT SYS/AS SYSDBA
Enter password: password
Connected.

SQL> ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE;
System altered.

SQL> CONNECT SYS/AS SYSOPER
Enter password: password
Connected.
SQL> SHUTDOWN
Database closed.
Database dismounted.
SQL> STARTUP
ORACLE instance started.

  • Ensuring that fine-grained auditing is enabled. If the database is using fine-grained auditing, then the AUDIT_TRAIL parameter does not need to be set. In fine-grained auditing, you create the auditing policy in a PL/SQL package. You can ensure that fine-grained auditing is enabled by querying the V$OPTION table in the source database. Remember that the parameter value, (in this case, Fine-grained Auditing), that you specify with V$OPTION is case sensitive.

    For example:

    SQL> SELECT * FROM V$OPTION WHERE PARAMETER = 'Fine-grained Auditing';

PARAMETER               VALUE
----------------------- ---------
Fine-grained Auditing   TRUE

    This example shows that fine-grained auditing is enabled. If the query returns FALSE, then ask the Oracle Database security administrator to enable and configure the necessary fine-grained auditing in this database.

    You can check if any fine-grained audit records have been created by asking an administrator to run the following query:

    SQL> SELECT COUNT(*) FROM DBA_FGA_AUDIT_TRAIL;

  COUNT(*)
----------
       212

    This example shows that 212 fine-grained audit records have been created.

1.3.1.2 Using Recommended Audit Settings in the Source Database

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

  • Database schema or structure changes. Use the following AUDIT SQL statement settings.

    • AUDIT ALTER ANY TABLE BY ACCESS;

    • AUDIT CREATE ANY TABLE BY ACCESS;

    • AUDIT DROP ANY TABLE BY ACCESS;

    • AUDIT CREATE ANY PROCEDURE BY ACCESS;

    • AUDIT DROP ANY PROCEDURE BY ACCESS;

    • AUDIT ALTER ANY PROCEDURE BY ACCESS;

    • AUDIT CREATE EXTERNAL JOB BY ACCESS;

    • AUDIT CREATE ANY JOB BY ACCESS;

    • AUDIT CREATE ANY LIBRARY BY ACCESS;

    • AUDIT ALTER DATABASE BY ACCESS;

    • AUDIT ALTER SYSTEM BY ACCESS;

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

    • AUDIT AUDIT SYSTEM BY ACCESS;

    • AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS;

    • AUDIT EXEMPT ACCESS POLICY BY ACCESS;

    • AUDIT ALTER USER BY ACCESS;

    • AUDIT CREATE USER BY ACCESS;

    • AUDIT ROLE BY ACCESS;

    • AUDIT CREATE SESSION BY ACCESS;

    • AUDIT DROP USER BY ACCESS;

    • AUDIT GRANT ANY PRIVILEGE BY ACCESS;

    • AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS;

    • AUDIT GRANT ANY ROLE BY ACCESS;

    • AUDIT ALTER PROFILE BY ACCESS;

    • AUDIT DROP PROFILE BY ACCESS;

1.3.2 Requirements for Microsoft SQL Server

Ensure that auditing is enabled in your Microsoft SQL Server database. You also should ensure that they are correctly configured to send audit data to the Oracle Audit Vault server. For more information, check the documentation for these two products and Oracle Audit Vault Administrator's Guide.

1.4 Starting the Audit Vault Console

To start the Audit Vault Console:

  1. From a browser, enter the following URL:

    http://host:port/av

    In this specification:

    • host: The server where you installed Oracle Audit Vault

    • port: The Audit Vault Console HTTP port number

    For example:

    http://123.456.78.9:5700/av

    If you are unsure of the URL, from the terminal window that you use for the Audit Vault server, enter the following command to display the URL you should use to start the Audit Vault Console:

    avctl show_av_status

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

    The Home page appears and displays information about configured alerts and audit trail activity. From here, you can do the following:

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

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

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

1.5 Ensuring That the Oracle Audit Vault Collectors Can Collect Data

The Oracle Audit Vault collection agents are responsible for the connection between the source database and the Audit Vault Server. In the Audit Vault Console, you can check the status of the collection agents. If you cannot access Oracle Database audit policies, or if the Audit Vault default reports do not show any information, then the collection agents may not be working, or the source database has been shut down.

To check the status of the source database collection agents:

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

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

  2. Click the Audit Status tab.

The Audit Status page shows the following information

Table 1-1 summarizes the database collector types.

Table 1-1 Audit Vault Provided Database Collector Types

Database Collectors Description

Oracle

DBAUD

Collector that performs the following:

  • Extracts audit records from the Oracle Database audit trail, where standard audit events are written to SYS.AUD$ dictionary table; and the fine-grained audit trail, where audit events are written to SYS.FGA_LOG$ dictionary table.

  • Extracts audit records from the Oracle Database Vault audit trail DVSYS.AUDIT_TRAIL$ table.

Oracle

OSAUD

Collector that performs the following:

  • For Linux and UNIX platforms: extracts audit records from the operating system files (audit logs) (SYS$AUD (.aud) and XML (.xml) files).

  • For Linux and UNIX platforms: SYSLOG Collector to extract audit records from the system audit trail where database audit trail records are written to a syslog file.

  • For Microsoft Windows: EVTLOG Collector to extract audit records from the system audit trail where database audit trail records are written to the Event Log.

Oracle

REDO

Collector using Oracle Streams technology to retrieve logical change records from the redo logs.

SQL Server

SQLSERVER

Collector (for Windows platforms) to extract audit records from Microsoft SQL Server databases from the Windows Event logs, Server-side Traces, and C2 auditing logs.

Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us