2 Creating Oracle Audit Vault Policies and Alerts

This chapter contains:

• About Oracle Audit Vault Policies and Alerts

• Fetching Audit Policy Settings from the Source Oracle Database

• Creating Oracle Vault Audit Policies for SQL Statements

• Creating Oracle Audit Vault Policies for Schema Objects

• Creating Oracle Audit Vault Policies for Privileges

• Creating Oracle Audit Vault Policies for Fine-Grained Auditing

• Creating Capture Rules for Redo Log File Auditing

• Verifying Oracle Audit Vault Policy Settings

• Exporting Oracle Audit Vault Policies to the Source Oracle Database

• Copying Oracle Audit Vault Policies to Other Oracle Databases

• Configuring Alerts

2.1 About Oracle Audit Vault Policies and Alerts

In the Audit Vault Console, you can create the following types of audit policies for Oracle databases:

• SQL statements

• Schema objects

• Privileges

• Fine-grained auditing

• Capture rules (for redo log file activities)

• Alerts

In general, to create Oracle Audit Vault policies and alerts, you follow these steps:

1. Fetch the current policy settings from the source Oracle database.

   See Section 2.2 for more information.

2. Create audit policies.

   See the following sections:

   • Section 2.3 to create SQL statement policies

   • Section 2.4 to create schema object policies

   • Section 2.5 to create privilege policies

   • Section 2.6 to create fine-grained auditing policies

   • Section 2.7 to create capture rules for redo log file auditing

   • Section 2.8 to verify the Oracle Audit Vault policies

3. Save the Oracle Audit Vault policy settings to a .sql file or manually provision them to the source database.

   See the following sections:

   • Section 2.9 to export the policies to the source Oracle database

   • Section 2.10 to copy the policy settings to other Oracle databases

4. Optionally, create alerts.

   See Section 2.11 for more information.

2.2 Fetching Audit Policy Settings from the Source Oracle Database

Before you create policies and alerts in the Audit Vault Console, you must fetch the current audit settings that have been created in the source Oracle database. This way, you have a snapshot of the audit settings in the source database from that point in time, before you begin to create policies and alerts.

Follow these steps:

• Step 1: Retrieve the Audit Settings from the Source Oracle Database

• Step 2: Activate (Update) the Fetched Audit Settings State

2.2.1 Step 1: Retrieve the Audit Settings from the Source Oracle Database

To retrieve audit settings from the source Oracle Database:

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 start the Audit Vault Console. The Overview page appears.

2. In the Audit Vault Console, select the Audit Policy tab.

3. From the Audit Source listing, select the source database, and then click the Retrieve from Source button.

   To filter the list of audit sources, enter text in the Audit Source text field or click the flashlight symbol to display the Search And Select: Audit Source page. If you make selections on the Search And Select: Audit Source page, when you return, the Audit Source column will be populated with your selections.

   The Audit Vault Console displays a summary of audit settings for the source database.

At this stage, you are ready to view the audit settings. Table 2-1 shows the fields used in the audit settings list in the Audit Settings page, which indicate the state of the source database. If the Problem field contains a value higher than 0, then most likely you need to activate (that is, update for use in Oracle Audit Vault) the audit settings. If the Problem field is set to 0, then all the existing audit settings already have been activated.

Table 2-1 Fields Under Apply Audit Settings in the Audit Settings Page

Field	Description
Select	Select which audit source to retrieve
Audit Source	Displays the name of the audit source
In Use	Number of active settings in the source database
Needed	Number of audit settings you (the auditor) have specified to be required
Problem	Number of audit settings that require attention by the auditor
Audit Trail	The location to which database audit records are directed, based on the AUDIT_TRAIL initialization parameter. See Oracle Database Reference for the AUDIT_TRAIL parameter values. If the setting is NONE, then ask the database administrator to enable auditing. See Section 1.3.1.1 for more information.
Audit Sys	Indicates that the SYS user is being audited
Last Retrieved	The time that the information for the selected audit source was last retrieved
Last Provisioned	The time that the settings were provisioned to the source database

2.2.2 Step 2: Activate (Update) the Fetched Audit Settings State

After you retrieve the source database, you are can view the audit settings so that you can modify them as needed. Remember that you are capturing a snapshot of the audit settings from a particular point in time: if these settings change in the source database, you then will need to retrieve the audit settings again.

1. In the Audit Settings page, select the name of the source database listed in the Audit Source field.

   The Apply Audit Settings section appears. In the following example, the Problem field shows that there are three SQL statement audit settings that may be activated or removed from the source database. None of the other audit settings types need to be activated.

   A non-zero value in the Problem field can indicate that an audit policy that was created in the source database has not yet been updated in Oracle Audit Vault. If you do not need the audit policy, then do not activate it. In that case, later on when you provision the Audit Vault settings back to the source database, this audit policy is deleted in the source database.

   
   Description of the illustration apply_audits.gif
   
   

