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.
Developing a policy consists of these main steps:
Create a firewall policy in the Audit Vault Server. See "Creating a New Firewall Policy".
Design your policy by setting policy actions and rules. See "Defining a Firewall Policy".
Publish the policy to make it available for applying to secured targets. See "Publishing a Firewall Policy".
Assign the policy to selected secured targets. "Deploying Firewall Policies to Secured Targets".
You can create a new firewall policy or copy an existing policy and edit it. See also "Copying a Firewall Policy".
To create a new firewall policy:
Log in to the Audit Vault Server console as an auditor, and click the Policy tab.
Under the Policy menu, click Firewall Policy.
Click Create Policy.
The Create Policy dialog appears.
Select the Database Type from the drop-down list.
Enter a Policy Name.
Optionally, enter a Description.
Click Create.
The new policy is created, and the policy's Overview page appears. Next, see:
You can copy an existing firewall policy and edit it to create a new policy. See also "Editing a Firewall Policy".
Log in to the Audit Vault Server console as an auditor, and click the Policy tab.
Under the Policy menu, click Firewall Policy.
Click the name of the policy you want to copy.
The Policy Overview page appears.
Click Copy.
Enter a Policy Name, and then click Copy.
You can edit only firewall policies that you have created or copied.
Log in to the Audit Vault Server console as an auditor, and click the Policy tab.
Under the Policy menu, click Firewall Policy.
Click the name of the policy you want to edit.
The Policy Overview page appears.
Make your edits, referring to these topics for additional information:
Click Save.
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".
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). See "Defining Policy Rules for Analyzed SQL".
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".
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. See "Defining Session Filters to Use in Profiles and Exceptions".
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.
Creating Exceptions to the default 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 criteria (such as client IP address)
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. See:
To define session filters:
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's Overview page, scroll down to the Policy Controls section, and click one of the following:
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.
Click Create New Set.
In the dialog that appears enter a New Set Name, and the first member of the set:
For IP Address and Database Client sets, enter IP addresses.
For Database Client sets, enter the client program name.
For Database User and OS User sets, enter user names.
Click Create Set.
The new set appears in the this policy control's page.
Add more members to the set by clicking the appropriate Add button for this set, for example, Add DB Client.
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. See "Defining Session Filters to Use in Profiles and Exceptions".
To create an Exception:
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.
In the Exception Rules section, select Add Exception.
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.
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.
Substitute Statement: (Optional) If you selected Block for the Threshold Action, enter a statement to substitute for the SQL matching this rule. See "Blocking SQL and Creating Substitute Statements" for advice.
(Optional) Enter a Note.
Click Create.
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.
Tip:
See also "Default Rule Settings in Relation to Other Policies".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.
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.
You can filter the list using the Actions menu. See "Working with Lists of Objects in the UI".
(Optional) Select one of the following in the Reports drop-down list:
Primary Report: Displays all SQL clusters from traffic to your secured targets. If a cluster has a defined rule, a Yes appears in the In Policy column.
SQL Statements in Policy: Displays only the SQL clusters for which you have defined rules in this policy.
Select one or more clusters, and then click Set Policy.
In the Set Policy Controls dialog, select the Action, Logging Level, and Threat Severity to apply to SQL statements of this cluster type.
(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:
Threshold: Enter the number of times a SQL statement must match this cluster before the escalation action is taken.
Threshold Action: Select Warn or Block as the action taken after the threshold is met.
Substitute Statement: (Optional) If you selected Block for the Threshold Action, enter a statement to substitute for the SQL matching this cluster. See "Blocking SQL and Creating Substitute Statements" for advice.
(Optional) Enter a Note.
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.
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.
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.
Tip:
See also, the following topics: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.
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. See "The Order of Applying Novelty Policies" for more information.
In the Novelty Policy Details dialog, define the following:
Novelty Rule: Enter a name for this rule.
Statement Classes: (Optional) Select one or more types of statements that SQL statements must match in order to apply this rule.
Policy Controls: Select the Action, Logging Level, and Threat Severity for this rule from the appropriate drop-down list.
Substitution: (Optional) This field appears if you select Block as the Action. Enter a statement to substitute for the SQL statement that was blocked. See "Blocking SQL and Creating Substitute Statements".
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 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.
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.
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.
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.
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.
In the Edit Default Rule page, assign the Action, Logging Level, and Threat Severity.
(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.
Substitution: (Optional) If you selected Block for the Threshold Action, enter a statement to substitute for the SQL matching this rule. See "Blocking SQL and Creating Substitute Statements" for advice.
Click Apply Changes.
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.
SELECT 100 FROM DUAL
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:
In order to use a Login/Logout policy for a secured target database, you must activate database response monitoring in the settings of the enforcement point monitoring that database. See Oracle Audit Vault and Database Firewall Administrator's Guide for instructions.To configure the login and logout policies:
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 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 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.
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.
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:
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 Invalid Statement Policy section, assign the Action, Logging Level, and Threat Severity.
(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:
Threshold: Enter the number of times invalid SQL must be seen before the escalation action is taken.
Threshold Action: Select Warn or Block as the action taken after the Threshold is met.
Substitution: (Optional) If you selected Block for the Threshold Action, enter a statement to substitute for the invalid SQL. See "Blocking SQL and Creating Substitute Statements" for advice.
To configure global settings for a firewall policy:
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 Global Settings section, configure the following:
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.
Under Case, select whether this firewall policy does Case sensitive matching for client program names, database user names, and/or OS user names.
Click Save in the Global Settings section.
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. see "Defining Session Filters to Use in Profiles and Exceptions".
These session filters filter SQL statements based on:
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.
In order to create a profile, there must be sets of factors defined to use for filtering purposes. See "Defining Session Filters to Use in Profiles and Exceptions".
To create 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.
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.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".
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.
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.
Once the policy is published, it is available to select in secured target pages. See "Deploying Firewall Policies to Secured Targets".
To assign a firewall policy to a secured target:
In the Audit Vault Server console, click the Secured Targets tab.
In the Targets page, click the name of the secured target you want.
In the Secured Target Details page, expand the Firewall Policy section and click Change.
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.