Skip Headers
Oracle® Audit Vault Administrator's Guide
Release 10.2.3.2
Part Number E14459-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 Administrators

This chapter contains:

1.1 How Do Administrators Use Oracle Audit Vault?

By the time you begin to use this guide, you will have installed the Oracle Audit Vault Server and the Oracle Audit Vault collection agent, to prepare for the collection of audit data from your databases (called source databases, or audit data sources). This guide explains how to configure the source databases so that Oracle Audit Vault can collect their audit data. After you have completed this configuration, then auditors can generate and customize reports that describe this audit data.

An Oracle Audit Vault administrator is responsible for the following tasks:

Oracle Database administrators are responsible for running the Oracle Database audit trail cleanup procedures on the source database, which purge audit trail records from the Oracle source database after these records are archived.

1.2 General Steps for Administering Oracle Audit Vault

To administer Oracle Audit Vault, follow these steps:

1.2.1 Step 1: Understand the Oracle Audit Vault Architecture

In this chapter, Section 1.3 describes the main components of Oracle Audit Vault, and explains how these components work together. Section 1.4 describes the various tools that you use to administer Oracle Audit Vault. Section 1.5 describes the predefined roles that are created during the Oracle Audit Vault installation process. Understanding how these pieces fit together provides the foundation you need to administer Oracle Audit Vault.

1.2.2 Step 2: Plan the Oracle Audit Vault Source Database and Collector Configuration

Section 1.6 provides guidelines for selecting the correct Oracle Audit Vault collector (that is, the module that collects audit data from your source databases) based on the type of database from which you are collecting audit data. You must understand the audit settings and audit trail used in your source databases before you can select the correct collector.

1.2.3 Step 3: Configure Collectors to Collect Audit Data

After you have decided which collectors to use for your source database, you are ready to configure them. Chapter 2 explains how to register (configure) collectors for the source databases.

To accomplish the configuration, you can use the command-line utilities described in Section 1.4.

After you complete this step, Oracle Audit Vault is collecting audit data, which the auditors on your site can access by using the reporting tools described in Oracle Audit Vault Auditor's Guide.

1.2.4 Step 4: Monitor and Maintain the Audit Record Collection Process

After you have completed the configuration, you should monitor the audit collection activities to ensure that they are working properly. These tasks include the following:

  • Perform common management tasks. For example, you may need to check whether the collectors are running, fine-tune how data is collected in the Oracle Audit Vault data warehouse, or modify the attributes of a source database. See the following chapters:

    • Chapter 3 describes common management tasks.

    • Chapter 4 provides advice on managing an Oracle Audit Vault installation on an Oracle Real Application Clusters environment, and what to do if you are concerned that your audit data will fill the default tablespace and disk space.

    • Chapter 5 describes common security tasks and how Oracle Advanced Security and Oracle Database Vault enhance the security of an Oracle Audit Vault system.

    • Chapter 12 describes optimum initialization parameter settings for the REDO collector.

  • For Oracle Database administrators, periodically archive and purge the Oracle Database audit trail for the Oracle source database. See the following:

    • Section 4.10 describes steps to follow for archiving and purging the Oracle Database audit trail.

    • Oracle Database SQL Reference describes data dictionary views that you can query to ensure that your configuration settings are correct. These views are as follows:

      DBA_AUDIT_MGMT_CONFIG_PARAMS

      DBA_AUDIT_MGMT_LAST_ARCH_TS

      DBA_AUDIT_MGMT_CLEANUP_JOBS

      DBA_AUDIT_MGMT_CLEAN_EVENTS

    • Oracle Database PL/SQL Packages and Types Reference describes the DBMS_AUDIT_MGMT package, which contains the procedures and functions that you use to archive and purge the Oracle Database audit trail.

  • Troubleshoot problems that arise. See the following:

    • Appendix A describes how to troubleshoot the Oracle Audit Vault system.

    • Appendix B explains how to resolve Oracle Audit Vault-specific error messages.

1.3 Components of Oracle Audit Vault

This section contains:

1.3.1 Source Databases

A source database is a database from which Oracle Audit Vault collects audit data. Oracle Audit Vault can collect this audit data from the internal audit trail tables and operating system audit trail files of a source database.

