Database Object Rule

Learn about the Database Object rule.

Database Objectrule can be used in the following scenarios:

Database Object rules are used to allow, alert or block specific types of SQL statements (DML, DDL, etc.) on specific database objects such as tables and views. These rules are often used for controlling access to sensitive application data.

• Monitoring specific statement types that are of interest on sensitive tables. Use Any table field, and select TRANSACTION COMPOSITE under Statement Classes. You can also select the tables AVG_COST, BOOKS, and BUSINESS_CONTACTS. A statement that matches this rule must be TRANSACTION COMPOSITE and it can contain any of the tables selected.

• Monitoring specific statement types that are of interest on sensitive tables, by using All table field. Select Procedural and Composite under Statement Classes. You can also select the tables AVG_COST, BOOKS, and BUSINESS_CONTACTS. A statement that matches this rule must either be Procedural or Composite, and the SQL statement must have all the tables (AVG_COST, BOOKS, and BUSINESS_CONTACTS).

• Monitoring exfiltration attempts of sensitive data. Use this functionality by creating a Database Object rule to capture the number of rows returned by a SELECT query. Select Data Manipulation Read only under the Statement Classes field. This option is available only for Data Manipulation Read only statement class. All or ANY tables can be selected according to the requirement. This data is further available for selection in the All Activity and Database Firewall Reports. Alerts can be configured if the returned number of rows exceeds a threshold value.

1. Log in to Oracle Database Security Central Console as an auditor.

2. Select Policies.

3. Select Database Firewall Policies tab in the left navigation menu.

4. Select the name of an existing user-defined policy . The page specific to that policy appears.

   Note: Though the page displays both User-defined Database Firewall Policies and Oracle Pre-defined Database Firewall Policies, only User-defined Database Firewall Policies can be altered.

5. Expand the Database Objects section, and then select on an existing database object rule or select Add. The Database Objects dialog is displayed.

6. Provide a Rule Name.

7. Enter a Description.

8. Select a Profile, the default is none as shown by -.

9. In the Commands section, select the specific commands to add to this rule

10. If the target type is an Oracle Database and one of the values for the Commands field is SELECT, the field Capture number of rows returned for SELECT queries is able to be toggled to Yes. Upon setting this field to Yes, it captures the number of rows for select queries as per the policy, and displays in the All Activity and Database Firewall Reports under the column Row Count. This column will be available for selection in the reports. Alerts can be configured for the number of rows fetched or queried.

11. In the Tables/Views to be monitored section, select one of the global or local sets from the DB Object Set drop down.

    Database object sets can be global or local sets. Global sets can be viewed in and applied to multiple database firewall policies, whereas local sets can only be viewed in and applied to the database firewall policies they were created in. Global sets can be created inDiscover & Classify.

    Note: All Tables and Views are monitored unless specified.

    1. To add Database Object Sets, select the + button to the right of the text box.

    2. In the dialog box you can edit the list of tables to be monitored from the three tabs: Enter Values, From File, or From Collected Data.

       • In the Enter Values type the table names in the text box. You will need to enter each table or view on a separate line. Select Save once done.

         • If left empty, all the tables analyzed by the Database Firewall are considered.

         • Policy evaluation happens on the table irrespective of schema. For example, the policy will evaluate qualified table name, Myschema.T1 and the plain table name, T1 in the same manner.

         • Table names can also include wild card characters by using * in the table name. For example, T* will include T1 and T2.

       • In the From File select theChoose File field to upload a .txt file containing the names of tables or views, with one name per line. Select your .txt file from the pop-up of your computer's files. Select Save once done.

       • In the From Collected Data select tables from the Available column and move them to the Selected column using the filters in the middle. You can search for tables by typing in the search box in the top left of the dialog. This will narrow down the list of visible tables under the Available column. Select Save once done.

       • (Optional) At the bottom of each tab is a table called Tables/Views to be monitored. This table contains the selected tables or views that will be monitored. An empty list means all tables and views are monitored. To select all tables and views, select the checkbox to the left of the Tables/views column header. To select any tables and views, select the checkbox to the left of the Tables/views column for that table or view. Select Delete to remove any selected table(s) or view(s) from the list to be monitored.

12. In the Action to be taken section, select the Action, Logging Level, and Threat Severity for this rule from the appropriate drop down list.

13. If you select Block as the Action, then the Substitution SQL field appears. Enter a statement to substitute for the SQL statement that was blocked.

14. Select Save.

Here are some important points to note for capturing return number of rows for SELECT queries feature:

• This is applicable when Database Firewall is deployed in Monitoring / Blocking (Proxy) mode.

• This functionality does not support use of cursors and partial data fetch.

• This functionality is supported on all 64 bit operating systems.

• This functionality can be used with JDBC driver based clients, SQL*Plus, and other Oracle DB OCI based clients.

• In case the return row count information does not show in reports, then review the traffic log timer. See Retrieval of Row Count Does Not Work for more information.

• While configuring a Database Object rule, consider the tables for which the return row count feature needs to be enabled. It is recommended to enable the return row count option on SELECT queries that operate on a single table. Composite queries on multiple tables can raise false positives. Use ANY or ALL selection as per the requirement.

• A malicious user may use different ways to hide data exfiltration. One of them may be partial fetches of the result set. Database Firewall marks the row count with value -1 for such cases. It is recommended to configure alerts based on this behavior.

Related Topics

• Statement Class to Command Mappings for Database Firewall Policies