Skip Headers
Oracle® Audit Vault Auditor's Guide
Release 10.2.3.1

Part Number E13842-02
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 How Do Auditors Use Oracle Audit Vault?

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

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

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

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

The audit data collected by Oracle Audit Vault is stored in its own secure data warehouse repository, where an administrator can use Oracle Database Vault and Oracle Advanced Security to prevent tampering 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. Because database administrators sometimes disable auditing for performance reasons, you cannot assume that auditing is enabled. For source databases, there are recommended audit settings that your database administrator should consider having in place. Your database administrator also should ensure that these databases are properly configured to send audit data to the Audit Vault Server.

See Section 1.3 and Section 1.5 for more information.

1.2.2 Step 2: Create Audit Policies for Oracle Database Data

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

You can create policies for the following kinds of data:

  • SQL statements. 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 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 Database, SQL Server, Sybase ASE, or IBM DB2 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 in the Audit Vault Console.

Section 2.12 explains how you can create and monitor alerts.

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

Oracle Audit Vault automatically populates its reports with the audit data from your source databases. You can view this data by selecting from the reports provided in the Audit Vault Console Default Reports and User-Defined Reports pages. The reports are organized by commonly used categories, including categories for compliance regulations. In the Audit Vault Console, you can create user-defined 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 Business Intelligence Publisher, or third-party business intelligence tools.

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

1.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 auditing cannot 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 SQL Server, Sybase ASE, and IBM DB2 Databases

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

1.4 Starting the Oracle Audit Vault Console

To start the Audit Vault Console:

  1. From a browser, enter the following URL:

    http://host:port/av
    

    In this specification:

    • host is the server where you installed Oracle Audit Vault

    • port is the Audit Vault Console HTTP port number

    For example:

    http://192.0.2.1:5700/av
    

    If you are unsure of the URL, from the terminal window that you use for the Audit Vault Server, enter the following command 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 Oracle 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. You can view audit information that has been collected in the Oracle Audit Vault reports. Optionally, you can control the display of data and create user-defined reports. See Chapter 3, "Using Oracle Audit Vault Reports" for more information.

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 while collectors collect the audit data. In the Audit Vault Console, you can check the status of the collection agents and collectors. If you cannot access Oracle Database audit policies, or if the Oracle Audit Vault default reports do not show any information, then the collection agents may not be working, or the source database has been shut down.

To check the status of the source database collection agents:

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

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

  2. Click the Audit Status tab.

The Audit Status page shows the following information for collectors:

Table 1-1 summarizes the database collector types.

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

Database Collectors Description

Oracle

DBAUD

Collector that performs the following:

  • Extracts audit records from the Oracle Database audit trail, where standard audit events are written to the SYS.AUD$ dictionary table; and the fine-grained audit trail, where audit events are written to the 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

MSSQLDB

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

Sybase ASE

SYBDB

Collector to extract audit records from the Sybase databases audit trail logged in audit tables in the SYBSECURITY database.

IBM DB2

DB2DB

Collector to extract records from the ASCII text file in which IBM DB2 generates audit data.


Table 1-2 lists the fields that describe each configured collection agent.

Table 1-2 Fields in the Agents Status Page

Field Description

Agent

The name of the agent that was configured.

Host

The fully qualified domain name for the computer on which the agent was installed (for example, avsrv.us.example.com)

Port

The port number for the computer listed in the Host column

HTTPS

Indicates whether the connection is an HTTPS connection. FALSE means the connection is an HTTP connection; TRUE means it is an HTTPS connection.

Status

An up green arrow indicates that the agent is active. A down red arrow means it is inactive.