Table 1-1 lists the supported source database products.

Table 1-1 Supported Source Database Products

Database Product Supported Versions

Oracle Database

For the OSAUD and DBAUD collector types: Releases 9.2.x, 10.1.x, 10.2.x, and 11.x

For the REDO collector type: Enterprise Edition Releases 9.2.0.8, 10.2.0.3, 10.2.0.4 and later, 11.1.0.6 and later, and 11.2 for the REDO collector type

Microsoft SQL Server

SQL Server 2000 and SQL Server 2005 on Windows 2000 Server and Windows 2003 Server platforms.

SQL Server 2008. Only the Event Log, C2 and server-side trace audit trails are supported.

Sybase Adaptive Server Enterprise (ASE)

ASE 12.5.4 through ASE 15.0 on platforms based on Linux and UNIX, and on Microsoft Windows platforms

IBM DB2

IBM DB2 Version 8.2 through Version 9.5 on platforms based on Linux and UNIX, and on Microsoft Windows platforms.

If you are using Version 8.2, ensure that you have installed Fixpack 16.

1.3.2 Oracle Audit Vault Server

The Oracle Audit Vault Server contains the tools necessary to configure Oracle Audit Vault to collect audit data from your source databases. The Audit Vault Server also contains an Oracle database, and makes it available to reporting tools through a data warehouse.

This section contains:

1.3.2.1 General Oracle Audit Vault Server Components

The Audit Vault Server consists of:

  • Audit Data Store

  • Oracle Audit Vault Console

  • The following services:

    • Audit data collection and storage management

    • Alert management

    • Collector management and monitoring

    • Report management

    • User entitlement management reports

    • Published data warehouse that can be used with reporting tools such as Oracle Business Intelligence Publisher to create customized reports

    Configuration services help define information about the source databases that connect to Oracle Audit Vault. Oracle Audit Vault stores information (metadata) about the sources of audit data and policy information (database audit settings).

Table 1-2 describes the Oracle Audit Vault Server components.

Table 1-2 Oracle Audit Vault Server Components

Components Description

Oracle Container for Java (OC4J)

Oracle Database container for Web applications. It hosts the following components:

  • Audit Vault Console. User interface for administrators to administer Oracle Audit Vault. Also, Oracle Audit Vault auditors can use this interface to generate reports, create alerts, and create Oracle Database audit policies.

  • Oracle Enterprise Manager Database Control console. User interface to manage the raw audit data store or audit repository database.

  • Management Framework. Internal tool that sends management commands to the Audit Vault collection agent to start or stop collection agents and collectors, collect metrics, and receive management commands from the Oracle Audit Vault command-line tools using HTTP protocol or HTTPS mutual certificate-based authentication. Section 1.4 lists the Oracle Audit Vault command-line tools.

  • Audit Policy System. Internal service that retrieves and provisions audit settings from the Oracle Database source. It also enables users to create and manage alerts raised by audit events from all source databases while they are being stored in the audit event repository.

  • User Entitlement System. Internal service that retrieves user entitlement information from an Oracle Database source.

  • PDF scheduling and printing subsystem. Internal service that schedules and generates Oracle Audit Vault reports in PDF format.

  • SMTP integration system. Internal service that manages e-mail notifications for Oracle Audit Vault reports and alerts.

  • Remedy trouble ticket integration system. Internal service that manages the Remedy trouble ticket service for Oracle Audit Vault reports and alerts.

Database Client

Infrastructure to communicate to the audit repository, consisting of:

  • Oracle Wallet. Contains credentials to authenticate Oracle Audit Vault users

  • Configuration files. Files used by Oracle Audit Vault for networking, preferences, and so on.

Configuration and Management Tools

Utilities used to configure and manage Oracle Audit Vault, which are described in detail in Section 1.4. They let you define and configure information about what source databases are known to Oracle Audit Vault.

Logs

Informational and error messages for Oracle Audit Vault. See Section A.1 for more information.

Audit repository

Oracle database (Release 10.2.0.4) to consolidate and manage audit trail records.