2. To update the statement audit settings, select the Statement tab.

   The Statement page appears. The settings that need to be updated are indicated with an X in the Needed column. As the Audit Vault Auditor, you can indicate that the audit policies are required.

   
   Description of the illustration fetch_settings.gif
   
   

3. Select each X in the Needed column to update the audit settings for SQL statements. Alternatively, click the Mark All as Needed button to update the settings for all the SQL statements.

   A check mark indicates that the Audit Vault auditor has determined that the audit setting is needed. A green up arrow in the In Use column indicates that the policy is active in the source database. A red X in the Needed column indicates that the policy is not active in the source database.

At this stage, the audit settings between the source database and Oracle Audit Vault should be the same, except for any settings that you have omitted in Step 3, or if changes in the audit settings are made independently in the source database.

2.3 Creating Oracle Vault Audit Policies for SQL Statements

This section contains:

• About SQL Statement Auditing

• Defining a SQL Statement Audit Policy

2.3.1 About SQL Statement Auditing

Statement auditing audits SQL statements by type of statement, not by the specific schema objects on which the statement operates. Statement auditing can be broad or focused, for example, by auditing the activities of all database users or of only a select list of users. Typically broad, statement auditing audits the use of several types of related actions for each option. These statements are in the following categories:

• Data definition statements (DDL). For example, AUDIT TABLE audits all CREATE TABLE and DROP TABLE statements. AUDIT TABLE tracks several DDL statements regardless of the table on which they are issued. You can also set statement auditing to audit selected users or every user in the database.

• Data manipulation statements (DML). For example, AUDIT SELECT TABLE audits all SELECT ... FROM TABLE or SELECT ... FROM VIEW statements, regardless of the table or view.

2.3.2 Defining a SQL Statement Audit Policy

To define a SQL statement audit policy:

1. If necessary, retrieve and activate the current statement audit policies.

   See Section 2.2 for more information.

2. In the Audit Settings page, select the Statement tab to display the Statement page.

   Table 2-2 describes the fields used in the Statement page.

3. Click the Create button and in the Create Statement Audit page, define the audit policy.

   Table 2-3 describes the Create Statement Audit fields.

4. Click OK.

   The statement audit policy is created. To ensure that the statement audit policy is semantically correct, see Section 2.8.

5. In the Overview page, select Save All Audit Settings.

   To display the Overview page, click the Audit Settings link, and then in the Audit Settings page, select the name of the source database.

Table 2-2 lists the fields used in the Statement page.

Table 2-2 Fields in the Statement Page

Field	Description
(Left-most column)	An exclamation mark icon indicates one of the following conditions: The statement is needed but not in use. The statement is in use but not needed.
Statement	The statement that is audited
User	The user to which this setting applies, if any
Proxy User	The proxy user for the database, if any
Execution Condition	The execution condition audited: WHENEVER SUCCESSFUL, WHENEVER NOT SUCCESSFUL, or BOTH
Audit granularity	The granularity of auditing: BY ACCESS or BY SESSION
In Use	The arrow points upward if the setting is active in the source database and downward if it has not been provisioned or is not active.
Needed	A check mark indicates that the policy is needed. An X indicates that the policy is not needed. If a policy that is not in use is set to needed, the In Use arrow points up after provisioning. If a policy that is in use is set to not needed, the audit policy is no longer displayed after provisioning.
(Right-most column)	Click the trash can icon to remove the policy. You only can use the trash can icon to remove the policy if you had just created it and decided it was not required in the source database, or if it is not active in the source database.

Table 2-3 lists the fields used in the Create Statement Audit page.

Table 2-3 Fields in the Create Statement Audit Page

Field	Description
Statements	Select the SQL statements to audit. To display a list of SQL statements from which to select, click the flashlight icon. Examples are: ALTER TABLE DATABASE LINK DROP DIRECTORY
Audited By	Choose the category of users to audit: All: Audits all users, including proxy users. User: Audits the user to which this setting applies. When you select this option, the Users box appears, in which you must specify at least one user. To display a list of users and their audit sources from which to select, click the flashlight icon. Proxy User: Audits the proxy user for the database. When you select this option, the Proxy User box appears, in which you must specify at least one user. To display a list of proxy users and their audit sources from which to select, click the flashlight icon.
Statement Execution Condition	Choose the execution condition: Both: Audits both successful and failed statements Success: Audits the statement if it is successful Failure: Audits the statement if it fails
DML Audit Granularity	Choose the level of granularity: Access: Creates an audit record each time the operation occurs Session: Creates an audit record the first time an operation occurs in the current session

2.4 Creating Oracle Audit Vault Policies for Schema Objects

This section contains:

• About Schema Object Auditing

• Defining a Schema Object Audit Policy

2.4.1 About Schema Object Auditing

Schema object auditing is the auditing of specific statements on a particular schema object, such as AUDIT SELECT ON HR.EMPLOYEES. Schema object auditing is very focused, auditing only a specific statement on a specific schema object for all users of the database.

