6 Configuring Secured Targets, Audit Trails, and Enforcement Points

Topics

6.1 About Configuring Secured Targets

Secured targets can be supported databases or operating systems that Audit Vault and Database Firewall monitors. You must register all secured targets in the Audit Vault Server, regardless of whether you are deploying the Audit Vault Agent, the Database Firewall, or both.

If you want to collect audit trails from your secured targets, you must configure an audit trail for each target and start collection manually.

If you want to monitor a secured target with the Database Firewall, you must create an enforcement point for that secured target.

For some database secured targets that you monitor with the Database Firewall, you can configure Oracle Audit Vault and Database Firewall to interrogate the database to collect certain data. To do so, you must run scripts on the secured target computers to configure the necessary privileges for database interrogation.

If you are using the Database Firewall, you can also monitor the secured target database's responses to incoming SQL traffic. The following sections contain the high-level workflow for configuring the Oracle Audit Vault and Database Firewall system.

See Also:

6.2 Registering Secured Targets and Creating Groups

Topics

6.2.1 Registering or Removing Secured Targets in the Audit Vault Server

Topics

6.2.1.1 About Secured Targets in the Audit Vault Server

An Oracle AVDF super administrator can create secured targets and grant access to them to other administrators. An Oracle AVDF administrator can also create secured targets, but they are only accessible to that administrator and the super administrator.

Important: In the following procedure, if you specify service names and/or SIDs, then the Database Firewall only captures traffic to the service names and/or SIDs listed. In this case, if a database client connects using a different service name or SID than those listed, the Database Firewall does not monitor that traffic. As a best practice to avoid this problem, follow these guidelines:

  • Define the configuration and policies that use Oracle service names for each and every service that runs on a protected Oracle secured target. This ensures that the configuration enables each policy to be applied to the correct Oracle service name.

  • Always define a catch-all secured target (and associated enforcement point) to process the database traffic that does not match the Oracle service names that were explicitly configured in the previous secured targets. This new secured target should have the same IP address and TCP port number, but the Oracle service name should be left blank, and should have a "log-all" policy applied. This way, any traffic that the secured targets with explicitly defined Oracle service names do not capture is logged and can be examined. Based on your findings, you then can tighten the configuration and policies so all traffic that reaches an Oracle service name is captured in an explicit fashion.

In Oracle Database 12c, if you are not using a multitenant container database (CDB), then register a secured target for your database as you would for previous versions of Oracle Database. If you use a CDB, then you must register a secured target for the CDB, as well as each pluggable database (PDB).

6.2.1.2 Registering Secured Targets

To register a secured target in the Audit Vault Server:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab.

    The Secured Targets page lists the configured secured targets to which you have access. You can sort or filter the list of targets.

  3. Click Register to register a new target.
  4. In the Register Secured Target page, enter a New Secured Target Name and optional Description for the new target.
  5. In the Secured Target Type field, select the secured target type. For example, Oracle Database.
  6. Optionally enter the Secured Target Location (For Auditing) settings. This is required for the agent to collect audit data, but not required to deploy Database Firewall only.

    Description of GUID-5CEF8C59-4129-4741-B97B-057BE2C51017-default.gif follows
    Description of the illustration GUID-5CEF8C59-4129-4741-B97B-057BE2C51017-default.gif

    In the Secured Target Location (For Auditing) section, choose the Basic option. Enter the Host Name or IP Address, Port, and for Oracle Databases, the Service Name (or SID).

    If you know the exact connect string, you can click the Advanced radio button instead, and enter the string there.

    For example, for Oracle Database, the string might look like the following:

    jdbc:oracle:thin:@//203.0.113.0:1521/hrdb

    When you configure an Oracle RAC secured target for agent data collection, enter the SCAN host name. Oracle RAC secure target can be configured with Oracle Database Firewall for protection.

  7. If required by the secured target type, enter the User Name and Password fields. These are the credentials for the secured target user account you created for Oracle Audit Vault and Database Firewall.
  8. If you will monitor this secured target with a Database Firewall, in the Add Secured Target Addresses (For Firewall) area, for each available connection of this database enter the following information, and then click Add.

    • Host Name / IP Address

    • Port Number

    • Service Name (Optional, for Oracle Database only)

      You can also use an SID in this field. To enter multiple service names and/or SIDs, enter a new line here for each of them, and then click Add.

      If you want to enforce different Database Firewall policies for different service names or SIDs on the same database, then you must create a separate secured target for each service name or SID.

    Note:

    • In case the secured target is Oracle Real Application Cluster (RAC) , the IP (or hostname) is the SCAN name of cluster node. The PORT is the port on which the remote listener is running. See How to Configure an Oracle Grid Infrastructure SCAN Listener for detailed steps to configure SCAN name for Oracle RAC environment.

    • In case the secured target is Microsoft SQL Server Cluster, a mandatory collection attribute needs to be set. See section Microsoft SQL Server for complete information.

  9. If required, enter values for Attribute Name and Attribute Value in the Collection Attributes section. Click Add.

    Collection attributes may be required by the Audit Vault Agent depending on the secured target type.

  10. If you will monitor this secured target with a Database Firewall, you can increase the processing resource for this secured target by adding the following Collection Attribute:

    Attribute Name: MAXIMUM_ENFORCEMENT_POINT_THREADS

    Attribute Value: A number between 1 - 16 (default is 1)

    This defines the maximum number of Database Firewall processes (1 - 16) that may be used for the enforcement point associated with this secured target. You should consider defining this if the number of secured targets you are monitoring is less than the number of processing cores available on the system running the Database Firewall. Setting a value when it is not appropriate wastes resources.

  11. Click Save.

    Note:

    TCPS must be configured for registering Hybrid Cloud Oracle Databases. See Securing the Agent and Oracle Database Secure Target Connection.

    See Also:

6.2.1.3 Modifying Secured Targets