It has the following components:

  • Raw audit data store. A partitioned table where audit records are inserted as rows

  • Warehouse schema. An open schema of normalized audit trail records. This is a published data warehouse that auditors can use with reporting tools such as Oracle Business Intelligence Publisher to create customized reports.

  • Job scheduler. Database jobs used to populate and manage the warehouse

  • Alerts. A queue that maintains auditor-created alerts

1.3.2.2 Default Oracle Audit Vault Server Port Numbers

Table 1-3 describes the ports that the Audit Vault Server uses. To find the port numbers that were used when you installed Oracle Audit Vault, check the portlist.ini file, which is in the $ORACLE_HOME/install directory. Be aware that if you change the port numbers later on, the portlist.ini file does not reflect the changes. If you need to change the port numbers, see Section 4.9.

Table 1-3 Oracle Audit Vault Server Ports

Component Default Port Number Required to be Open Finding the Current Port Number

SQL*Net listener

1521

Yes

At a command line, enter the following command:

lsnrctl status

Enterprise Manager Database Control HTTP (OC4J)

1158, 5500

Yes, if you want to use Database Control with the Audit Vault Console

At a command line, enter the following command:

emctl status dbconsole

Oracle Audit Vault Console HTTP

5700

Yes

At a command line, enter the following command:

avctl show_av_status

OC4J RMI

5522

No

Search for rmi-server port in the following file in the Audit Vault Server:

$ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_SID/config/rmi.xml

OC4J JMS

5542

No

Search for jms-server port in the following file in the Audit Vault Server:

$ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_SID/config/jms.xml

Oracle Audit Vault Reports HTTP

5707

Yes

In SQL*Plus, run the following query:

SELECT DBMS_XDB.GETHTTPPORT FROM DUAL;

1.3.3 Oracle Database Vault

Oracle Database Vault is included in the Audit Vault Server. Database Vault protects the Audit Vault Server data, including restricting the audited data from administrative access. By default, Database Vault is enabled.

For more information about how Oracle Database Vault is integrated with Oracle Audit Vault, see Section 5.5.

1.3.4 Audit Vault Collection Agent and Collectors

This section contains:

1.3.4.1 What Are Collection Agents and Collectors?

A collector retrieves the audit trail data from a source database and sends it to the Audit Vault Server. The collection agent manages the collectors. The collectors send both valid and invalid audit records, get configuration information, and send error records using Oracle Call Interface (OCI) and JDBC password-based authentication. If the collection agent is stopped, then the source database will still create an audit trail (assuming auditing is enabled). The next time you restart the collection agent, Oracle Audit Vault retrieves the audit data that had been accumulating since the agent was stopped.

Each source database is configured to have a collector, and that collector is based on the type of audit trail the source database is configured to use. For example, if an Oracle source database is configured to write the audit trail to the database audit trail, then it uses the DBAUD collector. The collection agent can be installed on one computer and manage multiple collection agents from there. For example, suppose you have 25 source databases on 25 servers. You must configure a collector for each of these source databases, but you do not need to configure a collection agent of each of the 25 servers. Instead, just create one collection agent to manage the 25 collectors. Be aware, however, that for Oracle databases, you cannot use a remote collection agent to collect audit data from users who have logged in with the SYSDBA or SYSOPER privilege.

1.3.4.2 General Audit Vault Collection Agent and Collector Components

Table 1-4 describes the components of the collection agent.

Table 1-4 Oracle Audit Vault Collection Agent Components

Component Description

OC4J

Oracle container for Web applications. It contains the Audit Vault Collector Manager, which receives management commands from the Audit Vault Server to start and stop collectors, collect and return metrics, and so on.

Database Server

Infrastructure to communicate to the audit repository, consisting of:

  • Oracle Wallet. Contains credentials to authenticate Audit Vault users

  • Configuration Files. Files used by Oracle Audit Vault for networking, preferences, and so on

Configuration and Management Tools

Utilities used to configure and manage Oracle Audit Vault. These are the AVCA, AVCTL, AVORCLDB, AVMSSQLDB, AVSYBDB, and AVDB2DB command-line utilities.

Logs

Informational and error messages for Oracle Audit Vault (see Section A.1)

