6 Creating Database Firewall Policies

You can create and manage Database Firewall policies.

6.1 Overview of Database Firewall Policies

Database Firewall policies enable you to apply a firewall around an Oracle database target.

6.1.1 About Firewall Policies

You have a great deal of flexibility when you create an Oracle Database Firewall policy.

Oracle strongly recommends that you read Chapter 3 of Oracle Audit Vault and Database Firewall Concepts Guide to understand the concepts of how a Database Firewall policy works, as well as to understand the various Database Firewall protection modes and network placement options.

Successful deployment of a Database Firewall depends on an effective policy. Oracle Audit Vault and Database Firewall includes preconfigured firewall policies (listed under Available Policies in the Database Firewall Policy page of the Audit Vault Server console). These include policies, for example, that log all SQL statements, or log only unique SQL statements. In addition, the Database Firewall policy editor enables you to design your own policies quickly and efficiently.

Policy rules can depend on any combination of the SQL statement type, name of the database user, IP address of the database client, operating system user name, client program name, or any exceptions you specify.

Developing a policy is an iterative process that keeps refining and improving the policy with new data.

6.1.2 The Steps of Developing a Database Firewall Policy

After you create a Database Firewall policy, you make it available to targets.

Developing a policy consists of these main steps:

  1. Create a firewall policy in the Audit Vault Server.

  2. Design your policy by setting policy actions and rules.

  3. Publish the policy to make it available for applying to targets.

  4. Assign the policy to selected targets.

6.2 Creating a Database Firewall Policy

Learn about creating a Database Firewall policy.

6.2.1 Understanding Database Firewall Policies

You can create a new policy or modify existing policies in the Database Firewall Policies page.

This page shows the policy rules that are being applied to groups of similar SQL statements (known as clusters) being monitored by the Database Firewall, as well as exceptions and other rules that may apply.

Select a policy under the Database Firewall Policies page. It is divided into these sub-sections:

  • Session Context - Lists exceptions you have created. The rules that you have assigned to SQL statement clusters will not apply to these exceptions. You can move the rules up or down in the list. The rules are evaluated in the order listed.

  • SQL Statement - Displays the number of SQL statement clusters for which you have defined policy rules, and their policy actions (such as Warn or Block).

  • Database Objects - Lists special policies you have created for specific statement classes and/or specific tables in your target databases. If you have identified specific tables in a policy in this section, the policy rule applies if it matches any or all of the tables.

  • Default - Shows the default rule for any statements that are not matched by the rules set under SQL Cluster Sets, Session Context, or Database Objects.

Note:

The policy rules are evaluated from the top, to the bottom. The first category of rules is Session Context and Default is the last. If the incoming traffic matches any of the rules, then no further rule is evaluated.

6.2.2 Creating a New Database Firewall Policy

You can create a new firewall policy or copy an existing policy and edit it.

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click Policies tab.
  3. Click on Database Firewall Policies tab in the left navigation menu.

    This page lists the policies you have created, as well as the pre-defined policies in two tabs.

  4. Click Create.

    The Create Policy dialog box appears.

  5. Select the Target Type from the drop-down list.
  6. Enter a Policy Name.
  7. Optionally, enter a Description.
  8. Click Create.

6.2.3 Copying a Database Firewall Policy

You can copy an existing firewall policy and edit to create a new policy.

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click the Policies tab.
  3. Click Database Firewall Policies on the left.

    This page lists the policies you have created, as well as the pre-defined policies.

  4. Select the check box against the policy you want to copy.
  5. Click Copy.

    The Copy Policy pop-up appears. The Target Type field is already filled in.

  6. Enter a Policy Name.
  7. Optionally enter the Description.
  8. Click Copy.

    Policy created successfully message is displayed.

  9. Click on the name of the policy created to make any further changes.

6.2.4 Editing a Database Firewall Policy

