5 Creating Database Firewall Policies

Topics

5.1 Overview of Database Firewall Policies

Topics

5.1.1 About Firewall Policies

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.

5.1.2 The Steps of Developing a Database Firewall Policy

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 secured targets.

  4. Assign the policy to selected secured targets.

5.2 Creating a Database Firewall Policy

Topics

5.2.1 Creating a New Database Firewall Policy

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

To create a new firewall policy:

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click the Policy tab
  3. Under the Policy menu, click Database Firewall Policy.

    This page lists policies you have created, as well as those that come with Oracle Audit Vault and Database Firewall under Available Policies.

  4. Click Create Policy.

    The Create Policy dialog box appears.

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

5.2.2 Copying a Database Firewall Policy

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

To copy a firewall policy:

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click the Policy tab.
  3. Under the Policy menu, click Database Firewall Policy.
  4. Click the name of the policy you want to copy.

    The Policy Overview page appears.

  5. Click Copy.
  6. Enter a Policy Name, and then click Copy.

    From here, you can modify this copy to create a custom policy.

  7. Click Save.

5.2.3 Editing a Database Firewall Policy

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

To edit a firewall policy:

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click the Policy tab.
  3. Under the Policy menu on the left, click Database Firewall Policy.
  4. Click on the name of the policy you want to edit.

    The Policy Overview page appears.

  5. Make your edits as required and click Save.
  6. Click Modify SQL.
  7. Select the target in the Secured Target field.
  8. Change the event time as required.
  9. Click Apply.
  10. Observe the values under the column In Policy. They are SQL statements running against the targets. Pick and select the statements for the policy.
  11. Click Set Policy.

    The Set Policy Controls pop up appears.

  12. Select the Logging Level to Always. Make other changes as required.
  13. Click Save.
  14. Observe the values under the column In Policy after the changes are applied.
  15. Click on Database Firewall Policy on the left.
  16. Select the policy and navigate to the Policy Overview page to see if the changes made are reflecting.

5.2.4 Understanding a Database Firewall Policy's Overview Page

When you create a new policy, or click an existing policy name in the Firewall Policies page, that policy's Overview page appears. 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.

The policy's Overview page is divided into these sub-sections:

  • Exception Rules - 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.

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

  • Novelty Policies (Any) - Lists special policies you have created for specific statement classes and/or specific tables in your secured target databases. If you have identified specific tables in a policy in this section, the policy rule applies if it matches Any of the tables.

  • Novelty Policies (All) - Lists special policies you have created for specific statement classes and/or specific tables in your secured target databases. If you have identified specific tables in a policy in this section, the policy rule applies if it matches All of the tables.

  • Default Rule - Shows the default rule for any statements that are not matched by the rules set for Analyzed SQL clusters, Exceptions, or Novelty Policies.

  • Policy Controls - Lets you configure firewall policy settings, create policy profiles, as well as sets of filters to use in defining profiles and Exception rules.

Note:

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

5.3 Defining a Database Firewall Policy

Topics

5.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 analyzed SQL from actual traffic to your secured targets. Oracle AVDF analyzes SQL by looking at SQL traffic to any selected secured 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 "whitelist" of permissible SQL, as well as a "blacklist" of statements that are not allowed based on various criteria. Defining rules for a firewall policy includes:

  • Specifying these settings for each cluster in the analyzed SQL:

    • 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 analyzed SQL

  • Adding Novelty Policies (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 Exception Rules, and Default Rule 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.

5.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 Exception rules. For example, when defining an Exception 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:

  • 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

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 Exception rules.


To define session filters:

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

  2. Select the Policy tab.

  3. Under Policy, select Database Firewall Policy.

  4. In the Firewall Policies page, click the name of the policy you want.

    The Overview page is displayed.

  5. In the Policy Controls section, and click one of the following:

    • IP Address Sets

    • Database User Sets

    • Database Client Sets

    • OS User Sets

    • Profiles

    • Settings

    The page for the selected policy control appears. For example, Policy_Name - IP Address Sets. This page lists the sets already defined for this policy control.

  6. Click Create New Set.

  7. In the dialog that appears enter a New Set Name, and the first member of the set:

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

  8. Click Create Set.

    The new set appears in the this policy control's page.

  9. Add more members to the set by clicking the appropriate Add button for this set, for example, Add IP Address.

5.3.3 Creating an Exception

Topics

5.3.3.1 About Exception

An exception determines the action, logging level, and threat severity to use when certain session data is encountered. For example, an exception could specify rules for statements that originate (or do not originate) from selected client IP addresses or database user names.

Exceptions 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 exceptions and control the order in which they are evaluated. Each exception has its own Action, Logging, and Threat Severity settings.

In order to create an exception, you must first define the sets of session factors to be used in defining it.

5.3.3.2 Creating Exceptions

To create an exception:

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

  2. Select the Policy tab.

  3. From the Policy menu, select Database Firewall Policy.

  4. In the Firewall Policies page, click the name of the policy you want.

  5. In the Exception Rules section, select Add Exception.

  6. At the top of the Exception Rule page, select the filtering criteria for this exception:

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

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

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

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

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

  7. In the bottom section of the Exception Rule page, assign the Action, Logging Level, and Threat Severity to apply to SQL matching this rule's filtering criteria.

  8. (Optional) Select Escalate action after a certain number of instances? 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 Action: Select Warn or Block as the action taken after the Threshold is met.

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

  9. Click Create.

5.3.3.3 The Order of Applying Exceptions

Exception rules are applied in the order they are listed in the Policy Overview page. For example, if a statement matches an Exception definition in both the first and second exception rule, the Action, Logging, and Threat Severity of the first Exception is applied to that statement.

For this reason, it is more secure to have the more stringent action level in the first Exception, 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.

5.3.4 Defining Policy Rules for Analyzed SQL

Topics

5.3.4.1 About Analyzed SQL

In any firewall policy, you can see SQL from traffic to any secured targets to which you have access as an auditor. The Database Firewall analyzes SQL statements from traffic to any selected secured target and puts similar SQL statements into groups known as clusters. You can see a sample statement from each unique cluster in the Analyzed SQL section in the Policy Overview page of a firewall policy.

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

5.3.4.2 Defining Policy Rules for Analyzed SQL

To define firewall policy rules for Analyzed SQL:

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

  2. Select the Policy tab.

  3. From the Policy menu, click Database Firewall Policy, and then the name of a policy.

  4. In the Firewall Policies page, click the name of the policy you want.

  5. In the Analyzed SQL section, click Modify SQL.

    The Modify SQL page appears, with no data displayed.

  6. Click Change, select the options below, and then click Apply.

    • Profile: (Optional) Select a profile.

    • Secured Target: Select a secured target to see analyzed SQL for that target.

    • Event Time: Select time options in the available fields to filter the SQL.

    A list of SQL clusters and their details and policy status is displayed. The SQL Statement column shows a sample statement from each cluster.

    You can filter the list using the Actions menu.

  7. Select one or more clusters, and then click Set Policy.

    This lets you set a policy for the selected SQL cluster. To remove policy rules for selected SQL clusters, click Remove from Policy.

  8. In the Set Policy Controls dialog, select the Action, Logging Level, and Threat Severity to apply to SQL statements of this cluster type.

  9. (Optional) Select Escalate action after a certain number of instances? 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 Action: Select Warn or Block as the action taken after the threshold is met.

    3. Substitute Statement: (Optional) If you selected Block for the Threshold Action, enter a statement to substitute for the SQL matching this cluster.

  10. (Optional) Enter a Note.

  11. Click Save.

    The In Policy column now has a Yes for the statement(s) for which you defined this rule. In the Policy Overview page, the Analyzed SQL section keeps a count of the total number of clusters that have policy rules defined, and the associated actions.

5.3.4.3 Analyzing SQL 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 analyze SQL encrypted 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.

5.3.5 Creating a Novelty Policy

Topics

5.3.5.1 About Novelty Policies

Novelty policies specify the action, logging level, and threat severity to use for specific types of statements and/or statements that operate on selected tables. Novelty policies 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 novelty policy that applies a Pass action if this statement type operates on tables containing public information. Alternatively, you may want to set up a novelty policy that blocks all statements that operate on tables containing sensitive information.

5.3.5.2 Creating Novelty Policies

To create a novelty policy:

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

  2. Select the Policy tab.

  3. From the Policy menu, click Database Firewall Policy.

  4. In the Database Firewall Policies page, click the name of the policy you want.

    The Policy Overview page appears.

  5. Click Add Novelty Rule in either of these sections:

    • Novelty Policies (Any) - If you add a novelty rule in this section, and you select specific tables in the rule, the novelty rule applies if a statement contains Any of the selected tables.

    • Novelty Policies (All) - If you add a novelty rule in this section, and you select specific tables in the rule, the novelty rule applies if All tables in the statement are selected in the rule. (Though you may select more tables than appear in the statement.)

    The Novelty Policies (Any) rules are evaluated before the Novelty Policies (All) rules.

  6. In the Novelty Policy Details dialog, define the following:

    1. Novelty Rule: Enter a name for this rule.

    2. Statement Classes: (Optional) Select one or more types of statements that SQL statements must match in order to apply this rule.

    3. Policy Controls: Select the Action, Logging Level, and Threat Severity for this rule from the appropriate drop-down list.

    4. Substitution: (Optional) This field appears if you select Block as the Action. Enter a statement to substitute for the SQL statement that was blocked.

  7. Affected Tables: (Optional) Select the table(s) to use for matching statements to this policy. The tables are matched according the Novelty Policy section chosen in Step 5.

  8. Click Create.

    The new Novelty Policy is listed in the appropriate Novelty Policies (Any or All) section.

5.3.5.3 The Order of Applying Novelty Policies

The Database Firewall first compares statements against the Match Any Table group of Novelty Policy rules. In a Match Any Table rule, at least one of the tables in a statement must match your selected table(s) for a statement to match the rule. If a statement matches more than one of the Match Any Table rules, the more severe policy is used. For example, a policy that blocks takes priority over a policy that warns.

If statements do not match a rule under the Match Any Table group, the Database Firewall then compares statements to the rules in the Match All Tables group. In a Match All Tables rule, all of the tables in the statement must be among your selected tables. Similarly, if a statement matches more than one rule in this group, the more severe action is applied.

If you create a Novelty Policy that only matches statement classes, but not tables, then the Novelty Policy will be evaluated with either the Match Any Table or Match All Tables group, depending on which one you select when defining the policy.

5.3.5.4 Novelty Policy Examples

There are two groups of Novelty Policies in a firewall policy. They appear in the Novelty Policies (Any) and Novelty Policies (All) sections of the Policy Overview page, and are evaluated in that order.

The following are examples of how Novelty Policy rules work:

  • You create a Novelty Policy in the Novelty Policies (Any) section. The Novelty Policy rules in this section are evaluated first.

    For Statement Classes, you 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 will be evaluated with the group of novelty policy rules in this section. This group of rules is evaluated first.

  • You create a Novelty Policy in the Novelty Policies (All) section. The Novelty Policy rules in this section are evaluated second.

    For Statement Classes, you 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 will not match this rule.

5.3.6 Defining a Default Rule

Topics

5.3.6.1 About the Default Rule

The Default Rule lets you specify the Action, Logging Level, and Threat Severity for any statement that does not fall into any of your 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.

5.3.6.2 Default Rule Settings in Relation to Other Policies

If you set the action for the Default Rule to Block, setting the action of a Novelty Policy, Exception, 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.

5.3.6.3 Defining the Default Rule

To define the default rule:

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

  2. Select the Policy tab.

  3. From the Policy menu, click Database Firewall Policy.

  4. In the Database Firewall Policies page, click the name of the policy you want.

    The Policy Overview page appears.

  5. Scroll down to the Default Rule section, and click the Default Rule link.

  6. In the Edit Default Rule page, assign the Action, Logging Level, and Threat Severity.

  7. (Optional) Select Escalate action after a certain number of instances? 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 Action: Select Warn or Block as the action taken after the threshold is met.

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

  8. Click Apply Changes.

5.3.7 Blocking SQL and Creating Substitute Statements

When the Database Firewall is in DPE (or blocking) 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 secured target. This statement is harmless and does not return any values or affect performance.

    SELECT 100 FROM DUAL
    

5.3.8 Configuring Other Policy Settings

Topics

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

Note:

Prerequisites

To configure the login and logout policies:

  1. Select the Policy tab.
  2. From the Policy menu, click Database Firewall Policy.
  3. In the Database Firewall Policies page, click the name of the policy you want.

    The Policy Overview page appears.

  4. In the Policy Controls section, and click Settings.
  5. In the Login/Logout Policy section, configure the following:
    • Login Policy: Specify the Action level and Threat Severity to use for successful or unsuccessful database user logins, and whether 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.

    • Logout Policy: Specify the Action level and Threat Severity to use for successful or unsuccessful database user logouts, and whether to Enable Logging for logouts.

  6. Click Save in the Login/Logout Policy section.

5.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 Analyzed SQL 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. Select the Policy tab.

  3. From the Policy menu, click Database Firewall Policy.

  4. In the Database Firewall Policies page, click the name of the policy that you want.

    The Policy Overview page appears.

  5. Scroll down to the Policy Controls section, and click Settings.

  6. In the Sensitive Data Masking section, select or deselect the Mask input data check box.

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

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

    Having columns:

    • Choose from the list.
    • Or enter a database column name and click Add to add the name to the Having columns list.
    • Alternately, click the up arrow icon and in the Search Dialog to search for a column name and select it. Then click Add to add it to the Having columns list. Data masking is applied on the statements containing these columns.
    • To remove one or more column names, select them and then click Remove to remove 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 click Add to add the procedure name to the Having procedures list.
    • Alternately, click the up arrow icon and in the Search Dialog to search for a procedure name and select it. Then click Add to add it to the Having procedures list. Data masking is applied on statements containing the specified procedures.
    • To remove one or more procedure names, select them and then click Remove to remove them. Accordingly the SQL statements are masked.
  9. Select whether to Include invalid statements. If this is selected even the invalid SQL statements are masked.

  10. Click Save in the Sensitive Data Masking section.

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

To set policy rules for invalid SQL:

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

  2. Select the Policy tab.

  3. From the Policy menu, click Database Firewall Policy.

  4. In the Database Firewall Policies page, click the name of the policy you want.

    The Policy Overview page appears.

  5. Scroll down to the Policy Controls section, and click Settings.

  6. In the Invalid Statement Policy section, assign the Action, Logging Level, and Threat Severity.

  7. (Optional) Select Escalate action after a certain number of instances? if you want 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 Action: Select Warn or Block as the action taken after the Threshold is met.

    3. Substitution: (Optional) If you selected Block for the Threshold Action, enter a statement to substitute for the invalid SQL.

5.3.8.4 Configuring Global Database Firewall Policy Settings

To configure global settings for a firewall policy:

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

  2. Select the Policy tab.

  3. From the Policy menu, click Database Firewall Policy.

  4. In the Database Firewall Policies page, click the name of the policy you want.

    The Policy Overview page appears.

  5. Scroll down to the Policy Controls section, and click Settings.

  6. In the Global Settings section, configure the following:

    1. Under Logging, select whether to Strip binary objects and comments from log files.

    2. Under Policy, in the Threshold action reset time (minutes) field, enter a number of 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. Under Policy, enter a Threshold action reset time (minutes). In the Without substitution set block action to 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 Syntax, 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. Under Case, select whether this firewall policy does Case sensitive matching for client program names, database user names, and/or OS user names.

  7. Click Save in the Global Settings section.

5.4 Using Profiles to Customize a Database Firewall Policy

Topics

5.4.1 About Profiles

Within a firewall policy, a profile lets you define 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 Policy Controls section of the firewall policy.

These session filters filter SQL statements based on:

  • IP addresses

  • Database user login names

  • Client program names (for example, SQL*Plus)

  • Operating system user names

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 Analyzed SQL in your normal policy, a profile lets you define rules for any cluster in the Analyzed SQL based on the session factors.

For example, you can create a profile if you want to define a completely different set of rules for Analyzed SQL 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.

5.4.2 Creating a Profile

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

To create a profile:

  1. Log in to the Audit Vault Server console as an auditor.
  2. Select the Policy tab.
  3. Under Policy, select Database Firewall Policy.
  4. In the Database Firewall Policies page, click the name of the policy you want.
  5. In the Policy Controls section of the page, click Profiles.

    The Policy Profiles page appears, listing existing profiles. You can click a profile name to edit it.

  6. Click Create New Profile.
  7. In the Create Profile dialog, enter the following:
    • Profile Name: Enter a name for the profile.

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

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

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

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

    Note:

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

  8. Click Save.

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

5.5 Publishing and Deploying Firewall Policies

Topics

5.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 secured targets.

Once a firewall policy is assigned to a secured 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 secured targets.

5.5.2 Publishing a Database Firewall Policy

To publish a firewall policy:

  1. Log in to the Audit Vault Server console as an auditor.
  2. Select the Policy tab.
  3. From the Policy menu, click Database Firewall Policy.
  4. In the Database Firewall Policies page, click the name of the policy you want.
  5. Click Publish.

    A firewall policy publish job is started. You can check the status of the publish job by clicking Jobs in the Quick Links menu.

    Once the policy is published, it is available to select in secured target pages.

5.5.3 Deploying Firewall Policies to Secured Targets

To assign a firewall policy to a secured target:

  1. Log in to the Audit Vault Server console as an auditor.
  2. Click the Secured Targets tab.
  3. In the Targets page, click the name of the secured target you want.
  4. In the Secured Target Details page, expand the Firewall Policy section and click Change.
  5. From the drop-down list, select the policy you want, and then click Save.

    The new policy name appears, and on the Firewall Policy page (in the Policy tab), a Yes appears in the Deployed column for this policy.