Collectors

Table 1-5 shows the type of collectors deployed by the Oracle Audit Vault collection agents and the audit trail from which audit records are extracted and collected.

Table 1-5 describes the types of collectors and their corresponding audit trail types.

Table 1-5 Oracle Audit Vault Collector Types and Audit Trails

Audit Source Collector Type Audit Trail

Oracle Database

DBAUD

Collects from the following audit trails:

  • 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

Oracle Database

OSAUD

Collects data from the following audit trails:

  • On Linux and UNIX platforms: The Oracle database audit files written to the operating system (.aud) files, and syslog files

  • On Windows platforms: The operating system Windows Event Log and operating system logs (audit logs) XML (.xml) files

Oracle Database

REDO

Collects audit data from logical change records (LCRs) from the REDO logs. If you plan to use the REDO collector, you can define the data to audit by creating capture rules for the tables from which the REDO collector will capture audit information. See Oracle Audit Vault Auditor's Guide for more information.

Microsoft SQL Server

MSSQLDB

Collects audit data from C2 audit logs, server-side trace logs, and Windows Event Logs

Sybase ASE

SYBDB

Collects audit data from system audit tables (sysaudits_01 through sysaudits_08) in the sybsecurity database

IBM DB2

DB2DB

Collects audit data from ASCII text files extracted from the binary audit log (db2audit.log). These files are located in the security subdirectory of the DB2 database instance.

1.3.4.3 Default Audit Vault Collection Agent and Collector Port Numbers

Table 1-6 describes the default port numbers that the Audit Vault agent uses. To find the port numbers that were used when you installed Oracle Audit Vault, check the portlist.ini file, which is in the $ORACLE_HOME/install directory. Be aware that if you change the port numbers later on, the portlist.ini file does not reflect the changes. If you need to change the port numbers, see Section 4.9.

Table 1-6 Oracle Audit Vault Agent Ports

Component Default Port Number Required to be Open Finding the Current Port Number

OC4J RMI

3101

Yes

Search for rmi-server port in the following file in the Audit Vault Agent home directory:

$ORACLE_HOME/oc4j/j2ee/home/config/rmi.xml

OC4J JMS

3201

No

Search for jms-server port in the following file in the Audit Vault Agent home directory:

$ORACLE_HOME/oc4j/j2ee/home/config/jms.xml

Agent HTTP

7010

Yes

Search for web-site port in the following file in the Audit Vault Agent home directory:

$ORACLE_HOME/oc4j/j2ee/home/config/http-web-site.xml

1.3.5 How the Oracle Audit Vault Components Work Together

Figure 1-1 provides a high-level overview of how the Oracle Audit Vault components work together.

Figure 1-1 Overview of the Oracle Audit Vault Components

Description of Figure 1-1 follows
Description of "Figure 1-1 Overview of the Oracle Audit Vault Components"

The process flow for the Oracle Audit Vault components works as follows:

  1. The source databases, Oracle Database, SQL Server, Sybase ASE, and IBM DB2, have all been configured to use their respective collectors:

    • Oracle Database uses the REDO, DBAUD, and OSAUD collectors.

    • SQL Server uses the MSSQLDB collector.

    • Sybase ASE uses the SYBDB collector.

    • IBM DB2 uses the DB2DB collector.

    As Figure 1-1 shows, you can configure multiple databases from different database product families using the same Audit Vault collection agent to connect to the same Audit Vault Server.

  2. The collectors listed in Step 1 retrieve the audit data from their source databases and send this data to the Audit Vault Server.

  3. The Audit Vault Server collects and stores this data in the database, and then makes it available in the warehouse.

    The data warehouse organizes this data into a set of internal dimension tables. The Audit Vault Server stores other information as well, for both the auditor and the administrator.

  4. Once the audit data is in the data warehouse dimension tables, an auditor can retrieve this data to generate and customize reports, as well as send e-mail notifications and trouble ticket alerts.

    Any settings that you, the administrator, create, such as security settings, are contained in this server. The Audit Vault Server stores all the tools that you need to configure the Audit Vault components and source databases.