You can edit only firewall policies that you have created or copied.

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click the Policies tab.
  3. Click on Database Firewall Policies tab in the left navigation menu.
  4. Click on the name of the specific policy. The details of the policy are displayed in the main page.
  5. Make edits to the policy as required.
  6. Click Save.
  7. The rules are categorized under Session Context, SQL Statement, Database Objects, and Default. You can make changes to the rules.
  8. Click Add at the bottom right corner.
  9. For example, SQL Statement and click Add. In the SQL Statement dialog, enter the Rule Name.
  10. Optionally enter the Description.
  11. Select the Profile previously created.
  12. Select the Cluster Set(s) previously created.
  13. Select the appropriate values under Action, Logging Level, and Threat severity. Select the Logging Level to Always.

    Set an escalation action by checking on Set threshold for escalating action. Additional fields are populated when this box is checked. Enter the details under:

    • Threshold
    • Threshold Time (in seconds)
    • Threshold Action
  14. Click Save.

6.3 Defining a Database Firewall Policy

When you define a Database Firewall policy, you can specify filters, rules, and objects for it.

6.3.1 About Defining the Policy

To successfully deploy a Database Firewall you must develop an effective policy.

Using the firewall policy editor, you can design and refine a policy based on SQL statements from actual traffic to your targets. Oracle Audit Vault and Database Firewall analyzes SQL statements by looking at SQL traffic to any selected target to which you have access. It then groups the SQL into groups of similar statements known as clusters, and displays these clusters in a firewall policy in the Audit Vault Server console.

You can then define the rules of your firewall policy for each type of SQL clusters. This allows you to have a allowlist of permissible SQL, as well as a blocklist of statements that are not allowed based on various criteria. Defining rules for a firewall policy includes:

  • Specifying these settings for each cluster in SQL Statement:

    • Action: Whether or not the Database Firewall permits, blocks, or produces a warning when it encounters a statement that matches the cluster.

    • Logging level: Whether the Database Firewall never logs, logs all statements, or logs statements that have a unique combination of cluster, source IP address, database username, operating system username, and client program name. You can use logging as an independent record of database activity, which may, for example, be used for future audit or forensic purposes.

      Consider the amount of logging carefully, because increasing the data logged directly impacts required disk space. The frequency for the sample logging is every tenth statement for the cluster.

      Oracle recommends that you use the "unique" logging level in policies for the initial policy because it guarantees one of each type. It efficiently samples traffic without logging all statements.

    • Threat Severity: The anticipated threat from statements in a cluster. There are five threat severity settings, ranging from Insignificant to Catastrophic (or Unassigned). When the Database Firewall logs a statement, the threat severity of the statement is also logged. You can use third-party reporting tools and syslogs to display SQL statements based on the logged threat severity.

  • Creating Exceptions to the policy settings for your SQL statements

  • Adding Database Objects (or rules) that are triggered when specific statement types are encountered and/or selected tables are called

  • Defining a Default rule to handle any SQL that does not match any of your other policy rules.

  • Creating profiles to apply a different set of policy rules from your normal policy, based on specific session criteria (such as client IP address or user name)

Note:

  • The policy rules are evaluated from the top, to the bottom. The first category of rules is Session Context and Default is the last. If the incoming traffic matches any of the rules, then no further rule is evaluated.

  • In blocking mode, by default the Database Firewall blocks all IPv6 traffic regardless of the policies in place.

6.3.2 Defining Session Filters to Use in Profiles and Exceptions

Policy controls let you create sets of filters, based on session information, to use in defining policy profiles and rules.

For example, when defining a Session Context rule you may want to exclude a set of database users from that rule, or apply the rule only if the SQL originates from specific IP addresses.

There are four types of filters for session information:

  • SQL Cluster Sets: A specified list of SQL cluster sets for a Database Firewall instance.

  • IP Address Sets: A specified list of IP addresses of database clients (IPv4 format)

  • Database User Sets: A specified list of database user login names

  • Database Client Sets: A specified list of client programs, for example SQL*Plus

  • OS User Sets: A specified list of operating system user names

  • Profiles: A specified list of profiles

Before defining policy profiles and exceptions, you must first define these sets of session filters, then you can include or exclude them in Profiles or Session Context rules.

