|Oracle® Audit Vault Auditor's Guide
Part Number E11058-01
This chapter contains:
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.
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.
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.
SQL statements. For example, you can audit statements that users use when attempting to query the database or modify data, such as
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.
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.
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.
This section contains:
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.
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
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.
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.
After your database administrator checks that auditing is enabled, Oracle recommends that the following areas of the database have auditing enabled:
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;
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.
From a browser, enter the following URL:
In this specification:
host: The server where you installed Oracle Audit Vault
port: The Audit Vault Console HTTP port number
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:
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.
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:
Log into the Audit Vault Console as a user who has been granted the
Section 1.4 explains how to log in to the Audit Vault Console.
Click the Audit Status tab.
The Audit Status page shows the following information
Collector. Name of the collector
Agent. The name of the agent to which this collector is associated
Audit Source. The name of the audit data source where the audit data is being collected
Status. Whether the collector is running or not. When the collector is up, a green up arrow indicator is displayed. When the collector is down, a red down arrow indicator is displayed. When there is a problem, an error is displayed. If the collector is not working, then contact your Oracle Audit Vault administrator.
Table 1-1 summarizes the database collector types.
Collector that performs the following:
Collector that performs the following:
Collector using Oracle Streams technology to retrieve logical change records from the redo logs.
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.