The details of the process flow for the Audit Vault components works as follows:

  1. The OC4J components in the Audit Vault Server and Audit Vault collection agent connect using HTTP or HTTPS.

    The OC4J is a container for Web applications that consists of the Audit Vault Console, the Oracle Enterprise Manager Database Control console, the Audit Vault internal tools (management framework), and the audit policy system used to retrieve and make available the audit settings. The HTTP (or HTTPS) connection is used for starting and stopping agents, managing metrics, and running commands related to policy retrieval.

    The Audit Vault Server contains its own database server, and an Oracle wallet containing the administrator's credentials. It also stores configuration information from utility settings (such as AVCA, AVCTL, and the command-line utilities used for the four database products) and log files that store operational information, such as broken database connections and missing files.

    In addition to its HTTP or HTTPS connection, each collector in the Oracle Audit Vault collection agent maintains an OCI and a JDBC connection to the Audit Vault Server using the credentials from the client wallet.

  2. The collectors retrieve audit records from the source databases and send this data to the audit repository, which contains the Audit Vault data warehouse.

    The data warehouse organizes this data into a set of dimension tables. Oracle Audit Vault Auditor's Guide describes the data warehouse dimension tables in detail. In addition to the data warehouse, the audit repository contains auditor-created alert information.

  3. Oracle Audit Vault receives data from the Oracle Database redo logs using a database link. The Oracle Database redo logs bypass the collectors.

1.4 Administrative Tools for Managing Oracle Audit Vault

You can use the following tools to administer Oracle Audit Vault:

1.5 Default Oracle Audit Vault Roles

Table 1-7 describes the various Oracle Audit Vault administrator roles and the tasks permitted for each role. See also Table 5-2 for a listing of the roles and privileges that are granted to these administrator roles.

Table 1-7 Oracle Audit Vault Administrator Roles and Their Assigned Tasks

Role When Is the 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 who is granted this role configures and manages metadata for audit source databases, collection agents, collectors, the configuration of the source database with the collection agent, and the data warehouse. The installation process creates and grants a user account with this role. Only the user granted the AV_ADMIN role can grant the AV_ADMIN role to other Oracle Audit Vault administrators.

You can consider the AV_ADMIN role a super-user account for Oracle Audit Vault, except that a user who has been granted this role cannot view, update, or delete audit data.

AV_AUDITOR

During Server installation

Audit Vault auditor

Accesses Oracle 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 who is granted this role manages central audit settings and alerts. This user also uses the data warehouse services to further analyze the audit data to look for trends, intrusions, anomalies, and other items of interest.

The installation process creates and grants a user account with this role. However, during installation, you optionally can bypass creating this user account. In that case, the roles and privileges normally granted to AV_AUDITOR are granted to AV_ADMIN instead. Typically, one user is granted an AV_ADMIN role and one user is optionally granted an AV_AUDITOR role as part of installing the Audit Vault Server.

AV_AGENT

During collection agent registration

Collection agent software component

Manages collection agents and collectors by starting and stopping them. Oracle Audit Vault creates this role for internal use only.

DV_ACCTMGR

During Audit Vault Server installation

Database Vault account manager

Manages database user accounts. Be aware that the inclusion of Oracle Database Vault in the Audit Vault Server prevents users SYS and SYSTEM from creating, altering, or dropping user accounts. See Oracle Database Vault Administrator's Guide for more information about how Oracle Database Vault affects user privileges. See also Section 5.5.

In a default Oracle Audit Vault installation, this account name is based on the default Oracle Audit Vault AV_ADMIN user account, with dva appended. For example, if during the installation you created avadmin as the AV_ADMIN user, then the DV_ACCTMGR account name is avadmindva.

DV_OWNER

During Audit Vault Server installation

Database Vault owner

Manages Oracle Database Vault roles and configuration.

In a default Oracle Audit Vault installation, this account name is based on the default Oracle Audit Vault AV_ADMIN user account, with dvo appended. For example, if you created avadmin as the AV_ADMIN user, then the DV_OWNER account name is avadmindvo.

1.6 Planning the Source Database and Collector Configuration

This section contains:

1.6.1 About Planning the Source Database and Collector Configuration

