2 Configuring Audit Policies

To use Oracle Audit Vault effectively, you must configure the proper settings and alerts. The management of settings and alerts is an important part of the auditor's job.

This chapter includes of the following sections:

• Configuring Audit Settings

• Configuring Alerts

2.1 Configuring Audit Settings

Auditing can be based on individual actions, such as the type of SQL statement run, or on combinations of factors that can include name, application, and time. Security policies can trigger auditing when specified elements in an Oracle Database are accessed or altered, including content.

Oracle Database auditing enables the use of several different mechanisms for auditing. The Oracle audit facility enables businesses to audit database activity by statement, by use of system privilege, by object, or by user.

For example, you can audit activity as general as all user connections to the database, and as specific as a particular user creating a table. You can also audit only successful or only unsuccessful operations. By auditing unsuccessful SELECT statements, you might catch users on "fishing expeditions" for data they are not privileged to see.

For a complete overview of database auditing, see Oracle Database Advanced Security Administrator's Guide. This section focuses on policies that can be set in Oracle Audit Vault.

2.1.1 Viewing and Defining Audit Settings

To view or define audit policies, you start from the Audit Settings Page. To reach the Audit Settings Page, click the Audit Policy tab on the dashboard. If necessary, click Audit Settings on the upper left.

The Audit Settings Page lists source names known to this Audit Vault instance. For each source, it shows the number of active (provisioned) and needed (desired) settings and the number of audit settings that require attention by the auditor. To view up-to-date policy information from the source, select the audit source from which you want to retrieve settings and click Retrieve. This operation fetches the latest policies from the source and loads them into Oracle Audit Vault.

From the Audit Settings Page, you can view detailed information about the settings for an audit source by clicking the name of the audit source. This takes you to the Overview Page, which lists the audit setting types and their number. Clicking one of the tabs on the Overview Page takes you to a page that lists the policies of that type, if any exist. See the page descriptions for more information.

To define audit policies, go to the Audit Settings Page. Then determine which Audit Source you want to define settings for and click the name of the Audit Source to go to the Overview Page.

Starting from the Overview Page, you select a policy type that you want to define for this source by clicking the corresponding tab. Clicking the tab takes you to a page where you define a policy type. Once you have defined policies, you click the Overview tab to return to the Overview Page. On the Overview Page, you can save, verify, and provision or export the policies you created.

2.1.1.1 Audit Settings Page

This page contains a complete list of source names known to this Audit Vault instance.

To retrieve policy information from the source, select the audit source from which you want to retrieve settings and click Retrieve from Source. This operation fetches the latest policies from the source and loads them into Oracle Audit Vault.

To filter the list of audit sources, enter text in the Audit Source text field or click the flashlight symbol to reach 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 field will be populated with your selections.

When you are satisfied with the selections in the Audit Source field, click Go to view information about the audit sources you have selected.

The audit settings list contains the fields shown in Table 2-1.

Table 2-1 Fields in the Audit Settings List

Field	Description
Select	Click to select which audit source to retrieve
Audit Source	Displays the name of the audit source
In Use	Number of active settings on the source system
Needed	Number of audit settings set up by the auditor but not active on the source system (that is, not provisioned)
Problem	Number of audit settings that require attention by the auditor
Audit Trail	The location to which database audit records are directed. See Oracle Database Reference for a list of possible values for AUDIT_TRAIL.
Audit Sys	Whether 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

2.1.1.2 Search And Select: Audit Source Page

On the Search And Select: Audit Source page, enter text in the Audit Source, Audit Source Host, or Audit Source Host IP fields, or a combination of fields, then click Go. When you are satisfied with the result of your search, select the audit sources you want, then click Select to return to the Audit Settings Page. The Audit Source field in the Audit Settings page will now be populated with the audit sources that you selected.

2.1.2 Overview Page

To define audit policies for an audit source, you start at the Audit Settings Page, determine which audit source you want to define settings for, and click the name of the audit source to go to the Overview page shown in Figure 2-1.

Figure 2-1 Overview Page

Description of "Figure 2-1 Overview Page"