For example, object auditing can audit all SELECT and DML statements permitted by object privileges, such as SELECT or DELETE statements on a given table. The GRANT and REVOKE statements that control those privileges are also audited.

Object auditing lets you audit the use of powerful database commands that enable users to view or delete very sensitive and private data. You can audit statements that reference tables, views, sequences, standalone stored procedures or functions, and packages.

Oracle Database and Oracle Audit Vault always set schema object audit options for all users of the database. You cannot set these options for a specific list of users.

2.4.2 Defining a Schema Object Audit Policy

To define a schema object audit policy:

1. If necessary, retrieve and activate the current object audit policies.

   See Section 2.2 for more information.

2. In the Audit Settings page, select the Object tab to display the Object page.

   Table 2-4 describes the fields used in the Object page.

3. Click the Create button and in the Create Object Audit page, define the audit policy.

   Table 2-5 describes the Create Object Audit fields.

4. Click OK.

   The object audit policy created. To ensure that the object audit policy is semantically correct, see Section 2.8.

5. In the Overview page, select Save All Audit Settings.

   To display the Overview page, click the Audit Settings link, and then in the Audit Settings page, select the name of the source database.

Table 2-4 lists the fields used in the Object page.

Table 2-4 Fields in the Object Page

Field	Description
(Left-most column)	An exclamation mark icon indicates one of the following conditions: The statement is needed but not in use. The statement is in use but not needed.
Statement	The statement that is audited
Schema	The database schema to which this setting applies
Object	The object to which this setting applies
Execution Condition	The execution condition audited: WHENEVER SUCCESSFUL, WHENEVER NOT SUCCESSFUL, or BOTH
Audit granularity	The granularity of auditing: BY ACCESS or BY SESSION
In Use	The arrow points upward if the setting is active in the source database and downward if it has not been provisioned or is not active.
Needed	A check mark indicates that the policy is needed. An X indicates that the policy is not needed. If a policy that is not in use is set to needed, the In Use arrow points up after provisioning. If a policy that is in use is set to not needed, the audit policy is no longer displayed provisioning.
(Right-most column)	Click the trash can icon to remove the policy. You only can use the trash can icon to remove the policy if you had just created it and decided it was not required in the source database, or if it is not active in the source database.

Table 2-5 lists the fields used in the Create Object Audit page.

Table 2-5 Fields in the Create Object Audit Page

Field	Description
Statements	Select the SQL statements to audit. To display a list of SQL statements from which to select, click the flashlight icon. Examples are: ALTER AUDIT UPDATE
Object Type	Select the type of object to audit, such as table. To display a list of object types and their audit sources from which to select, click the flashlight icon. Examples are: LOB RULE VIEW
Object	Optional. Select the object to audit. To display a list of objects and their source databases from which to select, and to filter the list by audit source and object owner, click the flashlight icon. For example, if you entered TABLE for Object Type and HR for Object Owner, you could select EMPLOYEES, JOBS, or any of the other tables in the HR schema.
Statement Execution Condition	Choose the execution condition: Both: Audits both successful and failed statements Success: Audits the statement if it is successful Failure: Audits the statement if it fails
DML Audit Granularity	Choose the level of granularity: Access: Creates an audit record each time the operation occurs Session: Creates an audit record the first time an operation occurs in the current session

2.5 Creating Oracle Audit Vault Policies for Privileges

This section contains:

• About Privilege Auditing

• Defining a Privilege Audit Policy

2.5.1 About Privilege Auditing

Privilege auditing is the auditing of SQL statements that use a system privilege. You can audit the use of any system privilege. Like statement auditing, privilege auditing can audit the activities of all database users or of only a specified list of users.

For example, if you enable AUDIT SELECT ANY TABLE, Oracle Database audits all SELECT tablename statements issued by users who have the SELECT ANY TABLE privilege. This type of auditing is very important for the Sarbanes-Oxley (SOX) Act compliance requirements. Sarbanes-Oxley and other compliance regulations require the privileged user be audited for inappropriate data changes or fraudulent changes to records.

Privilege auditing audits the use of powerful system privileges enabling corresponding actions, such as AUDIT CREATE TABLE. If you set both similar statement and privilege audit options, then only a single audit record is generated. For example, if the statement clause TABLE and the system privilege CREATE TABLE are both audited, then only a single audit record is generated each time a table is created. The statement auditing clause, TABLE, audits CREATE TABLE, ALTER TABLE, and DROP TABLE statements. However, the privilege auditing option, CREATE TABLE, audits only CREATE TABLE statements, because only the CREATE TABLE statement requires the CREATE TABLE privilege.

Privilege auditing does not occur if the action is already permitted by the existing owner and schema object privileges. Privilege auditing is triggered only if these privileges are insufficient, that is, only if what makes the action possible is a system privilege.

Privilege auditing is more focused than statement auditing for the following reasons:

• It audits only a specific type of SQL statement, not a related list of statements.

• It audits only the use of the target privilege.

2.5.2 Defining a Privilege Audit Policy

To define a privilege audit policy:

1. If necessary, retrieve and activate the current privilege audit policies.

   See Section 2.2 for more information.

2. In the Audit Settings page, select the Privilege tab to display the Privilege page.

   Table 2-6 describes the fields used in the Privilege page.

3. Click the Create button and in the Create Privilege Audit page, define the privilege audit policy.

   Table 2-7 describes the Create Privilege Audit fields.

4. Click OK.

   The privilege audit policy is created. To ensure that the privilege audit policy is semantically correct, see Section 2.8.

5. In the Overview page, select Save All Audit Settings.

   To display the Overview page, click the Audit Settings link, and then in the Audit Settings page, select the name of the source database.

Table 2-6 lists the fields used in the Privilege page.

Table 2-6 Fields in the Privilege Page

Field	Description
(Left-most column)	An exclamation mark icon indicates one of the following conditions: The statement is needed but not in use. The statement is in use but not needed.
Privilege	The privilege that is audited
User	The user to which this setting applies
Proxy User	The proxy user for the database, if any
Execution Condition	The execution condition audited: WHENEVER SUCCESSFUL, WHENEVER NOT SUCCESSFUL, or BOTH
Audit granularity	The granularity of auditing: BY ACCESS or BY SESSION
In Use	The arrow points upward if the setting is active in the source database and downward if it has not been provisioned or is not active.
Needed	A check mark indicates that the policy is needed. An X indicates that the policy is not needed. If a policy that is not in use is set to needed, the In Use arrow points up after provisioning. If a policy that is in use is set to not needed, the audit policy is no longer displayed provisioning.
(Right-most column)	Click the trash can icon to remove the policy. You only can use the trash can icon to remove the policy if you had just created it and decided it was not required in the source database, or if it is not active in the source database.

Table 2-7 lists the fields used in the Create Privilege Audit page.

Table 2-7 Fields in the Create Privilege Audit Page

Field	Description
Privilege	Select the privilege to audit. To display a list of privileges from which to select, click the flashlight icon. Examples are: ADMINISTER DATABASE TRIGGER CREATE ANY TABLE MANAGE TABLESPACE
Audited By	Choose the category of users to audit: All: Audits all users, including proxy users. User: Audits the user to which this setting applies. When you select this option, the Users box appears, in which you must specify at least one user. To display a list of users and their audit sources from which to select, click the flashlight icon. Proxy User: Audits the proxy user for the database. When you select this option, the Proxy User box appears, in which you must specify at least one user. To display a list of proxy users and their audit sources from which to select, click the flashlight icon.
Statement Execution Condition	Choose the execution condition: Both: Audits both successful and failed statements Success: Audits the statement if it is successful Failure: Audits the statement if it fails
DML Audit Granularity	Choose the level of granularity: Access: Creates an audit record each time the operation occurs Session: Creates an audit record the first time an operation occurs in the current session

2.6 Creating Oracle Audit Vault Policies for Fine-Grained Auditing

This section contains:

• About Fine-Grained Auditing

• Defining a Fine-Grained Auditing Policy

2.6.1 About Fine-Grained Auditing

Fine-grained auditing (FGA) enables you to create a policy that defines specific conditions that must take place for the audit to occur. For example, fine-grained auditing lets you audit the following types of activities:

• A table being accessed between 9 p.m. and 6 a.m. or on Saturday and Sunday

• An IP address from outside the corporate network being used

• A table column being selected or updated

• A value in a table column being modified

A fine-grained audit policy provides granular auditing of select, insert, update, and delete operations. Furthermore, because you are auditing only very specific conditions, you reduce the amount of audit information generated and can restrict auditing to only the conditions that you want to audit. This creates a more meaningful audit trail that supports compliance requirements. For example, a central tax authority can use fine-grained auditing to track access to tax returns to guard against employee snooping, with enough detail to determine what data was accessed. It is not enough to know that a specific user used the SELECT privilege on a particular table. Fine-grained auditing provides a deeper audit, such as when the user queried the table or the computer IP address user who performed the action.

2.6.1.1 Auditing Specific Columns and Rows

When you define the fine-grained audit policy, you can target one or more specific columns, called a relevant column, to be audited if a condition is met. This feature enables you to focus on particularly important, sensitive, or privacy-related data to audit, such as the data in columns that hold U.S. Social Security numbers, credit card numbers, patient diagnoses, and so on. A relevant-column audit helps reduce the instances of false or unnecessary audit records, because the audit must be triggered only when a particular column is referenced in the query.

Used with a condition, you can further fine-tune the audit to specific columns and rows. For example, suppose you enter the following fields in the Create Fine Grained Audit page:

• Condition: department_id = 50

• Columns: salary, commission_pct

This setting audits anyone who tries to select data from the salary and commission columns of employees in Department 50.

