Topics
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.
Topics
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.
Topics
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 allowlist of permissible SQL, as well as a blocklist of statements that are not allowed based on various criteria. Defining rules for a firewall policy includes:
Specifying these settings for each cluster in 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.
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:
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
Under Policy, select Database Firewall Policy.
In the Firewall Policies page, click the name of the policy you want.
The Overview page is displayed.
In 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, enter database client 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 IP Address.
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.
To create an exception:
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
From the Policy menu, select Database 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.
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.
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.
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.
Topics
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.
To define firewall policy rules for Analyzed SQL:
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
From the Policy menu, click Database Firewall Policy, and then the name of a policy.
In the Firewall Policies page, click the name of the policy you want.
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.
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.
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.
(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 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.
Topics
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.
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
From the Policy menu, click Database Firewall Policy.
In the Database 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.
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.
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.
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.
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.
See Also:
Topics
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.
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
From the Policy menu, click Database Firewall Policy.
In the Database 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.
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.
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
Topics
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.
Log in to the Audit Vault Server console as an auditor. See Logging in to the Audit Vault Server Console for more information.
To configure the login and logout policies:
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:
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
From the Policy menu, click Database Firewall Policy.
In the Database Firewall Policies page, click the name of the policy that you want.
The Policy Overview page appears.
Scroll down to the Policy Controls section, and click Settings.
In the Sensitive Data Masking section, select or deselect the Mask input data check box.
Select either For all statements, or Only for statements matching the following criteria.
If you selected to mask based on criteria, enter the criteria as follows:
Having columns:
Having procedures:
Select whether to Include invalid statements. If this is selected even the invalid SQL statements are masked.
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:
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
From the Policy menu, click Database Firewall Policy.
In the Database 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.
To configure global settings for a firewall policy:
Log in to the Audit Vault Server console as an auditor.
Select the Policy tab.
From the Policy menu, click Database Firewall Policy.
In the Database 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, 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.
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.
Topics
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
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.
Topics
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.