You use the Overview page to select a policy type that you want to define for this source. Links from this page take you to other pages where you define the policies. Once you have defined the policies, you return to this page to save, verify, and provision or export the policies. To save your selections, click Save All Audit Settings.

As shown in Figure 2-1, the Overview page lists five Audit Settings Types:

• Statement

• Object

• Privilege

• FGA

• Capture Rule

In addition to Audit Statement Types, the list has the fields shown in Table 2-2.

Table 2-2 Overview Fields

Field	Description
In Use	Number of active settings on the source system
Needed	Number of audit settings set up by the auditor but not active on the source system (that is, not provisioned)
Problem	Number of audit settings that require attention by the auditor

There are tabs at the top and bottom of the page. Clicking Overview takes you back to this page. The next five tabs, Statement, Object, Privilege, FGA, and Capture Rule, correspond with the five audit categories Audit Settings Type column. Clicking one of those tabs takes you to a page that lists the policies of that type, if any exist. On each of those pages, you can click Create to create a policy of that type. The pages are:

• Statement Page

• Object Page

• Privilege Page

• FGA Page

• Capture Rule Page

Once you have used those pages to create policies, you can provision, save, or export those policies.

The user name and password are for a user with rights to provision audit settings. This can be the SYSTEM user or a user with privileges equivalent to the SYSTEM user. If you do not have the rights to provision audit settings, you cannot provision settings to the source database automatically. However, you can export settings to a file and send the file to someone with sufficient privileges.

Before saving, ensure that the appropriate check boxes are selected. Click Select All to select all audit setting types, or select one or more already defined audit setting types to be applied to a source by clicking the appropriate check box in the Select column in the Apply Audit Settings section. Click Select None to deselect all selections to clear the check boxes.

Click Save All Audit Settings to save the policies in Oracle Audit Vault. You must save the policies in Oracle Audit Vault before you verify, export, or provision them. Once policies are saved, they will be available for provisioning or exporting when you log in again.

Once you have saved a category, you can click Verify to perform a verification of semantic correctness.

To provision a policy, select the category you want to provision, enter the user name and password, then click Provision.

Note:

To provision audit settings to a source, you must have database administrator (DBA) privileges over the source. That is, you must use the SYSTEM user or a user with privileges equivalent to the SYSTEM user to provision audit settings.

Click Export as SQL to save to an external file.

You can replicate settings from another database. In the Apply Audit Settings section of the Overview page, select Actual or Needed to use settings that are in use or not yet applied, respectively. Enter text into the From field, or click the flashlight icon to make a selection, then click Go.

2.1.3 Defining a Statement Auditing Policy

Statement Auditing is the selective auditing of related groups of statements regarding a particular type of database structure or schema object, but not a specifically named structure or schema object.

Statement auditing audits SQL statements by type of statement, not by the specific schema objects on which they operate. Statement auditing can be broad or focused, for example, by auditing the activities of all database users or of only a select list. Typically broad, statement auditing audits the use of several types of related actions for each option. These statements fall into 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.1.3.1 Statement Page

You use the Statement page, shown in Figure 2-2, to create a statement audit setting.

Figure 2-2 Statement Page

Description of "Figure 2-2 Statement Page"

If statement audit settings have been created for this source, the page displays a list of existing audited statements. The list contains the fields shown in Table 2-3.

Table 2-3 Statement Fields

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. The granularity needed is different from the granularity in use.
Statement	The statement to be audited
User	The user that this setting applies to
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 has been provisioned and downward if it has not been provisioned.
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 will point up after provisioning. If a policy that is in use is set to not needed, the row will vanish after provisioning.
(Right-most column)	Click the trash can icon to remove the policy.

Click Create to go to the Create Statement Audit Page and create an audited statement setting.

2.1.3.2 Create Statement Audit Page

To create an audited statement setting, provide data for the fields on the page. The fields are shown in Table 2-4.

Table 2-4 Create Statement Audit Fields