If you do not specify a relevant column, then Oracle Database applies the audit to all the columns in the table, that is, auditing occurs whenever any specified statement type affects any column, whether or not any rows are returned.

2.6.1.2 Using Event Handlers in Fine-Grained Auditing

In the fine-grained audit policy, you can specify an event handler to process an audit event. The event handler provides flexibility in determining how to handle a triggering audit event. For example, it could write the audit event to a special audit table for further analysis, or it could send a pager or an e-mail alert to a security administrator. This feature enables you to fine-tune audit responses to appropriate levels of escalation.

For additional flexibility in implementation, you can employ a user-defined function to determine the policy condition, and identify a relevant column for auditing (audit column). For example, the function could allow unaudited access to any salary as long as the user is accessing data within the company, but audit access to executive-level salaries when they are accessed from the outside the company.

2.6.2 Defining a Fine-Grained Auditing Policy

To define a fine-grained auditing policy:

1. If necessary retrieve and activate the current fine-grained auditing policies.

   See Section 2.2 for more information.

2. In the Audit Settings page, select the FGA tab to display the FGA page.

   Table 2-8 describes the fields used in the FGA page.

3. Click the Create button and in the Create Fine Grained Audit page, define the audit policy.

   Table 2-9 describes the Create Fine Grained Audit fields.

4. Click OK.

   The fine-grained audit policy is created. To ensure that the fine-grained audit policy is semantically correct, see Section 2.8.

5. In the Overview page, select Save All Audit Settings.

   To display the Overview page, click the Audit Settings link, and then in the Audit Settings page, select the name of the source database.

Table 2-8 lists the fields used in the Fine-Grained Audit page.

Table 2-8 Fields in the Fine-Grained Audit Page

Field	Description
(Left-most column)	An exclamation mark icon indicates one of the following conditions: The statement is needed but not in use. The statement is in use but not needed.
Policy Name	The name of this fine-grained audit policy
Schema	The schema to which this policy applies
Object	The object to which this policy applies
Statement	The SQL statement to which this policy applies. Values are: S: SELECT SQL statement I: INSERT SQL statement U: UPDATE SQL statement D: DELETE SQL statement M: MERGE SQL statement
Columns	The database columns being audited, also referred to as the relevant column. If this field is empty, all columns are audited.
In Use	The arrow points upward if the setting is active in the source database and downward if it has not been provisioned or is not active.
Needed	A check mark indicates that the policy is needed. An X indicates that the policy is not needed. If a policy that is not in use is set to needed, the In Use arrow points up after provisioning. If a policy that is in use is set to not needed, the audit policy is no longer displayed provisioning.
(Right-most column)	Click the trash can icon to remove the policy. You only can use the trash can icon to remove the policy if you had just created it and decided it was not required in the source database, or if it is not active in the source database.

Table 2-9 lists the fields in the Create Fine-Grained Audit page.

Table 2-9 Fields in the Create Fine-Grained Audit Page

Field	Description
Policy Name	Enter a name for this fine-grained audit policy.
Audit Trail	Select from one of the following audit trail types: Database: Writes the policy records to the database audit trail SYS.FGA_LOG$ system table. Database with SQL Text:Performs the same function as the Database option, but also populates the SQL bind and SQL text CLOB-type columns of the SYS.FGA_LOG$ table. XML: Writes the policy records to an operating system XML file. To find the location of this file, a database administrator can run the following command in SQL*Plus: SQL> show parameter audit_file_dest XML with SQL Text: Performs the same function as the XML option, but also includes all columns of the audit trail, including SQLTEXT and SQLBIND values.
Object	Select an object to audit, for example OE.CUSTOMERS. To display a list from which to select and to filter objects by audit source, object owner, and object, click the flashlight icon. For example, if you entered OE in the Object Owner box, you could select the CUSTOMERS, ORDERS, or another table in the OE schema.
Statements	Select one or more SQL statements to audit. To display a list of statements from which to choose, click the flashlight icon. Select from the following SQL statements: SELECT INSERT UPDATE DELETE MERGE
Columns	Optional. Enter the names of the database columns (relevant columns) to audit. Separate each column name with a comma. If you enter more than one column, select All or Any as the condition that triggers this policy. For example, assuming you selected the OE.CUSTOMERS table: CUSTOMER_ID, CREDIT_LIMIT, DATE_OF_BIRTH See Section 2.6.1.1 for more information about relevant columns.
Condition	Optional. Enter a Boolean condition to filter row data. For example: department_id = 50 If this field is blank or Null, auditing occurs regardless of condition.
Handler Schema	Mandatory if you specify an event handler. Enter the name of the schema account in which the event handler was created. For example: SEC_MGR See Section 2.6.1.2 for more information about event handlers.
Handler Package	Mandatory if you specify an event handler. Enter the name of the package in which the event handler was created. For example: OE_FGA_POLICIES
Handler	Optional. Enter the name of the event handler. If you specify an event handler, then specify its schema and package as well. For example: CHECK_OE_VIOLATIONS