To modify a secured target:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab.

    The Secured Targets page lists the configured secured targets to which you have access. You can sort or filter the list of targets.

  3. Select the name of the secured target you want to modify.
  4. In the Modify Secured Target page, make your changes, and then click Save.

Note:

If you change the name of a secured target, the new name does not appear in Oracle Audit Vault and Database Firewall reports until you restart the Audit Vault Agent.

See Also:

6.2.1.4 Removing Secured Targets

If you no longer need to have a secured target registered with Oracle AVDF, you can use either the console or the command-line utility to remove the secured target. After you have removed the secured target from Oracle AVDF, its audit data still resides in the data warehouse within its retention period (archiving policy).

After you have removed a secured target, its identity data remains in Oracle AVDF so that there will be a record of secured targets that have been dropped. Remove the secured target only if you no longer want to collect its data or if it has moved to a new host computer.

To remove a secured target:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab, and then select the secured target(s) you want to remove.
  3. Click Delete.

    See Also:

6.2.2 Creating or Modifying Secured Target Groups

As a super administrator you can create secured target groups in order to grant other administrators access to secured targets as a group rather than individually.

To create a secured target group:

  1. Log into the Oracle Audit Vault and Database Firewall console as a super administrator, and click the Secured Targets tab.

  2. Click the Groups menu on the left.

    Preconfigured groups are listed in the top pane, and user defined groups are listed in the bottom pane.

    You can adjust the appearance of the list in the bottom pane from the Actions menu.

  3. Click Create, and enter a name and optional description for the group.

  4. To add secured targets to the group, select the secured targets, and click Add Members.

  5. Click Save.

    The new group appears in the bottom pane of the groups page.

To modify a secured target group:

  1. Log into the Oracle Audit Vault and Database Firewall console as a super administrator, and click the Secured Targets tab.

  2. Click the Groups menu on the left.

    Preconfigured groups are listed in the top pane, and user defined groups are listed in the bottom pane.

    You can adjust the appearance of the list in the bottom pane from the Actions menu.

  3. Click the group name.

  4. In the Modify Secured Target page, select secured targets you want to add or remove, and then click Add Members or Drop Members.

  5. Optionally, you can change the name or description of the group.

  6. Click Save.

See Also:

Working with Lists of Objects in the UI to adjust the appearance of the list in the bottom pane from the Actions menu.

6.2.3 Controlling Access to Secured Targets and Target Groups

Oracle Audit Vault and Database Firewall super administrators can control which administrators have access to secured targets or secured target groups. You can control access for an individual user, or for an individual secured target or group.

See Also:

Managing User Access Rights to Secured Targets or Groups

6.3 Preparing Secured Targets for Audit Data Collection

Topics

6.3.1 Using an NTP Service to set Time on Secured Targets

It is recommended that you also use an NTP service on both your secured targets and the Audit Vault Server. This will help to avoid confusion on timestamps on the alerts raised by the Audit Vault Server.

See Also:

Specifying the Server Date, Time, and Keyboard Settings for instructions on using an NTP server to set time for the Audit Vault Server.

6.3.2 Ensuring that Auditing is Enabled on the Secured Target

In order to collect audit data from a secured target, you must ensure that auditing is enabled on that secured target, and where applicable, note the type of auditing that the secured target is using. Check the product documentation for your secured target type for details.

To check if auditing is enabled on an Oracle Database secured target:

  1. Log in to the Oracle database as a user with administrative privileges. For example: 
    sqlplus trbokuksa
Enter password: password
Connected.
  2. Run the following command: 
    SHOW PARAMETER AUDIT_TRAIL

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
audit_trail                          string      DB
  3. If the output of the SHOW PARAMETER command is NONE or if it is an auditing value that you want to change, then you can change the setting as follows.

    For example, if you want to change to XML, and if you are using a server parameter file, you would enter the following:

    CONNECT SYS/AS SYSDBA
Enter password: password

ALTER SYSTEM SET AUDIT_TRAIL=XML SCOPE=SPFILE;
System altered.

SHUTDOWN
Database closed.
Database dismounted.
ORACLE instance shut down.

STARTUP
ORACLE instance started.
  4. Make a note of the audit trail setting.

    You will need this information when you configure the audit trail in Oracle Audit Vault and Database Firewall.

6.3.3 Setting User Account Privileges on Secured Targets

Some secured target types require credentials in order for Oracle Audit Vault and Database Firewall to access them. If you plan to collect audit data from a secured target, do stored procedure auditing (SPA), entitlements auditing, or enable database interrogation, you must create a user account on the secured target with the appropriate privileges to allow Oracle Audit Vault and Database Firewall to access the required data.

Setup scripts for database secured targets: Oracle Audit Vault and Database Firewall provides scripts to configure user account privileges for database secured target types.

Non-database secured targets: You must create a user that has the appropriate privileges to access the audit trail required. For example, for a Windows secured target, this user must have administrative permissions in order to read the security log.

Note:

Oracle Audit Vault and Database Firewall does not accept user names with quotation marks. For example, "JSmith" would not be a valid user name for an Audit Vault and Database Firewall user account on secured targets.

See Also:

Scripts for Oracle AVDF Account Privileges on Secured Targets for information on scripts to configure user account privileges for database secured target types.

6.3.4 Scheduling Audit Trail Cleanup

Learn about scheduling audit trail cleanup.

Oracle Audit Vault and Database Firewall supports audit trail cleanup for Oracle Database, Microsoft SQL Server, and MySQL.

See Also:

Audit Trail Cleanup

6.4 Configuring and Managing Audit Trail Collection

Learn about configuring and managing audit trail collection.

6.4.1 Adding an Audit Trail in the Audit Vault Server

In order to start collecting audit data, you must configure an audit trail for each secured target in the Audit Vault Server, and then start the audit trail collection manually.

This procedure assumes that the Audit Vault Agent is installed on the same host computer as the secured target.

Prerequisites

Before configuring an audit trail for any secured target, you must:

To configure an audit trail for a secured target:

  1. Click the Secured Targets tab.

  2. Under Monitoring, click Audit Trails.

    The Audit Trails page appears, listing the configured audit trails and their status.

  3. In the Audit Trails page, click Add.

  4. From the Audit Trail Type drop-down list, select one of the following:

    • CUSTOM

    • DIRECTORY

    • EVENT LOG

    • NETWORK

    • SYSLOG

      This trail type can collect from either syslog or rsyslog files. If both are present, you must give the exact Trail Location (in step 7) if you want to collect audit data from rsyslog files. See Table B-23 for details.

      Important: Be sure that records generated by rsyslog have the same timezone information as the Audit Vault Agent running on the Collection Host.

    • TABLE

    • TRANSACTION LOG

      For this audit trail type, ensure that the secured target database has a fully qualified database name. See the GLOBAL_NAMES setting in Table C-1.

    See Table B-17 for details on which type(s) of audit trails can be collected for a specific secured target type.

  5. In the Collection Host field, click the up-arrow icon to display a search box, and then find and select the host computer where the Audit Vault Agent is deployed.

  6. In the Secured Target field, click the up-arrow icon to display a search box, and then find and select the secured target.

  7. In the Trail Location field, enter the location of the audit trail on the secured target computer, for example, sys.aud$.

    The trail location depends on the type of secured target.

    Note 1: If you selected DIRECTORY for Audit Trail Type, the Trail Location must be a directory mask.

    Note 2: If you selected SYSLOG for Audit Trail Type, and both syslog and rsyslog file types are present, enter the exact directory location of either the syslog or rsyslog files. See Table B-23 for important details.

  8. If you have deployed plug-ins for this type of secured target, select the plug-in from the Collection Plug-in drop-down list.

  9. Click Save.

    The audit trail is added to the list on the Audit Trails page. The collection status displays a red down-arrow (stopped) initially. The audit trail starts automatically shortly after it is added.

See Also:

6.4.2 Stopping, Starting, and Autostart of Audit Trails in the Audit Vault Server

An audit trail starts automatically shortly after you add it. In order to start an audit trail, the Audit Vault Agent must be running on a host computer.

Audit trails that are started will automatically restart if the Audit Vault Agent is restarted, or updated due to an Audit Vault Server update.

An audit trail can go down at times such as when the secured target goes down temporarily. With Autostart, the system automatically attempts to restart an audit trail if it goes down. Autostart is normally enabled unless you have manually stopped the trail. You can set parameters on when and how many times the system attempts Autostart using the AVCLI utility.

To start or stop audit trail collection for a secured target:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab.
  3. Click Audit Trails.
  4. Select the audit trail(s) you want to start or stop, and then click Stop or Start.

    You cannot start an audit trail while the Audit Vault Agent is updating.

    Note:

    If your environment has a large number of audit files to collect, for example 1 million or more, the audit trail may take a few minutes to start.

    See Also:

6.4.3 Checking the Status of Audit Trails in the Audit Vault Server

To check the status of audit trails:

  1. Log in to the Audit Vault Server console as an administrator.

  2. Click the Secured Targets tab.

  3. Click Audit Trails.

    The Audit Trails page lists audit trails and their status in the Collection Status column, along with other details. The status may be one of the following:

    • Idle - Trail is up and running, no new audit data to collect. In this state, the trail is waiting for the Secured Target to generate new audit data.

    • Starting - Collection process is starting.

    • Collecting - Trail is currently actively collecting audit data.

    • Stopping - Collection process is stopping.

    • Stopped - Trail is currently stopped.

    • Recovering - Trail has collected a batch of audit data and is setting a checkpoint on the Audit Vault Server. This can take a while depending on the server load.

    • Unreachable - A heartbeat timeout has occurred, indicating that a heartbeat message has not been received from the trail in the last two minutes. This status is temporary unless the trail has crashed.

    • Archive data files are required (link) - If you see this link, it means a new audit trail contains expired audit records that must be archived, and that the required archive data files are not available.

    The Trail Autostart Details column indicates whether Autostart is enabled for a trail, and whether there have been attempts to restart a failed audit trail (for example, if a secured target goes down temporarily).

Tip: You can sort and filter the audit trail list.

Note:

To view audit trails status for a specific agent host, you can click the Hosts tab, and in the Agent Details column for that host click View Audit Trails.

Note:

If an audit trail fails to start, you can get more information by showing the Error Message column:

  1. In the Audit Trails page, click the Actions button, then click Select Columns.

  2. Double-click Error Message on the left to move it to the Display in Report box, and then click Apply.

See Also:

6.4.4 Handling new Audit Trails with Expired Audit Records

With established audit trail collection, audit data is retained in the Audit Vault Server for the Months Online period of a retention (or archiving) policy. After this period, the data files are made available for archiving. The data is then kept in archives for the Months Archived period of the retention policy, and is available to retrieve to the Audit Vault Server during that period.

However, when you add a new audit trail to an existing secured target, the audit data collected may contain records that fall into the Months Archived period in the retention policy assigned to this secured target. That is, the online period for these audit records has expired and they should be archived according to the retention policy.

In this case, Oracle Audit Vault and Database Firewall attempts to automatically archive these expired records during the new audit trail collection. In some cases, you may need to make the archive data files available in order for the audit trail to complete collection.

When collecting a new audit trail for an existing secured target, follow these instruction if you see an Archive data files are required link in the Collection Status of the audit trail.

To make archive data files accessible:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab, and then click Audit Trails.
  3. In the Collection Status column, if applicable, click the Archive data files are required link.

    The required archive data files are listed.

  4. Check that required data files are available in the archive location, and that the connection to the location is set up correctly.
  5. After you make the required data files available, restart this audit trail.

See Also:

6.4.5 Deleting an Audit Trail

Follow these steps to delete an audit trail:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Make sure the audit trail is stopped.
  3. Click the Secured Targets tab.
  4. Click Audit Trails.
  5. Select the audit trail(s) you want to delete, and then click Delete.