Field	Description
Statement	The statements to be audited. Click the flashlight icon to use the Statements Audit Options page to select statements from a list. To filter the list, you can enter text in the Statements field and click Go. Select statements from the list, and click Select to return to the Create Statement Audit page.
Audited By	Select the appropriate option to indicate the users to be audited: All, User, or Proxy.
Users	The user that this setting applies to. You must set at least one user in this field or in the proxy user field. Click the flashlight icon to use the Search And Select: User page to select users from a list. To filter the list, you can enter text in the Audit Source or User field and click Go. Select users from the list, and click Select to return to the Create Statement Audit page.
Proxy User	The proxy user for the database. You must set at least one user in this field or in the User field. Click the flashlight icon to use the Search And Select: Proxy User and Client page to select proxy users from a list. The list will be populated if one or more proxy users is available. To filter the list, you can enter text in the Audit Source, Proxy, or Client Host field and click Go. Select proxy users from the list, and click Select to return to the Create Statement Audit page.
Statement Execution Condition	Choose WHENEVER SUCCESSFUL, WHENEVER NOT SUCCESSFUL, or BOTH as the execution condition to be audited.
DML Audit Granularity	Choose the level of granularity. You can audit BY ACCESS or BY SESSION.

Click OK to define this policy in Oracle Audit Vault or Cancel to return to the Statement Page without saving the policy.

2.1.4 Creating an Object Auditing Policy

Object Auditing is the auditing of specific statements on a particular schema object, such as AUDIT SELECT ON 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, schema object auditing can audit all SELECT and DML statements permitted by schema 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 provides the ability to audit the usage of powerful database commands that allow 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.

Schema object audit options are always set for all users of the database. These options cannot be set for a specific list of users.

2.1.4.1 Object Page

You use the Object page, shown in Figure 2-3, to define an object auditing policy.

Figure 2-3 Object Page

Description of "Figure 2-3 Object Page"

If object audit settings have been created for a source, the page displays a list of existing settings. The list contains the fields shown in Table 2-5.

Table 2-5 Object Fields

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. The granularity needed is different from the granularity in use.
Statement	The statement to be 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 has been provisioned and downward if it has not been provisioned.
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 will point up after provisioning. If a policy that is in use is set to not needed, the row will vanish after provisioning.
(Right-most column)	Click the trash can icon to remove the policy.

Click Create to go to the Create Object Audit Page and create an object audit setting.

2.1.4.2 Create Object Audit Page

To create an audited object setting, provide data for the fields on the page. The fields are shown in Table 2-6.

Table 2-6 Create Object Fields

Field	Description
Statements	The statements to be audited. Click the flashlight icon to use the Statements Audit Options page to select statements from a list. To filter the list, you can enter text in the Statements field and click Go. Select statements from the list, and click Select to return to the Create Object Audit page.
Object	The object that this setting applies to. Click the flashlight icon to use the Search And Select: Object page to select objects from a list. To filter the list, you can enter text in the Audit Source, Object Type, Object Owner, or Object field and click Go. Select objects from the list, and click Select to return to the Create Object Audit page.
Statement Execution Condition	Choose WHENEVER SUCCESSFUL, WHENEVER NOT SUCCESSFUL, or BOTH as the execution condition to be audited.
DML Audit Granularity	Choose the level of granularity. You can audit BY ACCESS or BY SESSION.

Select Everyone, User, or Proxy to indicate which users are to be audited.

Click OK to define this policy in Oracle Audit Vault or Cancel to return to the Object Page without saving the policy.

2.1.5 Defining a Privilege Auditing Policy

Privilege Auditing is the auditing of 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.

For example, when AUDIT SELECT ANY TABLE is in force, all statements issued by users with the SELECT ANY TABLE privilege are audited. This auditing capability is very important for the Sarbanes-Oxley (SOX) compliance requirements. Sarbanes-Oxley and other compliance regulations that specifically 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 similar statement and privilege audit options are both set, 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 because each privilege auditing option audits only specific types of statements, not a related list of statements. It is more focused than statement auditing because it audits only the use of the target privilege. You can set privilege auditing to audit a selected user or every user in the database.

2.1.5.1 Privilege Page

You use the Privilege page to define a privilege auditing setting. The Privilege page is shown in Figure 2-4.

Figure 2-4 Privilege Page

Description of "Figure 2-4 Privilege Page"

If privilege audit settings have been created for this source, the page displays a list of existing settings. The list contains the fields shown in Table 2-7.