2.7 Creating Capture Rules for Redo Log File Auditing

This section contains:

• About Capture Rules Used for Redo Log File Auditing

• Defining a Capture Rule for Redo Log File Auditing

2.7.1 About Capture Rules Used for Redo Log File Auditing

You can create a capture rule to track changes in the database redo log files. The capture rule specifies DML and DDL changes that should be checked when Oracle Database scans the database redo log. You can apply the capture rule to an individual table, a schema, or globally to the entire database. Unlike statement, object, privilege, and fine-grained audit policies, you do not retrieve and activate capture rule settings from a source database, because you cannot create them there. You only can create the capture rule in the Audit Vault Console.

2.7.2 Defining a Capture Rule for Redo Log File Auditing

To define a capture rule:

1. In the Audit Settings page, select the Capture Rule tab to display the Capture Rule page.

   Table 2-10 describes the fields used in the Capture Rule page.

2. Click the Create button and in the Create Capture rule page, define the capture rule.

   Table 2-11 describes the Create Capture Rule page fields.

3. Click OK.

   The capture rule is created. To ensure that the capture rule is semantically correct, see Section 2.8.

4. In the Overview page, select Save All Audit Settings.

   To display the Overview page, click the Audit Settings link, and then in the Audit Settings page, select the name of the source database.

Table 2-10 lists the fields used in the Capture Rule page.

Table 2-10 Fields in the Capture Rule Page

Field	Description
(Left-most column)	An exclamation mark icon indicates one of the following conditions: The statement is needed but not in use. The statement is in use but not needed.
Rule Type	The types of capture rules are as follows: Table: Captures or discards either row changes resulting from DML changes or DDL changes to a particular table. Schema: Captures or discards either row changes resulting from DML changes or DDL changes to the database objects in a particular schema. Global: Captures or discards either all row changes resulting from DML changes or all DDL changes in the database.
Schema	Indicates the schema to which this rule applies
Table	For table capture rules, this indicates the table to which this rule applies.
DDL	YES or NO indicates whether data definition language (DDL) statements are audited.
DML	YES or NO indicates whether data manipulation language (DML) statements are audited.
In Use	The arrow points upward if the setting is active in the source database and downward if it has not been provisioned or is not active.
Needed	A check mark indicates that the policy is needed. An X indicates that the policy is not needed. If a policy that is not in use is set to needed, the In Use arrow points up after provisioning. If a policy that is in use is set to not needed, the audit policy is no longer displayed provisioning.
(Right-most column)	Click the trash can icon to remove the policy. You only can use the trash can icon to remove the policy if you had just created it and decided it was not required in the source database, or if it is not active in the source database.

Table 2-11 lists the fields used in the Create Capture Rule page.

Table 2-11 Fields in the Create Capture Rule Page

Field	Description
Capture Rule	Select from the follow capture rule types: Table: Captures either row changes resulting from DML changes or DDL changes to a particular table. The Table box appears; enter the name of the table to which the capture rule applies. To display a list of tables and their audit sources, and to filter by object owner and object, click the flashlight icon. Schema: Captures either row changes resulting from DML changes or DDL changes to the database objects in a particular schema. The Schema box appears; enter the name of the schema, or click the flashlight icon to select from a list. Global: Captures either all row changes resulting from DML changes or all DDL changes in the database.
Capture	Select from the following: DDL (data definition language) DML (data manipulation language) Both

2.8 Verifying Oracle Audit Vault Policy Settings

After you have created an audit policy or capture rule, you can verify its semantic correctness.

1. In the Overview page, click the Audit Policy tab.

   From within the Audit Vault Console, click the Database Instance link to display the Overview page.

2. Select the name of the source database.

   The Apply Audit Settings section appears.

3. Select the audit settings types that you want to verify: Statement, Object, Privilege, FGA, or Capture Rule.

   By default, all audit types are selected.

4. Click the Verify button.

   The Audit Vault Console displays a message letting you know that the settings have been verified.

2.9 Exporting Oracle Audit Vault Policies to the Source Oracle Database

After you have created, verified, and saved the audit policies and capture rules, you need to export them to the source database. This ensures that the audit settings in the source database and Oracle Audit Vault are the same.

You can export the settings in the following ways:

• Save the settings to a SQL script. Afterwards, give this script to your database administrator so that he or she can apply the policies to the source database.

• Provision the audit settings to the source database yourself. You can provision the settings if you have been granted EXECUTE privileges for the AUDIT SQL statement, the NOAUDIT SQL statement, and DBMS_FGA PL/SQL package.

After you export the audit settings to the source database, a database administrator can modify or delete audit policies. For this reason, you should periodically fetch the settings to ensure that you have the latest audit settings. Section 2.2 describes how to fetch audit settings.

1. In the Overview page, click the Audit Policy tab.

   From within the Audit Vault Console, click the Database Instance link to display the Overview page.