To define session filters:

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

  2. Select the Policies tab.

  3. Select Database Firewall Policies on the left.

  4. Click on the name of the specific policy. The details of the policy is displayed.

  5. Click on Sets/Profiles on the top right corner.

  6. Click one of the following:

    • SQL Cluster Sets

    • IP Address Sets

    • Database User Sets

    • Database Client Sets

    • OS User Sets

    • Profiles

    This page lists the sets already defined for the specific policy.

  7. Select the specific set, and click Add to add a new set.

  8. In the dialog enter the details as follows:

    • For IP Address, enter database client IP addresses.

    • For Database Client sets, enter the client program name.

    • For Database User and OS User sets, enter user names.

  9. Click Save.

    The new set appears in the specific policy page.

  10. You can add more sets by clicking on Add button for the specific set.

Note:

Click on Database Firewall Policies, and then select a specific policy. Click on the Configuration button on the top right corner to change the settings of the specific firewall policy.

6.3.3 Creating an Session Context

After you create a session context, you must apply it.

6.3.3.1 About Session Context

A session context determines the action, logging level, and threat severity to use when certain session data is encountered.

For example, an session context could specify rules for statements that originate (or do not originate) from selected client IP addresses or database user names.

Session contexts override all other policy rules. For example, you may want to override the normal policy rules if SQL statements originate from an administrator, or if they originate from anywhere other than a specific IP address.

You can define many session contexts and control the order in which they are evaluated. Each session context has its own Action, Logging, and Threat Severity settings.

In order to create a session context, first define the sets of session factors to be used.

6.3.3.2 Creating Session Context

Any auditor can create a session context.

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

  2. Select the Policies tab.

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

  4. Select the name of the policy.

  5. Click Configuration button on the top right corner.

  6. Scroll down and click on Session Context sub tab on the main page.

  7. Click Add. The Session Context dialog is displayed.

  8. Enter a Rule Name and optionally Description.

  9. For the following fields listed under Ruleset section:

    • IP Address Set: Select to Include or Exclude, then select an IP address set.

    • DB User Set: Select to Include or Exclude, then select a database user set.

    • OS User Set: Select to Include or Exclude, then select an OS user set.

    • DB Client Program: Select to Include or Exclude, then select a database client program.

    Note:

    • There is no limit on the number of items that can be included in these sets.

    • You can use * (asterisk) as a wildcard for all the sets except IP Address Set.

    • There is an option in all the sets to make it case sensitive or otherwise. This can be done by selecting or deselecting the check box in the policy settings.

    For example, if you select to Include an IP Address Set, and Exclude a DB User Set, then this Session Context rule will only apply to SQL from the selected IP Address Set, but will not apply to SQL from database users in the selected DB User Set.

  10. Select the appropriate options available in the following fields:

    • Action
    • Logging Level
    • Threat Severity
  11. Optionally select Set threshold for escalating action if you want to apply a different action after SQL matches this rule a number of times. Then enter the following:

    1. Threshold: Enter the number of times SQL must match this rule before the escalation action is taken.

    2. Threshold Time (in seconds)

    3. Threshold Action: Select Warn or Block as the action taken after the threshold is met.

    4. Substitution SQL: (Optional) If you selected Block for the Threshold Action, enter a statement to substitute for the SQL matching this rule.

  12. Click Save.

  13. Click on the Login / Logout tab. Assign the Action and Threat Severity to apply to SQL matching the rule's filtering criteria. You can do this for both Login and Logout sub tabs.

  14. Check the box against Set failed login policy threshold under Failed Login as required. Fill in the rest of the fields as applicable.

  15. Check the box against Set Logging under Login and Logout sub tabs as required.

  16. Click Save.

6.3.3.3 The Order of Applying Session Context

Session Context rules are applied in the order they are listed in the policy overview page.

For example, if a statement matches a session context definition in both the first and second session context rule, the Action, Logging, and Threat Severity of the first session context is applied to that statement.

For this reason, it is more secure to have the more stringent action level in the first Session Context, so an exception with the action Block would supersede the exception with the action Warn. In this case, if a statement matches both groups, it will be blocked.

6.3.4 Defining Policy Rules for SQL Statement

Policy rules for SQL statements enable you to fine-tune the policy.

6.3.4.1 About SQL Statement

In any firewall policy, you can see SQL from traffic to any targets to which you have access as an auditor.

The Database Firewall analyzes SQL statements from traffic to any selected target and puts similar SQL statements into groups known as clusters. You can see a sample statement from each unique cluster in the SQL Statement section in the specific Firewall policy page.

You can then select any sample statement and set policy rules for that type of statement. The rules include the action the Oracle Database Firewall should take (such as Warn or Block), the logging level, and the threat severity to indicate.

6.3.4.2 Defining Policy Rules for SQL Statement

Any auditor can define policy rules for SQL statement firewall policies.

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

  2. Select the Policies tab.

  3. Click Database Firewall Policies on the left.

  4. Click on the name of the policy.

  5. Click on SQL Statement tab at the bottom of the screen.

  6. Click Add.

  7. In the SQL Statement pop up, enter a Rule Name.

  8. Enter the Description.

  9. Select the Profile and Cluster Set(s).

  10. In the Action sub tab, enter the details for Action, Logging Level, and Threat Severity fields to apply to SQL statements of this cluster type.

  11. Optionally select the checkbox for Set threshold for escalating action field, if you want to apply a different action after a statement matches this cluster a number of times. Then enter the following:

    1. Threshold: Enter the number of times a SQL statement must match this cluster before the escalation action is taken.

    2. Threshold Time (in seconds): Enter the time in seconds.

    3. Threshold Action: Select Warn or Block as the action taken after the threshold is met.

  12. Click Save.

6.3.4.3 SQL Statement Encrypted with Oracle Network Encryption

Oracle Database provides network encryption.

When enabled, this option automatically encrypts network traffic. In order for the firewall policy to encrypt SQL statement using Oracle network encryption, the Oracle Audit Vault and Database Firewall administrator must configure the Database Firewall to decrypt this traffic.

See Also:

Oracle Audit Vault and Database Firewall Administrator's Guide for information on how to do this configuration.

6.3.5 Creating a Database Object

Learn about creating database objects.

6.3.5.1 About Database Objects

Database Objects specify the action, logging level, and threat severity to use for specific types of statements and/or statements that operate on selected tables.

Database Objects can be used to loosen or tighten your normal policy rules if certain statements are encountered.

For example, if the normal policy action for a certain statement type is Warn, you may want to set up a Database Object that applies a Pass action if this statement type operates on tables containing public information. Alternatively, you may want to set up a Database Object that blocks all statements that operate on tables containing sensitive information.

6.3.5.2 Creating Database Objects

Any auditor can create a database object.

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

  2. Select the Policies tab.

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

  4. In the main page, the User-defined Policies sub tab is selected by default. Click the name of a specific policy.

    The page specific to that policy appears.

  5. Click Database Objects sub tab, and then click Add. The Database Objects dialog is displayed.

  6. Provide a Rule Name.

  7. Enter a Description.

  8. In the Statement Classes, select one or more types of statements that SQL statements must match in order to apply this rule.

  9. Under Database Tables section, select one of the following options in the Selected Tables field:

    • Any: If you add a Database Object in this section, and you select specific tables in the rule, the rule applies if a statement contains Any of the selected tables.

    • All: If you add a Database Object in this section, and you select specific tables in the rule, the rule applies if All tables in the statement are selected in the rule, though you may select more tables in the statement.

    Any rules are evaluated before the All rules.

  10. Select the Action, Logging Level, and Threat Severity for this rule from the appropriate drop-down list.

  11. 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.

  12. Optionally, select the tables to use for matching statements to this policy. The tables are matched according the Database Object chosen in the earlier step.

  13. Click Save.

6.3.5.3 The Order of Applying Database Objects

Database objects can be compared with ANY or ALL of the selected rules.

Database objects must be compared with the rules in Database Tables section. In the Selected Tables, choose ANY or ALL. The Database Firewall first compares statements against the Database Object rules as per the selection.

If any of the rules match the selected tables for a statement, the severity of the policy is applied accordingly. For example, a policy that blocks takes priority over a policy that warns.

If statements do not match a rule under any of the rules, then the Database Firewall compares statements as per ALL of the selected tables. If none of the tables are selected, then the rules are applicable as per ALL selected tables.

If you create a Database Object policy that only matches statement classes, but not tables, then the Database Object is evaluated with either ANY or ALL rules, depending on the selection while defining the policy.

6.3.5.4 Database Object Examples

There are two groups of Database Objects in a Firewall policy.

These group appear in the Any and All options of the Database Objects dialog, and are evaluated in that order.

The following are examples of how Database Object rules work:

  • You create a Database Object under Any section. The Database Object rules in this section are evaluated first.

    Under Statement Classes, you can select Composite with Transaction. You also select the tables AVG_COST, BOOKS, and BUSINESS_CONTACTS.

    A statement that matches this rule must be in the Composite with Transaction class and it must contain Any of the tables you selected. This rule is evaluated with the group of Database Objects in this section. This group of rules is evaluated first.

  • You create a Database Object in the All section. Database Object rules in this section are evaluated second.

    For Statement Classes, select Procedural and Composite. You also select the tables AVG_COST, BOOKS, and BUSINESS_CONTACTS.

    A matching statement must be in either the Procedural or Composite class and All the tables in the statement must match at least one of the tables AVG_COST, BOOKS, or BUSINESS_CONTACTS. So the statement may have one, two, or all three of these tables. However, if a different table appears in the statement, it does not match this rule.

6.3.6 Defining a Default rule

Learn about defining a default rule.

6.3.6.1 About the Default rule

The Default rule specifies the Action, Logging Level, and Threat Severity for any statement that does not fall into any other policy rules.

When the Database Firewall encounters such a statement, it will apply the Default rule.

Optionally, you can apply a different action in the Default rule after a number of similar statements are seen per minute, and/or provide a substitute statement.

6.3.6.2 Default rule settings in relation to other policies

When you set a Default rule, consider its impact on the Database Object, Session Context, or Invalid Statement policy.

If you set the action for the Default rule to Block, setting the action of a Database Object, Session Context, or the Invalid Statement policy to Pass or Warn will weaken the blocking action of the Default rule, and therefore the security of your Firewall policy overall.

6.3.6.3 Defining the Default rule

Any auditor can define the Default rule.

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

  2. Click on Policies tab.

  3. From the left navigation menu, click Database Firewall Policies.

  4. Click on the name of the specific policy.

  5. Scroll down and click on Default tab. Click on the Default Rule link.

  6. In the Default pop-up, select the values for Action, Logging Level, and Threat Severity fields.

  7. Optionally select Set threshold for escalating action field, if you want to apply a different action after statements fall within the default rule a number of times. Then enter the following:

    1. Threshold: Enter the number of times SQL must fall within the default rule before the escalation action is taken.

    2. Threshold Time (in seconds): Enter the time in seconds.

    3. Threshold Action: Select Warn or Block as the action taken after the threshold is met.

  8. Click Save.

6.3.7 Blocking SQL and Creating Substitute Statements

When the Database Firewall is in Monitoring / Blocking (Proxy) mode, you can configure a firewall policy to block certain SQL statements.

When you block SQL statements, you may also substitute a different SQL statement for any statement that is blocked. A substitute statement may be necessary to ensure that the database client is presented with an appropriate error message or response when a statement is blocked.

Note the following when blocking or writing substitute statements:

  • Blocking or warning when statements occur a specified number of times: You can choose to block the SQL statement or produce a warning if a statement that matches the selected cluster occurs a specified number of times (or threshold value). You should always enable logging for blocked statements.

  • Substituting statements: Substitution cannot be applied to the following SQL commands.

    • LOGIN USERNAME

    • EXECUTE CURSOR

    • ENCRYPTED

    • SHUTDOWN

    • DESCRIBE

    • ORADEBUG

    • TRANSACTION

    • LOB

    • INVALID OPERATION

    • COMMENT

    • COMPRESSED

    Although you cannot substitute SQL for them, you can create any other policy rules for these TNS protocol statements.

  • Creating substitute SQL statements: You must be sure that the results of the substitute statement can be handled by your client applications.

    The following is an example of a good substitute statement you can use for an Oracle Database target. This statement is harmless and does not return any values or affect performance.

    SELECT 100 FROM DUAL
    

6.3.8 Configuring Other Policy Settings

Learn how to configure other policy settings.

6.3.8.1 Creating Login and Logout Policies for Database Users

You can specify the login and logout policies for database users.

These policies send alerts when the rules you set for logins and logouts are violated. This is useful in the case of automated attacks on the database. You can configure the system to produce an alert when a database user logs in or out, and block database users who make a specified number of unsuccessful logins attempts.

Prerequisites

To configure the login and logout policies:

  1. Click on the Policies tab.
  2. From the left navigation menu, click Database Firewall Policies.
  3. Click on the name of the specific policy.
  4. In the Policy section, click Configuration button at the top right corner.
  5. Under the Login/Logout tab and Login sub-tab, configure the following:
    • Action: Specify the action

    • Threat Severity: To use for successful or unsuccessful database user logins.

    • Set Logging: To enable logging for logins.

    • Failed Login Policy: Optionally, select Enable failed login policy escalation. This setting lets you produce an alert, or block a client, after a specified number of consecutive unsuccessful logins. You can set a threshold and action. If triggered, login blocking continues for the specified Reset Period (in seconds). After this period, the database client can attempt to log in again.

  6. Under the Logout sub-tab configure the following:
    • Action: Specify the action on whether to pass or alert.
    • Threat Severity: Set for successful or unsuccessful database user logouts.
    • Set Logging: To enable logging for logouts.
  7. Click Save in the top right corner.
6.3.8.2 Masking Data

The Database Firewall always obfuscates passwords.

In addition, you can set rules for masking other sensitive data. Data masking prevents sensitive and confidential data, such as credit card numbers from appearing in the log files, reports, and in SQL statements of Firewall policy. If a logged statement matches your data masking policy, the policy automatically replaces all user data in that statement.

The characters used depend on the data type. Delimited strings are masked as "#". All numerical constants like float, hexadecimal, decimal, integer, and binary constants are masked as "0" (zero).

Note:

Once data is masked, it cannot be unmasked.

To set rules for data masking:

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

  2. Click on Policies tab.

  3. From the left navigation menu, click Database Firewall Policies.

  4. Click on the name of the specific policy.

  5. Click Configuration button in the top right corner.

  6. Click on the Sensitive Data Masking tab.

  7. Select or deselect the Mask logged data check box.

  8. Select either For all statements, or Only for statements matching the following criteria.

  9. If you selected to mask based on criteria, enter the details as follows:

    Having Columns:

    • Choose from the list.
    • Or enter a database column name from the list of options available. Data masking is applied on the statements containing these columns.
    • To remove one or more column names that are selected, click on the cross mark ("x") next to them. Accordingly the SQL statements are masked.

    Having Procedures:

    • Select Any. Data masking is applied on statements containing any procedure.
    • Or deselect Any and enter a procedure name and select from the list of options available to add the procedure name to the Having Procedures list. Data masking is applied on statements containing the specified procedures.
    • To remove one or more procedure names that are selected, click on the cross mark ("x") next to them. Accordingly the SQL statements are masked.
  10. Select whether to Include invalid statements. If this is selected even the invalid SQL statements are masked.

  11. Click Save.

6.3.8.3 Setting a Policy for Invalid SQL

You can set policy rules for SQL statements that are not recognized, such as statements that do not conform to the SQL syntax.

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

  2. Select the Policies tab.

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

  4. Click the name of the specific policy. The details of the policy are displayed on the page.

  5. Click Configuration button in the top right corner.

  6. Click Unknown Traffic sub tab in the main page.

  7. Assign the Action, Logging Level, and Threat Severity accordingly.

  8. Optionally select Set threshold for escalating action to apply a different action after invalid SQL statements are seen a number of times. Then, enter the following:

    1. Threshold: Enter the number of times invalid SQL must be seen before the escalation action is taken.

    2. Threshold Time (in seconds): Set the threshold time.

    3. Threshold Action: Select Warn or Block as the action taken after the Threshold is met.

    4. Substitution SQL: When Block is selected for Threshold Action, enter a statement to substitute for the invalid SQL.

6.3.8.4 Configuring Global Database Firewall Policy Settings

Any auditor can configure global database firewall settings.

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

  2. Select the Policies tab.

  3. From the left navigation menu, click Database Firewall Policies.

  4. In this page, click the name of the specific policy.

  5. Click Configuration button in the top right corner.

  6. Click on Policy Pattern tab. In this tab, configure the following:

    1. Under Log Pattern section, select whether to Strip binary objects and comments from log files.

    2. Under Action Rule Pattern section enter the Threshold action reset time (minutes) field. Enter a number in minutes. If you have set a Threshold in any of your policy rules, and the Threshold Action in your rule is taken, the action will not be repeated for the time you specify here. This prevents too many block/warn actions for the same rule.

    3. In the Action without substitution field, select the action to take (No response or Drop connection) if one of your policy rules is set to Block and you have not specified a substitute statement in the rule.

    4. Under the Syntax Rule Pattern section, select whether to treat Double quoted strings as identifiers. This determines whether double-quoted strings in SQL statements are treated as identifiers or string constants. If you deselect this check box, sensitive data masking (if used) will mask text in double quotes.

    5. For Case sensitive match, select whether this firewall policy does case sensitive matching for Client program name, Database username, and Operating system username.

  7. Click Save.

6.4 Using Profiles to Customize a Database Firewall Policy

Learn how to use profiles to customize a database firewall policy.

6.4.1 About Profiles

Within a firewall policy, a profile defines a different set of policy rules based on the session data associated with SQL statements.

To define the profile, you use the session filters you defined in the firewall policy.

These session filters filter SQL statements based on:

  • IP Address Set

  • DB User Set

  • OS User Set

  • DB Client Set (For example, SQL*Plus)

A profile is different from an exception, though they are both defined using the above session factors. Whereas an exception lets you bypass all the rules for SQL statements in your normal policy, a profile lets you define rules for any cluster in the SQL statements based on the session factors.

For example, you can create a profile if you want to define a completely different set of rules for SQL statements originating from a certain set of database users. When a user in this database user set accesses the database, this profile's policy rules are used instead of your normal policy rules.

A SQL statement can match more than one profile. In this case, the Database Firewall uses the most severe action, logging level, and threat severity of all matching profiles.

6.4.2 Creating a Profile

Before you can create a profile, there must be sets of factors defined to use for filtering purposes.

  1. Log in to the Audit Vault Server console as an auditor.
  2. Select the Policies tab.
  3. Select Database Firewall Policies tab in the left navigation menu.
  4. Click on the name of the specific policy.
  5. Click on Sets/Profiles button in the top right corner.
  6. Click Profiles sub tab.

    This page lists the existing profiles. You can click a profile name to edit it.

  7. Click Add to create a new profile.
  8. In the Add profile dialog, enter the following:
    • Name: Enter a name for the profile.

    • Description: Optionally enter the description.

    • IP Address Set: Select one of the available IP address sets, or leave it unselected.

    • DB User Set: From the list, select one of the available database user sets, or leave it unselected.

    • OS User Set: From the list, select one of the available operating system user sets, or leave it unselected.

    • DB Client Set: From the list, select one of the available client program sets, or leave it unselected.

    • SQL Cluster Sets: Enter a name for the SQL cluster set.

    Note:

    Client program names and OS user names are provided by the client and therefore, depending on the environment, may not be reliable.

  9. Click Save.

    The profile appears in the Profiles sub tab. You can now select this profile and set policy rules for the SQL statements. These rules will supersede your normal rules when this profile is matched.

6.4.3 Creating And Managing Database Firewall Cluster Sets

The database user can create and manage Database Firewall Cluster Sets.

The user needs to group the clusters and then define the cluster rules. Cluster Sets is a group of clusters. They are created and are part of a single Database Firewall policy. However, they cannot be used in multiple policies.

You can create a new SQL cluster set. You can delete an existing SQL cluster set from the list of sets. This deletes the definition of what constitutes the set. The rules are also deleted. However, it does not remove the event_log records that are used while creating the set.

A SQL cluster set constitutes a list of assigned SQL clusters that are related to a Database Firewall instance.

To create and manage a Database Firewall cluster set:

  1. Log in to the Audit Vault Server console as auditor.
  2. Click the Policies tab, and then Database Firewall Policies in the left navigation menu.
  3. Click Create to create a new policy.
  4. In the Create Policy dialog, enter the details in the Target Type, Policy Name, and Description fields.
  5. Click Save.
  6. A new policy is created and appears in the User-defined Policies sub tab.
  7. Click on the newly created policy.
  8. In this page, click SQL Cluster Sets sub tab.
  9. You can add a new SQL cluster set. Click Add.
  10. In the SQL Statement dialog, enter the Rule Name.
  11. Enter the rest of the fields as applicable.
  12. Click Save.
  13. You can delete the existing SQL cluster set from the list. Select the SQL cluster set and click Delete.
  14. Click on the newly created SQL cluster set. It displays the newly created cluster set.
  15. Click on Sets/Profiles button. In this page click on the tab of the specific set.
  16. Click Add to add a new cluster.

    The Add SQL Cluster Set dialog is displayed.

  17. To get the list of SQL clusters, choose the filter options in the following fields:
    • View data for

    • Target

  18. Click Go. It displays all the SQL clusters depending on the selection.
  19. Select the SQL cluster check box under the Cluster Hash column.
  20. Enter the Name and optionally Description.
  21. Click Save. A new SQL cluster is added to the cluster set and is listed in the Sets/Profiles page.
  22. To view the traffic details for the specific SQL cluster navigate back to the Sets/Profiles page. Click on the tab of the specific cluster set. Click on the name of the set.
  23. The Modify SQL Cluster Set dialog is displayed.
  24. Click on the specific SQL cluster under the Cluster Hash column.The SQL Cluster Traffic Summary dialog is displayed.
  25. To add more clusters to a specific SQL cluster set, navigate to the Modify SQL Cluster Set dialog. Select the clusters and add by clicking on the Add button. Else, you can choose to cancel it.
  26. To create a new profile, navigate to the overview page of the specific policy. Click on Sets/Profiles.
  27. Click on Add to create a new profile. Enter a profile name and select the values for the remaining fields in the dialog. Click Save. A new profile is created.
  28. To analyze the traffic within the cluster sets and profiles, navigate to the specific policy overview page. Click a specific rule name under the SQL Statement tab.
  29. Click the Add button to add or define rules for a specific profile. Enter values against the Cluster Set(s), Action, Logging Level, Threat severity, and Set threshold for escalating action fields.
  30. Click Save. The SQL Statement tab is displayed. You can edit or delete a rule.

6.5 Publishing and Deploying Firewall Policies

Learn how to publish and deploy firewall policies.

6.5.1 About Publishing and Using Firewall Policies

You can edit a firewall policy as much as you need to before publishing it.

Publishing a policy makes it available to assign to targets.

Once a firewall policy is assigned to a target, it cannot be edited. However, you can copy the policy and continue refining it under another name. Once you are happy with the new refined policy, you can publish it and assign it to targets.

6.5.2 Publishing a Database Firewall Policy

Any auditor can publish a firewall policy.

  1. Log in to the Audit Vault Server console as an auditor.
  2. Select the Policies tab.
  3. From the left navigation menu, click Database Firewall Policies.
  4. Click on the check box against the specific policy.
  5. Click Publish.

    A firewall policy publish job is started. A confirmation message is displayed on the screen.

    Check the status of the published job by clicking the Settings tab. Then click Jobs tab in the left navigation menu.

    Once the policy is published, it is available in the Database Firewall Policies tab in the left navigation menu.

6.5.3 Deploying Firewall Policies to Targets

Any auditor can deploy firewall policies to database targets.

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click Targets tab.
  3. Click Database Firewall Monitoring in the left navigation menu.
  4. Click on the name of the specific target.
  5. In the target details page, click on the Database Firewall Monitoring tab.
  6. Scroll down in this section and click the edit icon against Firewall Policy.
  7. From the drop-down list, select the policy, and then click on the check mark.