Table 2-7 Privilege Fields

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. The granularity needed is different from the granularity in use.
Privilege	The privilege to be audited
User	The user that this setting applies to
Proxy User	The proxy user for the database, if any
Execution Condition	Choose WHENEVER SUCCESSFUL, WHENEVER NOT SUCCESSFUL, or BOTH as the execution condition to be audited.
Audit Granularity	Choose the level of granularity. You can audit BY ACCESS or BY SESSION.
In Use	The arrow points upward if the setting has been provisioned and downward if it has not been provisioned.
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 will point up after provisioning. If a policy that is in use is set to not needed, the row will vanish after provisioning.
(Right-most column)	Click the trash can icon to remove the policy.

Click Create to go to the Create Privilege Audit Page and create an audited privilege setting.

2.1.5.2 Create Privilege Audit Page

To create an audited privilege setting, provide data for the fields on the page. The fields are shown in Table 2-8.

Table 2-8 Create Privilege Fields

Field	Description
Privilege	The privilege to be audited. Click the flashlight icon to use the Privileges Audit Options page to select statements from a list. To filter the list, you can enter text in the Privileges field and click Go. Select statements from the list, and click Select to return to the Create Privilege Audit page.
Audited By	Select the appropriate option to indicate the users to be audited: All, User, or Proxy.
Users	The user that this setting applies to. You must set at least one user in this field or in the proxy user field. Click the flashlight icon to use the Search And Select: User page to select users from a list. To filter the list, you can enter text in the Audit Source or User field and click Go. Select users from the list, and click Select to return to the Create Privilege Audit page.
Proxy User	The proxy user for the database. You must set at least one user in this field or in the User field. Click the flashlight icon to use the Search And Select: Proxy User and Client page to select proxy users from a list. The list will be populated if one or more proxy users is available. To filter the list, you can enter text in the Audit Source, Proxy, or Client Host field and click Go. Select proxy users from the list, and click Select to return to the Create Privilege Audit page.
Statement Execution Condition	Choose WHENEVER SUCCESSFUL, WHENEVER NOT SUCCESSFUL, or BOTH as the execution condition to be audited.
DML Audit Granularity	Choose the level of granularity. You can audit BY ACCESS or BY SESSION.

Select Everyone, User, or Proxy to indicate which users are to be audited.

Click OK to define this policy in Oracle Audit Vault or Cancel to return to the Privilege Page without saving the policy.

2.1.6 Creating a Fine-Grained Auditing (FGA) Policy

Fine-grained auditing (FGA) enables you to create policies that define specific conditions that must take place for the audit to occur. Fine-grained auditing enables you to monitor data access based on content. It provides granular auditing of queries, as well as insert, update, and delete operations. For example, a central tax authority needs 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 SELECT privilege was used by a specific user on a particular table. Fine-grained auditing provides this deeper functionality.

In general, FGA policy is based on simple user-defined SQL predicates on table objects as conditions for selective auditing. During fetching, whenever policy conditions are met for a returning row, the query is audited. For example, you can use fine-grained auditing to audit the following types of actions:

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

• An IP address from outside the corporate network is used

• A table column is selected or updated

• A value in a table column is used

FGA enables organizations to define audit policies, which specify the data access conditions that trigger the audit event, and to use an alert to notify administrators that the triggering event has occurred. Time and identity of the user accessing the data, information revealed, and modifications made are captured, creating meaningful audit trails supporting compliance requirements.

Oracle Database captures the exact SQL text of the statement that the user executed in audit tables. You can use FGA in conjunction with other database features such as Oracle Flashback Query to re-create the exact records returned to a user. This may be especially important to organizations that share sensitive information for which they require strict accountability. For example, many government law enforcement organizations at the international, federal, state and local levels share information among themselves. It is important that they audit access to sensitive information, such as informant and intelligence data, to know who accessed what exact data. For more information about fine-grained auditing, please see Oracle Database Advanced Security Administrator's Guide.

FGA can serve as an early warning system of users misusing data access privileges, as well as an intrusion detection system for the database itself. FGA enables you to monitor data access based on content. A built-in audit mechanism in the database prevents users from bypassing the audit.