6.4.6 Converting Audit Record Format For Collection

Audit records of some databases are in the format that cannot be read directly by Oracle Audit Vault and Database Firewall collectors. Such audit records are first converted to a readable format and then collected.

Running The XML Transformation Utility For MySQL Auditing

For MySQL secured targets, Oracle Audit Vault and Database Firewall provides a utility to transform the MySQL XML audit format log file into a required format for audit data collection. You must run this utility on the MySQL host machine before adding an audit trail.

Note:

This procedure is only applicable for the old audit format. The default audit format of MySQL 5.5 and 5.6 is old. The default audit format of MySQL 5.7 is new. The audit format can be changed by modifying the configuration on MySQL Server.

Prerequisites

To run the XML Transformation Utility:

  1. On the MySQL host computer, go to the directory AGENT_HOME/av/plugins/ com.oracle.av.plugin.mysql/bin/
  2. Run the following command: 
    MySQLTransformationUtility.bat inputPath=path_to_log_folder 
outputPath=path_to_converted_xml agentHome=path_to_AGENT_HOME 
interval=interval_in_minutes xslPath=XSL_file_path securedTargetName=registered_secured_target_name

    This command contains the following variables:

    • path_to_log_folder:

      • For MySQL version prior to 5.7.21: The path to the MySQL log folder listed in my.ini

      • For MySQL version 5.7.21 and later: The path to the MySQL log folder listed in my.ini\<audit file name>.*.log

    • path_to_converted_xml - The path to the folder where the converted XML files will reside. You will use this path as the Trail Location when creating the audit trail for this MySQL secured target in the Audit Vault Server, or when starting audit trail collection using the AVCLI command line.

    • path_to_AGENT_HOME - The path to the installation directory of the Audit Vault Agent

    • interval_in_minutes - (Optional) The waiting time, in minutes, between two transformation operations. If not specified, the default it is 60 minutes. To run the transformation utility once, specify -ve for this argument.

    • XSL_file_path - (Optional) The path to the XSL file to use for the transformation.

    • registered_secured_target_name - The name of the MySQL secured target registered in the Audit Vault Server.

    Example:

    For MySQL version prior to 5.7.21: MySQLTransformationUtility.bat inputPath=D:\MySQLLog outputPath=D:\ConvertedXML agentHome=E:\MySQLCollector interval=1 securedTargetName=MYSQL_DEV

    For MySQL version 5.7.21 and later: MySQLTransformationUtility.bat inputPath=D:\MySQLLog\audit.*.log outputPath=D:\ConvertedXML agentHome=E:\MySQLCollector interval=1 securedTargetName=MYSQL_DEV

6.4.6.1 Converting Binary Audit Files to ASCII Format

Converting Binary Audit Files to ASCII Format For IBM DB2 Auditing

IBM DB2 creates its audit log files in a binary file format that is separate from the DB2 database. For IBM DB2 secured targets, you must convert the binary file to an ASCII file before each time you collect audit data (start an audit trail) for a DB2 database, using the script instructions in this section.

Ideally, schedule the script to run periodically. If the script finds older text files that have already been collected by the DB2 audit trail, then the script deletes them. It creates a new, timestamped ASCII text file each time you run it. Optionally, you can set the script to purge the output audit files.

Note:

It is recommended that you extract audit log files for each database and each instance in a separate directory. You must configure separate audit trails for each database and each instance in Oracle AVDF.

To convert the binary DB2 Audit File to an ASCII file:

  1. Identify a user who has privileges to run the db2audit command.

    This user will extract the binary files to the text files.

  2. Grant the user you identified in Step 1 execute privileges to run the conversion script from the Oracle AVDF directory. The script name is:

    • DB2 release 8.2 databases: DB282ExtractionUtil (for Microsoft Windows, this file is called DB282ExtractionUtil.bat.)

    • DB2 9.5 release databases: DB295ExtractionUtil (for Microsoft Windows, this file is called DB295ExtractionUtil.bat.)

  3. Grant the user you identified in Step 1 read permission for the $AGENT_HOME/av/atc directory and its contents.
  4. In the server where you installed the IBM DB2 database, open a shell as the SYSADM DB2 user.
  5. Set the following variables:

    • AGENT_HOME (this is the Audit Vault Agent installation directory)

    • DB2AUDIT_HOME (this directory points to the main directory that contains the db2audit command)

  6. Ensure that the Oracle AVDF owner of the agent process has read permissions for the audit text files that will be generated by the extraction utility.
  7. Log in as the DB2 user that you identified in "IBM DB2 for LUW Setup Scripts".
  8. Run one of the following scripts, depending on the version of DB2 that you have installed:

    • For DB2 release 8.2 databases:

      DB282ExtractionUtil -extractionpath default_DB2_audit_directory -audittrailcleanup yes/no

      • default_DB2_audit_directory: Enter the full directory path to the location of the DB2 audit directory. Typically, this directory is in the following locations:

        UNIX: DB2_HOME/sqlib/security/auditdata

        Microsoft Windows: DB2HOME\instance\security\auditdata

      • yes/no: Enter yes or no, to enable or disable the audit trail cleanup. Entering yes deletes the IBM DB2 audit file up to the latest audit record which has been collected by the Oracle AVDF DB2 audit trail. If you omit this value, then the default is no.

      For example, to extract audit files and enable the audit trail cleanup:

      DB282ExtractionUtil -extractionpath /home/extract_dir -audittrailcleanup yes

      This script creates the ASCII text file in the auditdata directory, using the following format, which indicates the time the file was created:

      db2audit.instance.log.0.YYYYDDMMHHMMSS.out

    • For DB2 release 9.5 databases:

      DB295ExtractionUtil -archivepath archive_path -extractionpath extraction_path -audittrailcleanup yes/no -databasename database_name

      In this specification:

      • archive_path: This is DB2 archive path configured using the db2audit utility.

      • extraction_path: This is the directory where the DB2 extraction utility places the converted ASCII text file. This file is created in either the db2audit.instance.log.0.YYYYDDMMHHMMSS.out or db2audit.db.database_name.log.0.20111104015353.out format.

      • yes/no: Enter yes or no, to enable or disable the audit trail cleanup. Entering yes deletes the archived IBM DB2 audit files that were collected by the Oracle AVDF DB2 audit trail. If you omit this value, then the default is no.

      • database_name: (Optional) This is the name, or names separated by spaces, of the database(s) that contain the audit records.

        The utility creates a separate ASCII file for each database named in the command. If this parameter is omitted, then the utility converts the instance binary to an ASCII file. This parameter enables you to collect categories of audit records such as object maintenance (objmaint) records, which capture the creation and dropping of tables.

        Important: If you enter more than one database name in this command, be sure to put the ASCII file for each database in a separate directory after you run the command.

      Example 1: The following command creates an ASCII file for the TOOLSDB database, puts the file in the /home/extract_dir directory, and deletes archive files after you have collected audit data:

      DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes -databasename TOOLSDB

      Example 2: The following command creates an ASCII file for the database instance, puts the file in the /home/extract_dir directory, and deletes archive files after you have collected audit data:

      DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes

To schedule the script to run automatically, follow these guidelines:

  • UNIX: Use the crontab UNIX utility. Provide the same information that you would provide using the parameters described previously when you normally run the script.

  • Microsoft Windows: Use the Windows Scheduler. Provide the archive directory path (for release 9.5 databases only), extraction path, and secured target database name in the scheduled task.

6.4.7 Configuring Audit Trail Collection for Oracle Real Application Clusters

You can configure audit trail collection for Oracle Real Application Clusters (Oracle RAC).

Configure a SCAN listener for the RAC and use the SCAN listener IP as the single IP during target registration.

To configure Audit Trail collection for Oracle Real Application Clusters (RAC), follow these guidelines.

Audit Trail Type Number of Audit Trails

TABLE

To configure table trail audit data collection from Oracle RAC environment, 1 audit trail is sufficient.

DIRECTORY

To configure directory audit data collection from Oracle RAC environment, separate audit trails are required. The trail location must be different directories in the shared storage of the Oracle RAC environment.

TRANSACTION LOG (REDO)

To configure Transaction Log (REDO) audit data collection from Oracle RAC environment, 1 audit trail is sufficient.

See Also:

Adding an Audit Trail in the Audit Vault Server to configure an audit trail.

6.4.8 Configuring Audit Trail Collection For CDB And PDB

Oracle Database can work as Container Database (CDB) or Pluggable Databases (PDB). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c are non-CDB.

The PDB and CDB can be registered as secured targets. Oracle Audit Vault and Database Firewall supports CDB and PDB level audit collection. To collect audit data from multiple PDB instances within a CDB you must create a separate secured target for each PDB instance.

CDB_UNIFIED_AUDIT_TRAIL provides audit records from all PDB instances in a multitenant environment. The performance of audit collection from CDB_UNIFIED_AUDIT_TRAIL is lower than audit collection from UNIFIED_AUDIT_TRAIL of every PDB instance. If the number of audit records generated per day in CDB_UNIFIED_AUDIT_TRAIL is higher than 8 million, then configure audit collection from UNIFIED_AUDIT_TRAIL of every PDB instance.

To configure Audit Trail collection for CDB or PDB, follow these guidelines:

Audit Trail Type Guidelines

TABLE

  • Audit records can be collected from audit tables of CDB. They contain audit details of only CDB activities.

  • Every PDB has its own audit tables for storing audit data that are independent of each other. Hence, separate audit trails are needed for every PDB to collect audit data.

  • CDB level audit collection of PDB audit is not supported.

Note:

Audit collection from CDB_UNIFIED_AUDIT_TRAIL is not supported.

DIRECTORY

  • Audit from directory trail can be collected for CDB, by providing directory trail location as <value of AUDIT_FILE_DEST> (database parameter).

  • Audit from directory trail can be collected for each PDB, by providing directory trail location as <value of AUDIT_FILE_DEST>/<GUID of the PDB>.

Note:

If you are using a multitenant container database (CDB) in Oracle Database 12c, then for a CDB you must register a target for the CDB as well as for every PDB.

TRANSACTION LOG (REDO)

Transaction log collection is not supported for PDB or CDB.

Audit Policy Retrieval and Provisioning

Audit policies can be provisioned or retrieved by treating every PDB as an independent secured target.

See Also:

Adding an Audit Trail in the Audit Vault Server to configure an audit trail.

6.5 Configuring Enforcement Points

Learn about configuring enforcement points.

Note:

If you are using Transparent Application Failover (TAF), Fast Application Notification (FAN), or the Oracle Notification Service (ONS), then SQL commands are not sent through this channel. There is no need to route them through Oracle Database Firewall. ONS communications bypass the Database Firewall and connect directly to the ONS listener. ONS communications, including destination host and port, are configured in the ons.config properties file located on the ONS server.

6.5.1 About Configuring Enforcement Points for Secured Targets

If you are monitoring databases with a Database Firewall, you must configure one enforcement point for every secured target database that you want to monitor with the firewall. The enforcement point configuration lets you specify the firewall monitoring mode (monitoring only or blocking), identify the secured target database being monitored, the network traffic sources to that database, and the Database Firewall used for the enforcement point.

Before configuring enforcement points, configure network traffic sources as part of database firewall configuration.

See Also:

Configuring Database Firewall and its Traffic Sources on Your Network

6.5.2 Creating and Configuring an Enforcement Point

Configure each enforcement point at the Audit Vault Server console. If you have configured a resilient pair of Audit Vault Servers, configure the enforcement points on the primary server.

Prerequisites