2. Select the name of the source database.

   The Apply Audit Settings section appears.

3. Select from the audit settings types the audit settings you want to export: Statement, Object, Privilege, FGA, or Capture Rule.

   By default, all the audit settings types are selected.

4. Use one of the following methods to export the audit settings:

   • Exporting to a SQL file: Click Export as SQL. In the Browse dialog box, select a location for the SQL file.

   • Provisioning to the source database: In the Audit Source User Name and Audit Source Password fields, enter the name and password of a user who has been granted EXECUTE privileges for the AUDIT SQL statement, the NOAUDIT SQL statement, and DBMS_FGA PL/SQL package. Then click Provision.

2.10 Copying Oracle Audit Vault Policies to Other Oracle Databases

You can copy audit policy settings from one Oracle database to another Oracle database that has been added to Oracle Audit Vault. You can copy settings that are already in use in the database or copy settings that you have created in Oracle Audit Vault but not yet applied to that database.

1. In the Overview page, click the Audit Policy tab.

   From within the Audit Vault Console, click the Database Instance link to display the Overview page.

2. Select the name of the source database.

   The Apply Audit Settings section appears.

3. Select from the audit settings types whose audit settings you want to copy: Statement, Object, Privilege, FGA, or Capture Rule.

   By default, all the audit settings types are selected.

4. In the From field under Copy Audit Settings from Another Source, enter the name of a source database that is different from the currently used source database, or use the flashlight icon to select it from a list.

5. After Copy, select either of the following options:

   • Actual (In Use): Copies the settings listed in the In Use field under Apply Audit Settings.

   • Needed (Not Yet In Use): Copies the settings listed in the Needed field under Apply Audit Settings.

6. In the From box, enter the full name of the source database from which you want to copy, or use the flashlight icon to select its name from a list.

   You can filter the source databases by source name, host name, and host IP address.

7. Click the Load button.

8. Click the Save All Audit Settings button.

9. Export the settings to a SQL file or provision the settings to the source database, using the procedure described in Section 2.9.

2.11 Configuring Alerts

This section contains:

• About Alerts

• Creating Alerts

• Configuring the Basic Alert Condition

• Configuring the Advanced Alert Condition

• Monitoring Alerts

2.11.1 About Alerts

You can configure alerts for Oracle and Microsoft SQL Server database sources. The alert is raised when the incoming audit data violates specific audit policies. You can specify an alert level, and associate the alert with the events described in Appendix B and Appendix C.

When an incoming audit record meets the specified condition, an alert is raised and placed in the alert store, where you can review it. Oracle Audit Vault updates the Overview page to reflect the alert data, and places the alert in an output queue within the Audit Vault database. An Audit Vault administrator can install software that can read this queue and process the alert appropriately. Appropriate actions can include sending a page to a security officer or filing a trouble ticket within the appropriate tracking system. Oracle Audit Vault provides an example of an alert handler, which demonstrates actions taken as a result of alerts. The source files for this handler are in the $ORACLE_HOME/av/demo/alert directory. For more information, see the README.txt file in the alert directory.

Remember that alerts are raised when the audit data reaches the Oracle Audit Vault database, not when the actual action occurs. The time lag between when the action occurs and when the alert is raised depends on several factors, including how frequently the audit data collectors collect the audit records. An Audit Vault administrator can configure this frequency.

Alerts are independent of audit policies. That is, you do not need to perform the tasks described under Section 2.2 before you create you create an alert.

2.11.2 Creating Alerts

When you create an alert, you categorize the alerts into either basic alerts or advanced alerts.

This section contains:

• Creating an Alert Rule

• Configuring the Basic Alert Condition

• Configuring the Advanced Alert Condition

2.11.2.1 Creating an Alert Rule

To create an alert rule:

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

   Section 1.4 explains how to start the Audit Vault Console.

2. In the Audit Vault Console, select the Audit Policy tab, then select the Alerts tab.

   The Audit Alerts page appears, which lists the existing alerts. You can use the Audit Source Type, Audit Source, and Audit Event Category fields to filter the list of existing alerts. To view the definition for an existing alert, select its name in the Alert Name field.

   
   Description of the illustration alerts.gif
   
   

3. Click Create.

   The Create Alert Rule page appears.

4. In the Alert box, enter the alert name and then in the Description box, enter a brief description of the alert.

5. Specify the following information: level of severity, source type, source, and event category for the alert.

   • Alert Severity: Select Warning or Critical.

   • Audit Source Type: Select one of the following audit source types:

     • MSSQLDB (for Microsoft SQL Server)

     • ORCLDB (for Oracle Database)

   • Audit Source: Select from the list of source databases based on the audit source type that you selected.

   • Audit Event Category: Select from the list of available categories, based on the audit source type that you selected. For detailed information about the audit events for these categories, see the following appendixes:

     • Appendix B, "Oracle Database Audit Events"

     • Appendix C, "Microsoft SQL Server Audit Events"