FGA allows audit policies to be associated with application tables. The policy determines when to generate an audit record. You can fine-tune the audit behavior by targeting a specific column, referred to as a relevant column, to be audited if a condition is met. The relevant-column capability enables you to focus on particularly important types of data to audit. For example, an audit record might be generated only when someone attempts to access sensitive account information after midnight, or attempts to access the investment account of a customer within a database at a financial investment firm or bank.

Other examples of relevant columns include privacy-related columns, such as those containing social security numbers, salaries, patient diagnoses, and so on. You could combine the fine-grained audit records to identify queries that address both name and social security number, a potential violation of privacy security laws. This combination of audit records could be useful in the retail industry.

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. For example, an organization might want to audit executive salary access when only an employee name is accessed, because accessing salary information alone is not meaningful unless an HR clerk also selects the corresponding employee name.

If no relevant column is specified, then auditing applies to all columns, that is, auditing occurs whenever any specified statement type affects any column, independent of whether any rows are returned or not. For example, a large insurance company might allow HR clerks to access employee salary information, but audit access when salaries greater than $500K are accessed. The audit policy ("where SALARY > 500000") is applied to the EMPLOYEES table through an audit policy interface (a PL/SQL package). Oracle Database 10g Release 2 extends 10g support for fine-gained auditing to INSERT, UPDATE and DELETE statements.

FGA can be used to reduce the amount of audit information generated and restrict auditing to especially sensitive information. It provides granular auditing of queries, as well as insert, update, and delete operations. For example, a health care organization or hospital must track access to patient records to guard against employee snooping or viewing high-profile patients, with enough detail to determine what data was accessed. It is not enough to know that SELECT privilege was used by a specific user on a particular table. Fine-grained auditing provides this deeper functionality. The Health Insurance Portability and Accountability Act (HIPAA) requires health care organizations to audit user activity relating to patient data.

The extensibility framework in FGA enables administrators optionally to define an appropriate audit event handler to process the event, for example, by sending e-mail to the administrator. The event handler provides organizations with flexibility in determining how to handle a triggering audit event. A triggering audit event could be written into a special audit table for further analysis, or could activate a pager for the security administrator. The event handler enables organizations to fine-tune their audit response to appropriate levels of escalation.

For additional flexibility in implementation, organizations 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 intranet, but audit access to executive-level salaries when they are accessed from the Internet.

2.1.6.1 FGA Page

You use the FGA page, shown in Figure 2-5, to define fine-grained audit settings.

Figure 2-5 Fine-Grained Auditing Page

Description of "Figure 2-5 Fine-Grained Auditing Page"

If fine-grained audit settings have been created for a source, the page displays a list of existing settings. The list contains the fields shown in Table 2-9.

Table 2-9 Fine-Grained Audit Fields

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. The granularity needed is different from the granularity in use.
Policy Name	The name of this fine-grained audit policy
Schema	The schema to which this policy applies
Object	The object to which this setting applies
Statement	The statement to which this setting applies
Columns	The database columns being audited. If this field is empty, all columns are audited.
In Use	The arrow points upward if the setting has been provisioned and downward if it has not been provisioned.
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 will point up after provisioning. If a policy that is in use is set to not needed, the row will vanish after provisioning.
(Right-most column)	Click the trash can icon to remove the policy.

To view a fine-grained audit policy, click its name in the Policy Name column to go to the Fine-Grained Audit Detail Page.

Click Create to go to the Create FGA Page and create an FGA setting.

Note:

If you set up a fine-grained auditing policy, ensure that a database and collector are running against the source. Otherwise, you will not get audit records corresponding with this policy in Oracle Audit Vault.

2.1.6.2 Create FGA Page

To create a fine-grained audit setting, provide data for the fields on the page. The fields are listed in Table 2-10.

Table 2-10 Create Fine-Grained Audit Fields