To configure an enforcement point:

  1. Click the Secured Targets tab, and from the Monitoring menu, click Enforcement Points.

    The Enforcement Points page displays a list of configured enforcement points and their status.

  2. Click Create.
  3. Enter a Name for this enforcement point.
  4. Select a Monitoring Mode:

    • Database Policy Enforcement (DPE) - to block or substitute SQL statements.

    • Database Activity Monitoring (DAM) - to log SQL statements and raise alerts only

  5. In the Select Secured Target to monitor section, select a secured target.

    Secured targets are listed here with their specified firewall policy. If the policy specified contains SQL blocking rules, but you select the DAM mode (monitoring only), SQL statements will not be blocked. Therefore, if you want to block SQL statements according to policy rules, you should have both a blocking policy for the secured target, and DPE monitoring mode for the enforcement point.

  6. In the Select Firewall section, select the Database Firewall that will handle this enforcement point.

    The Select Traffic Sources section appears below the Select Firewall section.

  7. Select traffic sources in either the Bridged Interfaces or the Proxy Interfaces area.

    Note: If you select a proxy traffic source, you cannot select any other traffic sources. Also, selecting a proxy forces the Monitoring Mode to DPE.

  8. Click Save.

    The new enforcement point appears in the Enforcement Points list and starts automatically.

  9. To stop or restart the enforcement point, select it from the Enforcement Points list and click Stop or Start.

Note:

When you use a Database Firewall in DPE mode, you must configure any external devices that use IP or MAC address spoofing detection rules such that they ignore database IP or MAC address changes made by the Database Firewall.

See Also:

6.5.3 Modifying an Enforcement Point

After you create an enforcement point, you can modify it to change its settings, or to enable database response monitoring, database interrogation, and/or host monitoring.

Advanced settings in the enforcement point let you configure Oracle Audit Vault and Database Firewall to work with BIG-IP Application Security Manager (ASM).

To modify an enforcement point:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click Secured Targets tab.
  3. From the Monitoring menu, click Enforcement Points, and then click the name of the enforcement point you want to modify.
  4. In the Modify Enforcement Point page, you can change the following settings:

    • Secured Target - Select a different secured target to monitor

    • Monitoring Mode - Select the alternate monitoring mode.

      Note: If switching from DAM to DPE mode, select whether or not to Maintain Existing Connections from clients to your secured target database. If you select this option, existing connections will not be disrupted, but will need to reconnect to the secured target database before they can be monitored in DPE mode.

    • Traffic Sources - Enable different traffic sources.

    • Database Response - Select to enable database response monitoring.

    • Database Interrogation - Select to enable database interrogation.

  5. Click Save.

6.5.4 Starting, Stopping, or Deleting Enforcement Points

To manage enforcement points:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab, and under Monitoring, click Enforcement Points.
  3. Select the enforcement points you want, and click one of the following buttons:

    • Start to start the enforcement point

    • Stop to stop the enforcement point

    • Delete to delete the enforcement point

    See Also:

    Logging in to the Audit Vault Server Console UI

6.5.5 Viewing the Status of Enforcement Points

To view the status of enforcement points:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab, and under Monitoring, click Enforcement Points.

    A list of enforcement points and their status is displayed. Possible status values are:

    • Up - The enforcement point is up and running, and there are no errors.

    • Suspended - The user has stopped the enforcement point, and there are no errors.

    • Down - The enforcement point is not working, probably due to errors.

    • Unreachable - There are communications errors between the Database Firewall and the Audit Vault Server.

    See Also:

    Logging in to the Audit Vault Server Console UI

6.5.6 Finding the Port Number Used by an Enforcement Point

To find the port number used by an enforcement Point:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab, and under Monitoring, click Enforcement Points.
  3. Select the enforcement points you want, and in the Modify Enforcement Point page click Advanced.

    The port number is shown next to DBFW TCP Port.

    See Also:

    Logging in to the Audit Vault Server Console UI

6.6 Configuring Stored Procedure Auditing (SPA)

Stored procedure auditing (SPA) enables Oracle Audit Vault and Database Firewall auditors to audit changes to stored procedures on secured target databases. Oracle Audit Vault and Database Firewall connects to the database server at scheduled intervals and discovers any changes or additions that have been made to stored procedures. SPA is supported for all database secured targets supported by Oracle Audit Vault and Database Firewall.

To enable SPA, you simply configure the user account privileges necessary for Oracle Audit Vault and Database Firewall to do stored procedure auditing on a secured target. Oracle Audit Vault and Database Firewall provides scripts for setting up these privileges. Run the scripts specific to the secured target type.

An Oracle Audit Vault and Database Firewall auditor can view changes to stored procedures in reports if the auditor enables Stored Procedure Auditing in the Secured Target configuration.

See Also:

6.7 Configuring and Using Database Interrogation

Learn about configuring and using database interrogation.

6.7.1 About Database Interrogation

Database interrogation allows the Database Firewall to interrogate supported database secured targets for specific information. The information collected depends on the database type. This section describes two ways to use database interrogation:

6.7.1.1 Using Database Interrogation for SQL Server and SQL Anywhere Databases

You can use database interrogation to interrogate a monitored Microsoft SQL Server and Sybase SQL Anywhere database to obtain the name of the database user, operating system, and client program that originated a SQL statement, if this information is not available from the network traffic. This information then is made available in the Audit Vault and Database Firewall reports.

To configure database interrogation for these two databases you must:

  • Create a user account for Audit Vault and Database Firewall database interrogation on the database. Grant specific privileges to that user account.

  • In Audit Vault and Database Firewall, enable database interrogation in the enforcement point that monitors the secured target database.

See Also:

6.7.1.2 Using Database Interrogation for Oracle Databases with Network Encryption

If you are using the Database Firewall to monitor an Oracle Database secured target that uses Network Encryption, you must use Database Interrogation in order to decrypt statements sent to, and responses received from, that database so they can be analyzed.

Limitations on Decryption of Oracle Database Statements