6. For the alert conditions, select either Basic or Advanced. Then go to the following sections:

   • Section 2.11.2.2 to configure a basic alert condition

   • Section 2.11.2.3 configure advanced alert condition

7. Click OK.

After you create alert rules, you can monitor the alert activity from the Overview page. See "Monitoring Alerts" for more information.

2.11.2.2 Configuring the Basic Alert Condition

Table 2-12 lists the basic alert condition fields in the Basic Alert Condition section of the Create Alert Rule page.

Table 2-12 Fields in the Basic Alert Condition Section

Field	Description
User	Specify the names of one or more users or click the flashlight icon to search for and select user names.
Table	Specify the names of one or more tables or click the flashlight icon to search for and select table names.
Audit Event	Select the name of an audit event from the list. The audit events that appear are based on the audit event category you selected. See the following appendixes for more information about audit events: Appendix B, "Oracle Database Audit Events" Appendix C, "Microsoft SQL Server Audit Events"
Audit Event Status	Select an option to represent whether the event has a status of Success, Failure, or Both.

2.11.2.3 Configuring the Advanced Alert Condition

In the Advanced Alert Condition section of the Create Alert Rule page, you construct the Boolean condition for when this alert should be evaluated. When audit data violates the Boolean condition, Oracle Audit Vault raises the alert.

Figure 2-1 shows the Advanced Alert Condition section.

Figure 2-1 Create Alert Rule Page, Advanced Alert Condition

Description of "Figure 2-1 Create Alert Rule Page, Advanced Alert Condition"

To construct a Boolean condition:

1. From the Select an event to insert in the condition list, select an event.

   The event appears in the Condition field with its associated event ID. For example, if the source database is an Oracle database and you selected INSERT from the list, Oracle Audit Vaults adds the following event code to the Condition field:

   SOURCE_EVENTID = '2'
   

   (Appendix B and Appendix C describe the event codes in detail.)

2. From the Select an attribute to insert in the condition list, select an attribute.

   For example, if you select EVENT_STATUS, it is added to the Condition field. At this stage, the Condition field appears as follows:

   SOURCE_EVENTID = '2' EVENT_STATUS
   

3. Edit the event and attribute to create a Boolean condition. In this example, you must insert the AND condition after '2' to create a valid expression.

   For example:

   SOURCE_EVENTID = '2' AND EVENT_STATUS !=0
   

   An event status of '0' specifies success in an Oracle database. A nonzero status specifies the ORA error number returned by the database in response to the event.

4. Click OK.

2.11.3 Monitoring Alerts

The Overview page is the home page for auditors to view alert summaries, drill down to reports, and view agent and collector status. To display the Overview page, select the Audit Reports tab, and then select the Home tab.

When an audit record is generated, Audit Vault classifies it into the event category that you specified when you created the alert. Audit event activity is monitored by the event category to which the audit record belongs. For example, a Logon event belongs to the User Session event category.

Audit Vault raises an alert when data in a single audit record matches an alert rule condition. Alerts are grouped by the sources with which they are associated, by the event category to which the event belongs, and by the severity level of the alert (warning or critical).

Figure 2-2 shows the Overview page.

Figure 2-2 Overview Page

Description of "Figure 2-2 Overview Page"

From the Overview page, you can:

• Select an event start time and end time in which to view Audit Vault event data.

• View five types of graphical summaries (pie charts and bar graphs) of alert activity and event activity over the specified time period. You can specify a time period by month, week, or day time span or the period between a specified begin and end date. These graphical summaries include:

  • Alert Severity Summary (pie chart)

    Click a section in this pie chart to drill down to a more detailed critical and warning alerts reports to see what sources are showing a particular severity level. See Section 3.7 for more information about critical and warning alert reports.

  • Summary of Alert Activity (pie chart)

    Click a section in this pie chart to drill down to critical and warning alerts to see the affected sources for all alert activity.

  • Top Five Audit Sources by Number of Alerts (bar graph)

    Click a bar in this bar graph to drill down to see more detailed critical and warning alert information that shows a severity level for a particular source.

  • Alerts by Audit Event Category frequency (number of alerts) (bar graph)

    Click an event category link in this bar graph to drill down to see more detailed critical and warning alert information that shows all alerts for that event category.

  • Activity by Audit Event Category frequency (number of events) (bar graph)

    Click an event category link in this bar graph to drill down to see events for that event category. You can generate default reports for the following audit event categories:

    • Account Management Report

    • Procedure Management Report

    • Audit Commands Report

    • Data Access Report

    • Database Vault Report

    • Exception Report

    • Invalid Audit Record Report

    • Object Management Report

    • Distributed Database Report

    • Role and Privilege Management Report

    • Procedure Executions Report

    • System Management Report

    • Uncategorized Activity Report

    • User Sessions Report

• Click a pie section or bar chart y-axis event category label to drill down to a more detailed report level.