Field	Description
FGA Policy Name	Enter a name for this fine-grained audit policy.
Object	The object that this policy applies to. Click the flashlight icon to use the Search And Select: Object page to select objects from a list. To filter the list, you can enter text in the Audit Source, Object Type, Object Owner, or Object field and click Go. Select objects from the list, and click Select to return to the Create FGA page.
Statements	The type of statement that this policy applies to. Click the flashlight icon to use the Statement Type page to select statement types from the list. Click Select to return to the Create FGA page.
Columns	Enter the database columns to audit. If you enter more than one column, select All or Any as the condition that triggers this policy.
Condition	Enter the Boolean condition to be audited, for example: < 1000 If this field is blank or Null, auditing occurs regardless of condition.
Handler	The name of the event handler. For more information about fine-grained auditing handlers, see Oracle Database Security Guide.

Click OK to define this policy in Oracle Audit Vault or Cancel to return to the FGA Page without saving the policy. When you click OK, a View FGA Policy page is displayed. Click Return to return to the FGA Page.

2.1.6.3 Fine-Grained Audit Detail Page

The Fine-Grained Audit Detail page lists the fields shown in Table 2-11.

Table 2-11 Fine-Grained Audit Detail Fields

Field	Description
FGA Policy Name	The name for this fine-grained audit policy
Schema	The schema to which this policy applies
Object	The object to which this policy applies
Statements	The type of statements to which this policy applies
Columns	Whether all table columns are to be audited or the specified table columns are to be audited
Condition	The Boolean condition to be audited, for example, <1000. If Null, auditing occurs regardless of condition.
Handler Schema	The schema in which the handler event is stored
Handler package	The package containing the handler, for example: DBMS_FGA
Handler	The name of the event handler. For more information about fine-grained auditing handlers, see Oracle Database Security Guide.

Click Cancel to return to the FGA Page.

2.1.7 Creating a Capture Rule

Capture rules are used for Streams-based auditing. For information about Oracle Streams, see Oracle Streams Concepts and Administration.

2.1.7.1 Capture Rule Page

You use the Capture Rule page, shown in Figure 2-6, to define capture rule settings.

Figure 2-6 Capture Rule Page

Description of "Figure 2-6 Capture Rule Page"

If capture rule audit settings have been created for a source, the page displays a list of existing settings. The list contains the fields shown in Table 2-12.

Table 2-12 Capture Rule Fields

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. The granularity needed is different from the granularity in use.
Rule Type	The types are Global, Schema, or Table. Global capture rules are systemwide. Schema capture rules apply only to access of specific schema, and Table rules apply to access of specific tables in the schema.
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 DDL statements are audited.
DML	YES or NO indicates whether DML statements are audited.
In Use	The arrow points upward if the setting has been provisioned and downward if it has not been provisioned.
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 will point up after provisioning. If a policy that is in use is set to not needed, the row will vanish after provisioning.
(Right-most column)	Click the trash can icon to remove the policy.

Click Create to go to the Create Capture Rule Page and create a capture rule audit setting.

Note:

A REDO collector must be defined against this source. Otherwise, attempts to provision a capture rule will fail.

2.1.7.2 Create Capture Rule Page

To create a capture rule audit setting, provide data for the fields on the page. The fields are shown in Table 2-13.

Table 2-13 Create Capture Rule Fields

Field	Description
Capture Rule Type	Select Global, Schema, or Table. Global capture rules are systemwide. Schema capture rules apply only to access of specific schema, and Table rules apply to access of specific tables in the schema.
Schema	For Schema rules, specify a schema name or click the flashlight icon to search for and select a schema name.
Table	For Table rules, specify a table name or click the flashlight icon to search for and select a table name.
Capture	Select DDL, DML, or Both.

Click OK to define this policy in Oracle Audit Vault or Cancel to return to the Capture Rule Page without saving the policy.

2.2 Configuring Alerts

Oracle Audit Vault has the capability to raise alerts when the incoming audit data violates specific audit policies. The Oracle Audit Vault auditor can specify the conditions under which to raise these alerts on the Alerts page of the Audit Policy tab. When an incoming audit record meets the condition specified, an alert is raised and placed in the alert store, where the auditor can review it. The Oracle Audit Vault Dashboard is also updated to reflect the alert data. Also, the alert is placed in an output queue within the Audit Vault database. The Audit Vault administrator can install software that can read this queue and process the alert appropriately. Appropriate actions might include sending a page to a security officer or filing a trouble ticket within the appropriate tracking system.