This section provides guidelines for selecting the correct Oracle Audit Vault collector for the source databases from which you want to extract audit data. In brief, for Oracle Database, the type of collector that you select depends on the type of auditing that you have enabled in the source database. The Microsoft SQL Server, Sybase ASE, and IBM DB2 databases each use one collector specific to each of these database products.

After you understand which collector to choose, you are ready to register the source database and collector with Oracle Audit Vault.

1.6.2 Planning the Oracle Source Database and Collector Configuration

To plan the Oracle Database source database and collector configuration:

  1. Ensure that auditing has been enabled, and find the type of auditing that the Oracle source database uses.

    See Oracle Audit Vault Auditor's Guide for more information about the Oracle Database requirements.

  2. Based on the audit trail setting, determine which collector to use.

    The type of auditing that has been enabled determines the collector you will choose. The types of collectors available are as follows:

    • OSAUD collector. Use this collector if the audit trail is being written to operating system files. Table 1-8 lists the operating system audit trail settings that use the OSAUD collector.

    • DBAUD collector. Use this collector if the audit trail is being written to the database audit trail. Table 1-9 lists of the database audit trail settings that use the DBAUD collector.

    • REDO collector. Use this collector if the database is collecting audit data from the redo logs. Table 1-10 shows more information about redo logs.

  3. Register the Oracle source database and the appropriate collector with Oracle Audit Vault, as described in Section 2.3.

The OSAUD operating system audit settings capture the following activities:

  • SELECT statements

  • Data definition language (DDL) and data manipulation language (DML) statements

  • Succeeded and failed actions

  • SYS operations (Set the AUDIT_SYS_OPERATIONS initialization parameter to TRUE to perform administrator auditing. SYS auditing collects SQL text information.)

Table 1-8 lists the Oracle Database operating system audit settings that use the OSAUD collector.

Table 1-8 Oracle Database Operating System Audit Settings for the OSAUD Collector

Audit Trail Audit Trail Setting Comments

Linux and UNIX-based platforms (.aud)

For standard audit records: The AUDIT_TRAIL initialization parameter is set to OS.

For fine-grained audit records: Not applicable.

None

Linux and UNIX-based platforms (.xml)

For standard audit records: The AUDIT_TRAIL initialization parameter is set to XML or XML, EXTENDED.

For fine-grained audit records: The audit_trail parameter of the DBMS_FGA.ADD_POLICY procedure is set to DBMS_FGA.XML or DBMS_FGA.XML + DBMS_FGA.EXTENDED.

EXTENDED writes SQL text and SQL bind information to the audit trail.

Linux and UNIX-based platforms (syslog)

For standard audit records: The AUDIT_TRAIL initialization parameter is set to OS, and the AUDIT_SYSLOG_LEVEL parameter is set.

For fine-grained audit records: Not applicable

More secure than audit records stored in operating system audit trail

Windows platform

Windows Event Log

For standard audit records: The AUDIT_TRAIL initialization parameter is set to OS.

For fine-grained audit records: Not applicable

None

Windows platform

Operating system XML files (.xml)

For standard audit records: The AUDIT_TRAIL initialization parameter is set to XML or XML, EXTENDED.

For fine-grained audit records: The audit_trail parameter of the DBMS_FGA.ADD_POLICY procedure is set to DBMS_FGA.XML or DBMS_FGA.XML + DBMS_FGA.EXTENDED.

EXTENDED writes SQL text and SQL bind information to the audit trail.

Table 1-9 lists the Oracle Database database audit trail settings, which must use the DBAUD collector.

Table 1-9 Oracle Database Audit Trail Settings for the DBAUD Collector

Audit Trail Audit Trail Setting Audited Operations Comments

SYS.AUD$

For standard audit records: The AUDIT_TRAIL initialization parameter is set to DB or DB, EXTENDED.

For fine-grained audit records: Not applicable

SELECT, DML, DDL, success and failure, SQL text, SQL bind

EXTENDED writes SQL text and SQL bind data to the audit trail.

SYS.FGA_LOG$

For standard audit records: Not applicable

For fine-grained audit records: The audit_trail parameter of the DBMS_FGA.ADD_POLICY procedure is set to DBMS_FGA.DB or DBMS_FGA.DB + DBMS_FGA.EXTENDED.