Configuring Audit Vault and Database Firewall to decrypt traffic with Network Encryption has the following limitations:

  • There is no statement substitution in Audit Vault and Database Firewall when Network Encryption checksum is used.

  • There is no support for Network Encryption RC4 cipher.

  • Supported versions of Oracle Database.

See Also:

Configuring Oracle Database Firewall for Databases That Use Network Encryption

6.7.2 Configuring Database Interrogation for SQL Server and SQL Anywhere

Topics

6.7.2.1 Setting Database Interrogation Permissions in a Microsoft SQL Server Database

To set up the user account for a Microsoft SQL Server (versions 2005, 2008, or 2012) database:

  1. Create a user account for Audit Vault and Database Firewall database interrogation on the database that you want to interrogate. (This database should be a secured target in Audit Vault and Database Firewall.)

    Make a note of the user name and password for this account.

  2. Grant the following permissions to the user account you created in Step 1:

    • VIEW ANY DEFINITION and VIEW SERVER STATE for SQL Server 2005 and later

    • SELECT on the master.dbo.sysdatabases table

  3. Enable database interrogation in the enforcement point that monitors this secured target database, using the credentials you created in Step 1.

6.7.2.2 Setting Database Interrogation Permissions in a Sybase SQL Anywhere Database

Note: Before you can use Sybase SQL Anywhere, you must download and install the SQL Anywhere ODBC driver for Linux.

To set user permissions for database interrogation in a Sybase SQL Anywhere database:

  1. Create a user account for Audit Vault and Database Firewall database interrogation on the database that you want to interrogate. (This database should be a secured target in Audit Vault and Database Firewall.)

    Make a note of the user name and password for this account.

  2. Grant the following permissions to the user account you created in Step 1:

    • CONNECT

    • SELECT on these system tables:

      sys.sysuser
sys.sysuserauthority
sys.sysremoteuser
sys.sysloginmap
sys.sysgroup
  3. Enable database interrogation in the enforcement point that monitors this secured target database, using the credentials you created in Step 1.

6.7.3 Enabling Database Interrogation

Use this procedure to enable Database Interrogation.

Prerequisite

Log in to the Audit Vault Server console as an administrator. See Logging in to the Audit Vault Server Console UI for more information.

To enable database interrogation in an enforcement point:

  1. Click the Secured Targets tab, and then from the Monitoring menu, click Enforcement Points.
  2. Find the enforcement point that monitors the secured target that will be interrogated, and then click the name of that enforcement point.

    The Modify Enforcement Point page appears.

  3. In the Database Interrogation section of the page, click the Enable Database Interrogation check box.
  4. Enter values for the following:

    • Database Address and Port - Enter the IP address and port number of the secured target database that will be interrogated.

    • Database Name - Enter the name of the database or database instance.

    • User Name - Enter the database interrogation user name that was set up for this secured target.

      See Also:

      Configuring Database Interrogation for SQL Server and SQL Anywhere

    • Password and Re-type Password - Enter the password for the database interrogation user name.

  5. Click Save.

6.7.4 Disabling Database Interrogation

You can temporarily disable database interrogation. Audit Vault and Database Firewall saves the configuration information that you have created for the next time that you want to enable it.

To disable database interrogation:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab, and then from the Monitoring menu, click Enforcement Points.

    The Enforcement Points page appears, listing enforcement points and their status. You can sort or filter the list.

  3. Find the enforcement point for which you want to disable database interrogation, and then click the name of that enforcement point.

    The Modify Enforcement Point page appears.

  4. In the Database Interrogation section of the page, clear the Enable Database Interrogation check box.
  5. Click Save.

    See Also:

6.8 Configuring Oracle Database Firewall for Databases That Use Network Encryption

Learn about configuring Oracle Database Firewall for databases that use network encryption.

To configure Database Interrogation for an Oracle Database that uses Network Encryption, follow steps in this section:

6.8.1 Step 1: Apply the Specified Patch to Oracle Database

Learn how to apply the patch to Oracle Database

Note:

This step is not required for Oracle Database versions 11.2.0.4 or later. For all versions prior to 11.2.0.4, apply the patch specified in this section on the Oracle Database that is using Network Encryption.

To apply the patch:

  1. Shut down the Oracle Database.
  2. Get the patch identified by the bug number 13051081.

    The patch file will be in the format: p13051081_OracleVersion_Platform.zip. For example: p13051081_112030_Linux-x86-64.zip

  3. Unzip the patch .zip file in a directory, identified here as Patch_Directory.
  4. Go to the directory Patch_Directory/13051081.
  5. Execute the command:

    $ opatch apply

  6. Start the Oracle Database.

6.8.2 Step 2: Run the Oracle Advance Security Integration Script

To run the Network Encryption integration script:

  1. From the Oracle AVDF utilities file dbfw-utility.zip (downloaded with your Oracle AVDF software), copy the database directory to a location from which you can connect to the Oracle Database being patched.
  2. In this location, go to the database/ddi directory and uncompress one of the two oracle compressed files (both contain the same content), preferably into a directory called oracle.

    This directory now contains the uncompressed file: advanced_security_integration.sql.

  3. If the installed version is release 12.2.0.11.0 and prior, then execute the following command as a user that has privileges to create users and grant privileges:

    sqlplus / as sysdba @advanced_security_integration schema password

    For schema, use the name of an existing schema or choose a name for a new schema. We do not recommend using SYSTEM or SYS as the target schema. If the schema does not exist, this procedure will create a user and a schema.

    This command grants the create session and resource privileges to the schema user.

    The password for the schema is set to password.

    A package supporting Network Encryption integration is installed into schema.

  4. If the installed version is release 12.2.0.12.0 and later, then execute the following command as a user with privileges to create users and grant privileges. This is a DDI enhancement to retrieve session information for Oracle Database targets which is available from release 12.2.0.12.0 and onwards. This is applicable for Database Firewall in Monitoring and Blocking mode, or in Monitoring only mode.

    sqlplus / as sysdba @advanced_security_integration <param1> <param2> <param3>

    where <param1> is the schema or username

    <param2> is the password to be set for the username

    <param3> valid values are ASO and SESSION_INFO

    ASO retrieves oracle native network encryption key and session information

    SESSION_INFO retrieves session information

    Note:

    The third parameter (<param3>) is mandatory. In case it is missed, the system prompts with a help message.

    In case value of the third parameter (<param3>) is incorrect, the following help message is displayed:

    Invalid value is provided for <param3>