It is important to understand that alerts are raised when the audit data reaches the 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. This frequency can be configured by the Audit Vault administrator.

To view or define alerts, you use the Audit Alerts Page, shown in Figure 2-7. To reach the Audit Alerts page from the dashboard, click the Audit Policy tab, then click Alerts on the upper left.

Figure 2-7 Audit Alerts Page

Description of "Figure 2-7 Audit Alerts Page"

2.2.1 Creating an Alert

To add an alert, click Create on the Audit Alerts Page. This takes you to the Create Alert Rule Page. You define an audit rule by entering information on the Create Alert Rule Page.

2.2.2 Audit Alerts Page

On the Audit Alerts page, you can:

• Specify or select filter criteria to show the audit alerts associated with a particular audit source type, audit source, or audit event category, or any combination of these three filter criteria.

• Click an alert name in the Alert Name column to view alert information for that alert.

You can specify the following filter criteria:

• Audit Source Type – Enter Audit Source Type criteria or click the flashlight icon for the Audit Source Type field. An audit source type defines the collection behavior of the audit sources classified for an audit source type.

  At the Search and Select: Audit Source Type page, you can filter the list or search for a specific item by entering text in the text field for the Audit Source field, then click Go to see the items that are returned. Next, you can select one or more of the returned items by clicking individual check boxes for each item listed, or click Select All to select all items. You can also click Select None to deselect all selected items and begin again. After making your selections, click Select to populate the Audit Source Type field with your selected filter criteria, and return to the Audit Alerts page.

• Audit Source – Enter Audit Source criteria or click the flashlight icon for the Audit Source field. An audit source is where events are created.

  At the Search and Select: Audit Source page, you can filter the list or search for a specific item by entering text in the text field for the Audit Source field, Audit Source Host field, and the Audit Source Host IP field, then click Go to see the items that are returned. Next, you can select one or more of the returned items by clicking individual check boxes for each item listed, or click Select All to select all items. You can also click Select None to deselect all selected items and begin again. After making your selections, click Select to populate the Audit Source field with your selected filter criteria, and return to the Audit Alerts page.

• Audit Event Category – Enter Audit Event Category criteria or click the flashlight icon for the Audit Event Category field.

  At the Search and Select: Audit Event Category page, you can filter the list or search for a specific item by entering text in the text field for the Audit Event Category field, then click Go to see the items that are returned. Next, you can select one or more of the returned items by clicking individual check boxes for each item listed, or click Select All to select all items. You can also click Select None to deselect all selected items and begin again. After making your selections, click Select to populate the Audit Event Category field with your selected filter criteria, and return to the Audit Alerts page.

When you are satisfied with the selections in the Audit Source Type, Audit Source, or Audit Event Category field, click Go.

The Alerts report contains the column headings shown in Table 2-14.

Table 2-14 Audit Alerts Fields

Field	Description
Alert Name	The name of the alert
Audit Source Type	The audit source type to which this alert applies
Audit Source	The audit source to which this alert is restricted
Audit Event Category	The audit category to which this alert is restricted
Status	When you create an alert, it is Active. If you remove it, it remains in the Audit Vault database, but is Inactive.
Remove	To make an Active alert Inactive, click the trash can icon in the row corresponding to that alert.

Click an alert name in the Name column to view the Alerts Page, which contains alert information about that alert.

Click Create to go to the Create Alert Rule Page to create an alert rule.

Click Next n to view the next group of listed alerts returned or click Previous to view the previous group of listed alerts.

2.2.3 Alerts Page

The Alerts page contains the fields shown in Table 2-15.

Table 2-15 Alerts Page Fields

Field	Description
Alert Name	The name of the alert
Description	A brief description of the alert
Audit Source	The audit source to which this alert is restricted
Audit Source Type	The audit source type to which this alert applies
Audit Event Category	The audit category to which this alert is restricted
Audit Severity	The severity level of the alert: CRITICAL or WARNING.
Condition	The condition when this alert rule should be evaluated. The alert condition must evaluate to a Boolean value and be based on either the event category format of the audit record or the source-type-specific event category format to which the audit record belongs.
Status	Whether the alert is ACTIVE or INACTIVE

Click Return to return to the Audit Alerts Page.

2.2.4 Create Alert Rule Page

Use this page to add an alert that is to be raised when audit data violates specific audit policies.

Follow these steps to add an alert:

1. Enter the alert name and a brief description of the alert.

2. Specify the level of severity, source type, source, and event category for the alert.

3. Select Basic or Advanced to specify additional alert conditions in the Basic Alert Condition or Advanced Alert Condition sections and enter the additional alert conditions.

4. Click OK to save and add the alert to Oracle Audit Vault and return to the Audit Alerts page.

To begin to create an alert, enter or select information for the fields shown in Table 2-16.

Table 2-16 Create Alert Rule Fields

Field	Description
Alert	Enter a name for the alert.
Description	Enter a brief description for the alert.
Alert Severity	Select a severity level for the alert: Critical or Warning.
Audit Source Type	Select an audit source type from the list.
Audit Source	Select an audit source name from the list. If audit source information is specified, then audit source type information is not needed. However, when audit source information is specified, it is filtered by audit source type information if this information is specified.
Audit Event Category	Select the name of an audit event category from the list.

If both audit source and audit source type information are specified and they do not match, an error is raised and an error message is returned.

If audit source information is specified, the user and table fields are enabled and filtered by the audit source information.

The following combinations of audit source type and audit event category information are supported:

• If information for neither is specified

• If information for both is specified

• If only information for source type is specified

If audit event category information is specified, but audit source information is not specified, an error is raised and an error message is returned.

If information for the audit source type and audit event category are specified, then information for the audit event is enabled and filtered by both these fields.

2.2.4.1 Basic Alert Condition

Specify or select fields that describe when an alert should be raised. Alerts can be created on each field and certain combinations of fields. Specifying information for certain fields causes the information to be filtered as described in this section. Enter or select information for the fields shown in Table 2-17.

Table 2-17 Basic Alert Condition Fields

Field	Description
User	Specify the name of a user or click the flashlight icon to search for and select a user name.
Table	Specify the name of a table or click the flashlight icon to search for and select a table name.
Audit Event	Select the name of an audit event from the list.
Audit Event Status	Select an option to represent whether the event has a status of Success, Failure, or Both.

2.2.4.2 Advanced Alert Condition

In the Advanced Alert Condition section, shown in Figure 2-8, you can construct the Boolean condition for when this alert should be evaluated. When audit data violates the Boolean condition, it evaluates to a Boolean value that when true, triggers the alert to be raised and sent to an alert store and placed in an output queue.

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

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

Enter a valid Boolean condition in the Condition field under which an alert should be raised. Construct the condition by choosing audit events and event attributes by double-clicking the specific audit event or event attribute desired. Complete the Boolean condition using valid expression syntax and valid values for the event attribute's data type.

Condition is the Boolean condition when this alert rule should be evaluated. The alert condition must evaluate to a Boolean value and be based on either the event category format of the audit record or the source-type-specific event category format to which the audit record belongs.

You can select audit events and event attributes from the menus at the bottom of the page to insert them into the condition field. When you select an audit event it is represented in the condition field by its Oracle Database source event ID. For example, for the account management event category, the audit event named CREATE USER is represented as SOURCE_EVENTID='51'. When you select an event attribute, the event attribute name appears in the Condition field.

You specify the alert condition as an expression containing audit events and event attributes from the incoming audit records. Which audit events and event attributes you can use in a condition depends on how you specify the record. All audit records contain a minimal set of event attributes that you can use. In addition, each type of auditable event adds event attributes specific to itself. The complete list of event attributes available to you is in Appendix B, Section B.1. To use these additional event attributes, however, you must explicitly specify the type of auditable event in the Audit Event Category field.

For a failed logon event, for example, you would specify:

SOURCE_EVENTID = '100' AND EVENT_STATUS != 0

Oracle Databases use a numeric code to denote these events by their source event ID. You can restrict the alert to a specific type of event by using this field in your conditions. The complete list of Oracle Database events and source event IDs is in Appendix B, Section B.2.

The other event attribute used in the preceding example is EVENT_STATUS. 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.

Click OK to create the alert rule and return to the Alerts Page.