Very specific user-defined audited conditions, such as the time a user modified a table column

None

DVSYS.AUDIT_TRAIL$

Not applicable. The Oracle Database Vault audit trail collects data even if Oracle Database auditing is disabled.

Oracle Database Vault audit activity specified by audit options on realms, command rules, and so on

None

Table 1-10 shows the redo log audit trail setting that uses the REDO collector.

Table 1-10 Oracle Database Redo Log Setting for the REDO Collector

Audit Trail Audit Trail Setting Audited Operations Comments

Redo logs

Audit Vault capture rule (see Oracle Audit Vault Auditor's Guide

DML, DDL, before and after values

Tracks before and after changes to sensitive data columns.

1.6.3 Planning the Microsoft SQL Server Source Database and Collector Configuration

To plan the Microsoft SQL Server source database configuration:

  1. Ensure that auditing has been enabled in the SQL Server source database.

    See the Microsoft SQL Server product documentation for more information.

  2. Understand the audit trail settings used for SQL Server databases.

    Table 1-11 lists the SQL Server audit trail settings.

  3. Configure the MSSQLDB collector to collect audit data from the SQL Server database, as described in Section 2.4.

Table 1-11 describes the SQL Server audit trail.

Table 1-11 Microsoft SQL Server Source Database Audit Settings for the 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 all actions

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. It is deleted 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

1.6.4 Planning the Sybase ASE Source Database and Collector Configuration

To plan the Sybase ASE source database configuration:

  1. Ensure that auditing has been enabled in the Sybase ASE source database.

    See the Sybase ASE product documentation for more information.

  2. Understand the audit trail setting information used for Sybase ASE databases.

    Table 1-12 shows the Sybase ASE audit trail setting information.

  3. Configure the SYBDB collector to collect audit data from the SQL Server database, as described in Section 2.5.

Table 1-12 describes the Sybase ASE audit trail.

Table 1-12 Sybase ASE Database Audit Setting for the SYBDB Collector

Audit Trail - Audit Logs Audit Trail Setting Audited Operation Comments

System audit table logs

Run system procedures to set global audit options, and then to enable, disable, or restart auditing.

Records standard to fine-grained audit and security-related activity

Can choose exactly what to audit

Can choose to audit everything or just very specific events

Implement your best practices for Sybase ASE database auditing

1.6.5 Planning the IBM DB2 Source Database and Collector Configuration

To plan the IBM DB2 source database configuration:

  1. Ensure that auditing has been enabled in the IBM DB2 source database.

    See the IBM DB2 product documentation for more information.

  2. Understand the audit trail information used for IBM DB2 databases.

    Table 1-13 shows the IBM DB2 audit trail setting information.

  3. Configure the DB2DB collector to collect audit data from the DB2 database, as described in Section 2.6.

Table 1-13 describes the IBM DB2 audit trail.

Table 1-13 IBM DB2 Database Audit Setting for the DB2DB Collector

Audit Trail - Audit Logs Audit Trail Setting Audited Operation Comments

ASCII text files

Run the DB2AUDIT command to enable auditing, disable auditing, and set auditing operations.

Audit (AUDIT). Changes to audit records or times that the audit log is accessed

Authorization Checking (CHECKING). Authorization checking during attempts to access or manipulate DB2 database objects or functions

Security Maintenance (SECMAINT). Grants or revokes to object or database privileges or to the DBADM privilege; also modification of the SYSADM_GROUP, SYSCTRL_GROUP, or SYSMAINT_GROUP configuration parameters

Object Maintenance (OBJMAINT). Creating and dropping data objects

System Administration (SYSADMIN). Operations requiring SYSADM, SYSMAINT, or SYSCTRL privileges

User Validation (VALIDATE). Authentication of users or retrieval of system security information

Operation Context (CONTEXT). Database operation context performed. Helps when interpreting the audit log file. See the IBM DB2 documentation for more information about how the operation context of a DB2 database is audited.

In addition to these categories, you can audit successes, failures, or both.

Implement your best practices for IBM DB2 database auditing

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