The valid values are ASO, SESSION_INFO.
ASO retrieves oracle native network encryption key and session information
SESSION_INFO retrieves session information

6.8.3 Step 3: Provide the Database Firewall Public Key to the Oracle Database

In order for to decrypt database traffic using database interrogation, you must provide the Database Firewall public key to the Oracle Database that is using Network Encryption.

To provide the public key to the Oracle Database:

  1. In the Administration console of the Database Firewall that will be monitoring this Oracle Database, in the System menu, click Public Keys .


    Description of GUID-5A17929E-C65B-409D-B14E-1AEBE59AFE35-default.gif follows
    Description of the illustration GUID-5A17929E-C65B-409D-B14E-1AEBE59AFE35-default.gif

  2. Copy the public key under Oracle Advanced Security Decryption and paste it into a text file, for example, dbfw_public_key.txt.

    Each Database Firewall has its own public key. In a case where you have Database Firewall high availability or enforcement point resiliency, when you have more than one Database Firewall monitoring this secured target, each Database Firewall public key must be copied and appended to the dbfw_public_key.txt file.

    Note: For security purposes the dbfw_public_key.txt file must have the same access permissions as the sqlnet.ora file on the Oracle Database server.

  3. Modify the sqlnet.ora file in the Oracle Database to include the public key and to require Network Encryption native traffic encryption:

    1. Put the file you created in Step 2 on the Oracle Database server, preferably in the same directory as the sqlnet.ora file.

    2. Open the sqlnet.ora file and append the following parameters (in this example the public key file is dbfw_public_key.txt):

      SQLNET.ENCRYPTION_TYPES_SERVER=AES256
SQLNET.DBFW_PUBLIC_KEY="/path_to_file/dbfw_public_key.txt"
SQLNET.ENCRYPTION_SERVER=REQUIRED

      Note: If the sqlntet.ora file contains the optional parameter SQLNET.ENCRYPTION_CLIENT, its value must not be REJECTED. Otherwise, an error will occur.

    3. Save and close the sqlnet.ora file.

See Also:

Oracle Database Security Guide for more information on network encryption.

6.8.4 Step 4: Enable Database Interrogation for the Oracle Database

Follow the procedure in "Enabling Database Interrogation" to complete the Database Interrogation setup for an Oracle Database that uses Network Encryption.

6.9 Configuring and Using Database Response Monitoring

Topics

6.9.1 About Database Response Monitoring

Enabling the Database Response Monitoring feature allows the Database Firewall to record responses that the secured target database makes to login requests, logout requests and SQL statements sent from database clients, as shown in Figure 6-1. This feature allows you to determine whether the database executed logins, logouts and statements successfully, and can provide useful information for audit and forensic purposes.

Figure 6-1 illustrates the process flow of database response monitoring.

Figure 6-1 Database Response Monitoring

Description of Figure 6-1 follows
Description of "Figure 6-1 Database Response Monitoring"

The Oracle AVDF auditor can view database responses in audit reports.

Database Response Monitoring records database responses for all SQL statements, logins, and logouts that are logged the Database Firewall policy

The information recorded includes the response interpreted by Oracle AVDF (such as "statement fail"), the detailed status information from the database, and the database response text (which may be displayed at the database client).

6.9.2 Configuring Database Response Monitoring

Topics

6.9.2.1 Enabling Database Response Monitoring

To enable database response monitoring for a secured target:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Secured Targets tab, and then from the Monitoring menu, click Enforcement Points.

    The Enforcement Points page appears, listing enforcement points and their status. You can sort or filter the list.

  3. Find the enforcement point the monitors the secured target, and then click the name of that enforcement point.

    The Modify Enforcement Point page appears.

  4. In the Database Response section of the page, select the Enable Database Response check box.

    If you also select Full error message annotation, any detailed error message text generated by the database is logged along with the error code.

  5. Click Save.

    See Also:

6.9.2.2 Setting Up Log-in and Log-out Policies in Oracle Database Firewall

Learn how to set up Oracle Database Firewall log-in and log-out policies.

The login and logout policies are stored in Oracle Audit Vault and Database Firewall and must be configured in the firewall policy.

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide

6.10 Securing the Agent and Oracle Database Secure Target Connection

Data security between an AVDF agent and an Oracle Database secure target is achieved by default, through network encryption over TCP connection. Data security can also be achieved by using a TCPS/SSL connection.

If the secure target has been setup to accept TCPS/SSL connections, then follow these steps to configure the agent:

  1. Ensure that in the secure target's sqlnet.ora file, the following parameters are set:

    • SQLNET.ENCRYPTION_SERVER = REQUESTED, REJECTED, or the default, ACCEPTED.

    • SQLNET.CRYPTO_CHECKSUM_SERVER = REJECTED or the default, ACCEPTED

  2. Log in to the Audit Vault Server console as an administrator.

  3. Click the Secured Targets tab.

  4. Select the name of the secured target that you want to modify.

  5. In the Modify Secured Target page, do the following:

    1. In the Secured Target Location (For Auditing) area, enter the details in Host Name/IP Address, choose TCPS protocol, Server DN, and upload the wallet file.

    2. Or alternately, select the Advanced option, choose TCPS protocol, upload the wallet file, and then in the Secured Target Location field, provide the TCPS connection string.

      For example:

      jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=host_ip)(PORT=port_number))(CONNECT_DATA=(SERVICE_NAME=service_name)(SERVER=DEDICATED))(SECURITY= (SSL_SERVER_CERT_DN="dn")))

    3. Click Save.

See Also: