Overview of Database Firewall Policies

About Firewall Policies

Successful deployment of a Database Firewall depends on an effective policy. Oracle AVDF includes preconfigured firewall policies as described in the Firewall Policy page in the Policy tab of the Audit Vault Server console. For example, these include policies 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.

Understanding a 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 the statement types (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. See "Creating Exceptions".

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. See "Creating Novelty Policies".

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. See "Creating Novelty Policies".

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. See "Defining the Default Rule".

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 traffic to your secured targets. Oracle AVDF analyzes SQL by looking at SQL traffic to all the secured target to which you have access. It then groups the SQL into clusters of similar statements, and displays these clusters in a firewall policy in the Audit Vault Server console.

You can then define the rules of your firewall policy based on these clusters. 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.

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 criteria (such as client IP address)

Note:

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

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.

Creating Exceptions

About Exceptions

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.

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.

DBClient Set: Select to Include or Exclude, then select a database client set.

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.

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.

(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:

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

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

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.

Defining Policy Rules for Analyzed SQL

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 groups the statements into similar 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.

Defining Policy Rules for Analyzed SQL

To define firewall policy rules for Analyzed SQL:

In the Audit Vault Server console, click the Policy tab.

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

In the Analyzed SQL section, click Modify SQL.

The Modify SQL page appears, with no data displayed.

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.

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.

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 AVDF administrator must configure the Database Firewall to decrypt this traffic. See the Oracle Audit Vault and Database Firewall Administrator's Guide for information on how to do this configuration.

Creating Novelty Policies

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.

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

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

Click Create.

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

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

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. See "The Order of Applying Novelty Policies".

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.

Defining the Default Rule

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.

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.

Defining the Default Rule

To define the Default Rule:

In the Audit Vault Server console, select the Policy tab.

From the Policy menu, click Firewall Policy.

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

The Policy Overview page appears.

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

(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:

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

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

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.

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.

Configuring Other Policy Settings

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.

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 lets you produce an alert, or block a client, after a specified number of consecutive unsuccessful logins. If triggered, login blocking continues for the specified Reset period. 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.

Click Save in the Login/Logout Policy section.

Masking Sensitive Data

The Database Firewall obfuscates all passwords. In addition, you can set rules for masking other sensitive data. Sensitive data masking prevents sensitive data, such as credit card numbers, from appearing in log files. If a logged statement matches your data masking policy, the policy automatically replaces all user data in that statement (such as, string constants, integer constants, hexadecimal constants, and float constants) with alternative characters. The characters used depend on the data type.

Note:

Once sensitive data is masked, it cannot be unmasked.

To set rules for sensitive data masking:

In the Audit Vault Server console, select the Policy tab.

From the Policy menu, click Firewall Policy.

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

The Policy Overview page appears.

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

In the Sensitive Data Masking section, configure the following:

Select or deselect Mask sensitive data.

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

If you selected to mask based on criteria, enter the criteria:

Having columns: Enter the database columns.

Having procedures: Select Any or enter the procedures.

Select whether to Include invalid statements.

Click Save in the Sensitive Data Masking section.

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.

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

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.

Under Policy, 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.

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.

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.

Creating a Profile

Log in to the Audit Vault Server console as an auditor, and select the Policy tab.

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

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.

Click Create New Profile.

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.

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

Click Create Profile.

The profile appears in the Analyzed SQL section of the Policy Overview 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. See "Defining Policy Rules for Analyzed SQL".

Publishing and Deploying Firewall Policies

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.

Publishing a Firewall Policy

To publish a firewall policy:

In the Audit Vault Server console, click the Policy tab.

From the Policy menu, click Firewall Policy, and then click the name of the policy you want to publish.

Click Publish.

A firewall policy publish job is started. You can check the status of the publish job by clicking Jobs in the Settings tab.