Policies

A security policy contains an ordered set of rules to be applied to the observed traffic between database clients and servers. Each rule can apply to a request from a client, or to a response from a server. Multiple policies can be defined and multiple policies can be installed on a Guardium® appliance at the same time.

Each rule in a policy defines a conditional action. The condition tested can be a simple test - for example it might check for any access from a client IP address that does not belong to an Authorized Client IPs group. Or the condition tested can be a complex test that considers multiple message and session attributes (database user, source program, command type, time of day, etc.), and it can be sensitive to the number of times the condition is met within a specified timeframe.

The action triggered by the rule can be a notification action (e-mail to one or more recipients, for example), a blocking action (the client session might be disconnected), or the event might simply be logged as a policy violation. Custom actions can be developed to perform any tasks necessary for conditions that may be unique to a given environment or application. For a complete list of actions, see Rule Actions Overview.

A policy violation is logged each time that an alert or log-only action is triggered. Optionally, the SQL that triggered the rule (including data values) can be recorded with the policy violation. Policy violations can be assigned to incidents, either automatically by a process, or manually by authorized users (see the Incident Management tab in the Guardium GUI. For further information, see Incident Management.

Note: Correlation alerts can also be written to the policy violations domain (see Correlation Alerts).

In addition to logging violations, policy rules can affect the logging of client traffic, which is logged as constructs and construct instances.

Constructs are basically prototypes of requests that Guardium detects in the traffic. The combinations of commands, objects and fields included in a construct can be very complex, but each construct basically represents a very specific type of access request. The detection and logging of new constructs begins when the inspection engine starts, and by default continues (except as described) regardless of any security policy rules.
Each instance of a construct detected in the traffic is also logged, and each instance is related to a specific client-server session. No SQL is stored for a construct instance, except when a policy rule requests the logging of SQL for that instance, or for a particular client/server session of instances (with or without values).

In addition to controlling the inclusion of SQL in client construct instances, a security policy rule can disable the logging of constructs and instances for the remainder of a session.

In heavy volume situations, the parsing and aggregating of information into constructs and instances can be deferred by using the Log Flat (Flat Log) option. When used, the production of alerts and reports will be delayed until the logged information has been aggregated. See Log Flat discussed later in this topic.

To completely control the client traffic that is logged, a policy can be defined as a selective audit trail policy. In that type of policy, audit-only rules and an optional pattern identify all of the client traffic to be logged. See Use Selective Audit Trail discussed later in this topic.

In addition to installing new policies from Policy Installer screen of Administration Console/Policy Installation:

A new policy can be installed from Policy Finder screen.
From the Policy Definition screen, an installed policy can be reinstalled, without reinstalling other installed policies.
From Policy Rules screen, an installed policy rule can be reinstalled, without reinstalling the entire policy.

On a new installation only (not on upgrades), a default policy exists. It has no rules, but Selective Audit is checked (this means that the Guardium system will not collect any traffic per the default policy). The default policy on 64-bit Guardium (new installation) is Default - Ignore Data Activity for Unknown Connections.

Policy Rule Basics

Within a policy, rules are evaluated in the order in which they appear, as each element of traffic is analyzed.

There are three types of rules:

An access rule applies to client requests - for example, it might test for UPDATE commands issued from a specific group of IP addresses.
An exception rule evaluates exceptions returned by the server (responses) - for example, it might test for five login failures within one minute.
An extrusion rule evaluates data returned by the server (in response to requests) - for example, it might test the returned data for numeric patterns that could be social security or credit card numbers.

Category, Classification, and Severity

For each rule, an optional Category and/or Classification can be assigned. These are used to group policy violations for both reporting and incident management.

Minimum Counts and Reset Intervals

Some activities are normal and acceptable when they occur less than a certain rate. But those same activities may require attention when the rate exceeds a tolerable threshold. For example, if interactive database access is allowed, a consistent but relatively low rate of login failures might be expected, whereas a sharply higher rate might indicate an attack is in progress.

To deal with thresholds, a minimum count and a reset interval can be specified for each policy rule. This can be used, for example, to trigger the rule action after the count of login failures exceeds 100 (the minimum count) within one minute (the reset interval). If omitted, the default is to execute the rule action each time the rule is satisfied.

Continue to Next Rule

By default, the evaluation of access and exception rules for a unit of traffic ends when a rule is triggered, providing that there is not multiple actions in one rule. In cases where it is necessary to take multiple actions for the same or similar conditions, mark the Continue to Next Rule box for that rule.

Note: Continue to Next Rule applies to access rules following access rules and to exception rules following exception rules, but not to an exception rule following an access rule or an access rule following an exception rule.

Extrusion rules will be processed regardless of the end of an access or exception rule preceding the extrusion rule. See extrusion rules revoke in the Rule Definitions Reference table at the end of this topic for information on excluding logging a response that has already been selected for logging by a previous rule in the policy.

Record Values with Policy Violation

When marked, the actual construct causing the rule to be satisfied will be logged in the SQL String attribute and is available in reports. If not marked, no SQL statement will be logged. To include the full values in the policy violation, mark the Rec. Vals box for that rule.

Note: The full SQL with values will be available only in the policy violation record, within the policy violations reporting domain. It will not be available in the client traffic log, or on reports from the data access domain. To include full SQL (with or without data values) in the client traffic log, use the Log Full SQL rule actions.

For more information about working with rules, see the following topics:

View the Policy Rules for the Installed Policy
Specify Values and/or Groups of Values in Rules
Filter Rules to Display only a Subset
Copy Rules
Using Rules Suggested from the Database ACL.
Add or Edit Rules
Using the Policy Simulator

Specify Values and/or Groups of Values in Rules

For many rule attributes, you can specify a single value and/or a group value, using controls like those illustrated for the App User.

Be aware that a group member may contain wildcard (%) characters, so each member of a group may match multiple actual values.

When a Group is selected, be aware that the group may contain wildcards.

Negative Rule: Mark the Not box to create a negative rule; for example, not the specified App User, or not any member of the selected group, or neither the specified App User nor any member of the selected group.
Empty Value: Enter the special value guardium://empty to test for an empty value in the traffic. This is allowed only in the following fields: DB Name, DB User, App User, OS User, Src App, Event Type, Event User Name, and App Event Text.
To define a new group to be tested: Click the Groups button to define a new group, and then select that group from the Group list.
To match any value: Leave the value box blank, and select nothing from the Group list (be sure that the line of dashes is selected, as in the example).
To match a specific value only: Enter that value in the value box, and select nothing from the Group list.
To match any member of a group: Leave the value box blank, and select the group from the list. If the minimum count is greater than 1, there will be a single counter, and it will be incremented each time any member of the group is matched.
To match an individual value or any member of a group: Enter a specific value in the value box, and select a group from the list. If the minimum count is greater than 1, there will be a single counter, and it will be incremented each time the individual value or any member of the group is matched.
If the minimum count is greater than 1, count each individual value separately: Enter a dot (.) in the value box, and select nothing from the group list. Note that the dot option cannot be used for the Service Name or Net Protocol boxes. If the minimum count is greater than 1, count each member of a group separately: Enter a dot (.) in the value box, and select a group from the list. Note that the dot option cannot be used for the Service Name or Net Protocol boxes.

Pattern matching using Regular Expressions

In addition to special pattern tests, regular expressions can be used to search traffic for complex patterns in the data. The Guardium implementation of regular expressions conforms with POSIX 1003.2, which differs from the UNIX implementation of regular expressions. Regular expressions are allowed in any field that is followed by the Build Regular Expression button.

Note: You can also use regular expressions in the following fields (DB user, App User, SRC App, Field name, Object, App Event Values Text) by typing the special value guardium://regexp/(regular expression) in the text box that corresponds to the field.

Note: IBM Security Guardium does not support regular expressions for non-English languages.

For detailed information about how to use regular expressions, see Regular Expressions.