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 instances of the following database products:
Oracle Database (including Oracle Real Application Clusters and Oracle Data Guard)
Microsoft SQL Server
Sybase Adaptive Server Enterprise (ASE)
IBM DB2
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 with the audit data.
To use Oracle Audit Vault, follow these general steps:
Check that auditing is enabled in the databases from which you want to collect audit data and that the Oracle Audit Vault collectors are working. 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.
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. 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, Oracle Audit Vault records SQL statements that require the audited privilege to succeed.
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.
You can create either warnings or critical alerts that are triggered when certain events occur in an Oracle Database, SQL Server, Sybase ASE, or IBM DB2 database. You can configure the e-mail notifications or trouble tickets in response to the alert. Oracle Audit Vault alerts enable you to detect threats, which helps keep 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 configure e-mail and trouble ticket notifications, and create and monitor alerts.
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, Compliance Reports, and User-Defined Reports pages. The reports are organized by commonly used categories, including categories for compliance regulations.
You can perform the following actions with the reports:
Create user-defined reports to filter specific data.
Send the report to other users as a PDF file.
Schedule the report to be generated at specific times and then sent to users as a PDF file. You can create an e-mail distribution list, called a profile, to be used specifically for different types of reporting and alert activities.
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.
At this stage, the Oracle Audit Vault reports and alerts are generating as Audit Vault monitors your source databases.
When you review an Audit Vault report, you can annotate and attest the report, which is described in Section 3.7.
When you are notified of an alert, you can take the following actions:
Notify other users of the alert so that they can take the appropriate actions.
Log a trouble ticket if one is necessary. In this release, you can log trouble tickets to the BMS Remedy Service Management trouble ticketing system. You can design trouble ticket templates to be used for different types of trouble ticket scenarios.
View notes that other users may have created for the alert report.
Set a status for the alert, such as NEW
or CLOSED
.
Section 2.13 explains how to respond to an alert.
This section contains:
Before Oracle Audit Vault can collect audit data from the source databases, auditing must be enabled in those databases. A database administrator can check the type of auditing your database uses by logging in to SQL*Plus and running the appropriate command.
For example, to check if standard auditing is enabled:
SQL> SHOW PARAMETER AUDIT_TRAIL NAME TYPE VALUE ---------------------- ----------- ----------- audit_trail string DB
This output shows that standard auditing is enabled and audit records are being written to the database audit trail.
For fine-grained auditing, you can query the AUDIT_TRAIL
column of the DBA_AUDIT_POLICIES
data dictionary view to find the audit trail types that are set for the fine-grained audit policies on the database. For more information, see Oracle Database Security Guide.
Table 1-1 describes the audit trail types and their corresponding Audit Vault collectors.
Table 1-1 Oracle Database Audit Trail Types and Corresponding Collectors
Audit Trail Type | How Enabled | Corresponding Collector |
---|---|---|
Database audit trail |
For standard audit records: The For fine-grained audit records: The |
DBAUD |
Operating system audit trail |
For standard audit records: The For syslog audit trails, For fine-grained audit records: The |
OSAUD |
Redo log files |
The table that you want to audit must be eligible. See "Creating Capture Rules for Redo Log File Auditing" for more information. |
REDO |
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 PROCEDURE BY ACCESS;
AUDIT ALTER ANY TABLE BY ACCESS;
AUDIT ALTER DATABASE BY ACCESS;
AUDIT ALTER SYSTEM BY ACCESS;
AUDIT CREATE ANY JOB BY ACCESS;
AUDIT CREATE ANY LIBRARY BY ACCESS;
AUDIT CREATE ANY PROCEDURE BY ACCESS;
AUDIT CREATE ANY TABLE BY ACCESS;
AUDIT CREATE EXTERNAL JOB BY ACCESS;
AUDIT DROP ANY PROCEDURE BY ACCESS;
AUDIT DROP ANY TABLE BY ACCESS;
Database access and privileges. Use the following AUDIT
SQL statements:
AUDIT ALTER PROFILE BY ACCESS;
AUDIT ALTER USER BY ACCESS;
AUDIT AUDIT SYSTEM BY ACCESS;
AUDIT CREATE PUBLIC DATABASE LINK BY ACCESS;
AUDIT CREATE SESSION BY ACCESS;
AUDIT CREATE USER BY ACCESS;
AUDIT DROP PROFILE BY ACCESS;
AUDIT DROP USER BY ACCESS;
AUDIT EXEMPT ACCESS POLICY BY ACCESS;
AUDIT GRANT ANY OBJECT PRIVILEGE BY ACCESS;
AUDIT GRANT ANY PRIVILEGE BY ACCESS;
AUDIT GRANT ANY ROLE BY ACCESS;
AUDIT ROLE BY ACCESS;
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.
To start the Audit Vault Console:
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, which displays the URL that starts the Audit Vault Console:
$ avctl show_av_status
In the Login page, enter your user name and password. From the Connect As list, select AV_AUDITOR. Then click Login.
The Dashboard page appears and displays information about configured alerts and audit trail activity.
From the Dashboard page, you can do the following:
View audit data from a range of dates. To view the audit data, which includes data such as the top five objects accessed and failed logins, specify the range you want, and then click the Go button. To automatically refresh the data every 60 seconds, click the Refresh every 60 seconds check box, or manually refresh it by clicking the Refresh button.
Check alerts. The Dashboard page displays recently raised alerts, as well as all warning and critical alerts.
Check attestation actions. The Dashboard page displays a list of reports that you may need to attest.
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.
Ensure that the Oracle Audit Vault collection agents are working. Section 1.5 explains how to ensure that these agents are collecting audit data.
This section contains:
Checking the Status of the Source Database Collection Agents
What Happens if the Source Database Collection Agents Were Not Active?
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. See also Oracle Audit Vault Administrator's Guide for additional troubleshooting tips for the reports.
To check the status of the source database collection agents:
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.
Click the Settings tab.
Click the Collection Status secondary tab.
The Collection Status page shows the following information for collectors:
Source name. The name of the audit source database where the audit data is being collected
Collector Name. Name of the collector
Agent Name. The name of the agent with which this collector is associated
Bytes Per Sec. Number of bytes per second it takes to retrieve the audit data
Records Per Sec. Number of audit records that are being retrieved per second
Is Alive. 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-2 summarizes the database collector types.
Table 1-2 Database Collector Types Provided by Oracle Audit Vault
Database | Collectors | Description |
---|---|---|
Oracle |
DBAUD |
Collector that performs the following:
|
Oracle |
OSAUD |
Collector that performs the following:
|
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 |
IBM DB2 |
DB2DB |
Collector to extract records from the ASCII text file in which IBM DB2 generates audit data. |
If the collection agents were not active, then no audit data is lost, as long as the source database continues to collect the audit data. When you restart the collection agent, it captures the audit data that the source database had collected during the time the collection agent was inactive.