Policies

Policy Overview

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, but only a single policy is installed on a Guardium appliance at any point in 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.

A policy violation is logged each time that a rule is triggered (except when the rule explicitly requests no logging). 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 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.

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 Flat Log option. When used, the production of alerts and reports will be delayed until the logged information has been aggregated. See Use Log Flat.

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.

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:

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 below 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 rules for a unit of traffic ends when a rule is triggered. 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.

Record Values with Policy Violation

By default, when policy violations are logged, the SQL causing the violation is recorded with the violation, but the SQL values are masked (replaced with question marks). 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, described below.

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

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

Special Pattern Tests to Detect Sensitive Data

In some cases it is necessary to scan the actual data contained in the SQL traffic, looking for a recognizable pattern such as a social security number, indicating that sensitive data may be exposed. Guardium provides a set of special pattern tests (described below) for this purpose.

Each policy rule can include a single special pattern test. To use one, begin the rule name with one of the special pattern test names described below. All other components of the rule (selecting specific client and server IP addresses, for example) still can be specified.

If a match is found, keep in mind that these tests only match a character pattern, and that fact alone does not guarantee that the suspected item (a Social Security number, for example) has been encountered. There can be false positives under a variety of circumstances, especially if longer sequences of numeric values are concatenated in the data.

Special Pattern Tests

guardium://CREDIT_CARD

Detects two credit card number patterns. It tests for a string of 16 digits or for four sets of four digits, with each set separated by a blank. For example:

1111222233334444

or

1111 2222 3333 4444

For both patterns, this test also checks that the digits are a correct credit card number using the Luhn Algorithm.

guardium://PCI_TRACK_DATA

Detects two patterns of magnetic stripe data. The first pattern consists of a semi-colon (;), 16 digits, an equal sign (=), 20 digits, and a question mark (?). For example:

;1111222233334444=11112222333344445555?

The second pattern consists of a percent sign (%), the character B, 16 digits, a carat (^), a variable-length character string terminated by a forward slash (/), a second variable-length character string terminated by a carat (^), 31 digits, and a question mark (?). For example:

%B1111222233334444^xxx/xxxx x^1111222233334444555566667777888?

guardium://SSEC_NUMBER

Detects numbers in Social Security number format: three digits, dash (-), two digits, dash (-), four digits. The dashes are required. For example:

123-45-6789

Pattern Matching Using Regular Expressions

In addition to the special pattern tests described above, 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. For detailed information about how to use regular expressions, see Regular Expressions.

Rule Actions

There are a number of factors to consider when selecting the action to be taken when a rule is satisfied. Depending on the situation, you may want to perform one or more of the following general actions:

Blocking Actions

These actions can be used to block or stop access.

Drop and Terminate Actions

Drop and Terminate are available only when the Guardium appliance is operating in firewall mode. For both of these actions, the client message is blocked – it will not be forwarded to its destination. For a Terminate action, the client will be sent a reply indicating that the session has been terminated. For a Drop action, the session will appear to hang (from the client’s perspective). In either case, the SQL included in the request, including all data values, will be logged in the policy violation.

Although the two actions are similar, we suggest that you use Terminate rather than Drop, to eliminate the delay associated with the Drop.  

Notes: The Drop and Terminate actions cannot block messages received from S-TAP, since S-TAP only reports on traffic that is outside of the Guardium database firewall. For any firewall to be effective, the actual traffic must pass through it.

These actions do not prevent a client from reconnecting to the server. Many applications attempt to reconnect automatically following either action.

S-GATE Actions

S-GATE is a separately licensed option that provides database protection via S-TAP for both network and local connections. For Guardium version 7.0, all S-GATE actions (S-GATE ATTACH, S-GATE DETACH, and S-GATE TERMINATE) are available on Unix database servers only. The S-TAP Terminate action is available on both Unix and Windows database servers.

S-GATE has two activity modes:

S-GATE Policy Rule Actions are:

Reset Action

The Reset action sends an IP reset message to the server, which disconnects the session. This action is provided for use where the more powerful Drop and Terminate actions are not available – for example, on Guardium servers with no firewall, or for messages relayed from S-TAPs (which are outside of the firewall). When using Reset, you must be aware of the limitations. (See the notes below.)

Alerting Actions

Alert actions send notifications to one or more recipients. For each alert action, multiple notifications can be sent, and the notifications can be a combination of one or more of the following notification types:

There are several types of alert actions, each of which may be appropriate for a different type of situation.

Log or Ignore Actions

These actions control the level of logging, based on the observed traffic. The Log and Ignore commands are generally always available, but the Audit Only action is only available for a Selective Audit Trail policy.

Use Log Flat

The Log Flat option allows the Guardium appliance to log information without immediately parsing it. This saves processing resources, so that a heavier traffic volume can be handled. The parsing and amalgamation of that data to Guardium’s internal database can be done later, either on a collector or an aggregator unit.

When Log Flat is marked:

To use the Log Flat option:

  1. Mark the Log Flat box in the Policy Definition panel.

  2. Optionally mark the Rules On Flat box to test policy rules against the flat log. Since the SQL has not been parsed at this point, not all rules, and not all actions can be performed. This means that:

Use Selective Audit Trail

Use a Selective Audit Trail policy to limit the amount of logging on the Guardium appliance. This is appropriate when the traffic of interest is a relatively small percentage of the traffic being accepted by the inspection engines, or when all of the traffic you might ever want to report upon can be completely identified.

Without a selective audit trail policy, the Guardium appliance logs all traffic that is accepted by the inspection engines. Each inspection engine on the appliance or on an S-TAP is configured to monitor a specific database protocol (Oracle, for example) on one or more ports. In addition, the inspection engine can be configured to accept traffic from subsets of client/server connections. This tends to capture more information than a selective audit trail policy, but it may cause the Guardium appliance to process and store much more information than is needed to satisfy your security and regulatory requirements.

When a selective audit trail policy is installed, only the traffic requested by the policy will be logged, and there are two ways to identify that traffic:

Selective Audit Trail and Application Events API

When a selective audit trail policy is used, and application users or events are being set via the Application Events API, the policy must include an Audit Only rule that fires whenever a set/clear application event, or set/clear application user command is encountered. See the Guardium Administrator Guide for information about setting the application user via the Application Events API.

Selective Audit Trail and Application User Translation

When a selective audit trail policy is used, an Application User Translation is also being used:

Create a Policy

  1. Open the Policy Finder:

  2. Click the New button to open the Policy Definition panel.

  3. Enter a unique name for the policy in the Policy Description box. Do not include apostrophe characters in the description.

  4. Optional. Enter a category in the Category box. A category is an arbitrary label that can be used to group policy violations for reporting purposes. The category specified here will be used as the default category for each rule (and it can be overridden in the rule definition).

  5. Optional. Select a baseline to use from the Policy Baseline list. Be sure that the baseline selected has been generated. If it has not been generated, the Policy Builder will not be able to suggest rules from that baseline.

    Note
    : If the baseline you want to use does not display in the list, your Guardium user ID has not been assigned a security role authorized to use that baseline. Contact your Guardium Administrator for further information.

    If the policy includes a baseline, the policy definition will initially contain only the baseline, and the action for a baseline is always allow without continuing to the next rule.

    When adding a baseline to an existing policy, it will be added as the first rule. You can move the baseline rule to any location in the policy. (As the last rule, it will have no effect.)

  6. Optionally mark Log Flat to indicate that Guardium is to log data, but not analyze and aggregate the data to the internal database. No queries can be run against the data until the flat log is processed. (The administrator schedules the processing of flat logs.)

  7. If Log Flat is selected, optionally mark Rules on Flat to apply the policy rules to the flat log data (as opposed to the aggregated data).

  8. Optionally mark Selective Audit Trail to restrict what will be logged when this policy is installed:

  9. Click the Save button to save the policy definition.

  10. Optionally click the Roles button to assign roles for the policy. See Assign Security Roles.

  11. Optionally click the Comments button to add comments to the definition. See Commenting.

Where to Go from Here

After creating a new policy definition, use the Policy Finder panel to access that definition. Complete the policy definition by performing one or more of the following tasks:

Modify a Policy

Caution: Before modifying a policy definition, be sure that you understand the implications of modifying a policy that is in use. If the existing policy has to be re-installed before all revisions have been completed, the policy may not install, or it may not produce the desired results when installed. For this reason, it is preferable to clone the policy, so that the original is always available to reinstall. See Clone a Policy, below, for more information on cloning a policy.

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy to be modified.

  3. Do one of the following:

Clone a Policy

There are a number of situations where you may want to define a new policy based on an existing one, without modifying the original definition. See the caution in the Modify a Policy topic, above.

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy to be cloned.

  3. Click the Clone button to open the Clone Policy panel.

  4. Enter a unique name for the new policy in the New Name box. Do not include apostrophe characters in the name.

  5. To clone the baseline constructs (the commands, basically) that have been generated for the baseline being cloned, mark the Clone Constructs checkbox.

  6. Click the Accept button to save the new policy. You can then open and edit the new policy via the Policy Finder. See Modify a Policy, above.

Remove a Policy

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy to be cloned.

  3. Click the Remove button. You will be prompted to confirm the action.

Add or Edit Rules

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy to be edited.

  3. Click the Edit Rules button to open the Policy Rules panel.

  4. Do one of the following:

  5. The attributes that can be tested for in each type of rule vary, but regardless of the rule type, each rule definition begins with the following four items:

  6. Use the remaining fields of the Rule Definition panel to specify how to match the rule. Many of the same fields are available for Access, Exception, and Extrusion Rules; and some fields are available only after selecting various other options. For an alphabetical reference of all fields available in the rules definition panels, see Rule Definition Reference, below. Also, for instructions on how to use combinations of groups and individual values, see Specify Values and/or Groups of Values in Rules, above.

  7. For each type of rule, you can enter one or more regular expressions in a Pattern box, to match against strings in the traffic. Enter the expression manually, or click the RE button to open the Build Regular Expression tool, which allows you to enter and test regular expressions. See Regular Expressions in the Common Tools book for more information about using regular expressions.

  8. For exception rules only, select a single exception type to which the rule will be sensitive, from the Exception Type box. The rule count will be incremented only when the selected exception type is encountered.

  9.  Login Failed A login attempt failed.

  10. When a rule action other than Allow or S-TAP Terminate is selected, the following two fields are enabled:

  11. Mark the Continue to next Rule box to indicate that when this rule is satisfied and its action is triggered, testing of the same request, exception, or results should continue with the next rule. This means that multiple rules may be satisfied and multiple actions taken based on a single request or exception. If not marked (the default), no additional rules will be tested when this rule is satisfied.

  12. Mark the Rec. Vals. box to indicate that when the rule action is triggered, the complete SQL statement causing that event will be logged and available in the policy violation report (but not anyplace else where the SQL is available). If not marked, the SQL String attribute will be empty. This box will be cleared and disabled whenever either the Allow, Audit Only, or Skip Logging action is selected; it will be marked automatically whenever any of the Alert actions, Log only, or Reset is selected; and it will be cleared automatically any of the “Log Full…” actions or the “Ignore… ” actions are selected.

  13. Select the action to take when the rule is satisfied. See Rule Actions, above.

  14. If an alert action is specified, the Notification pane opens, and at least one notification type must be defined. For instructions on how to add notifications, see Notifications, in the Common Tools book.

  15. Click the Accept button to save the rule. This closes the Rule Definition panel and returns to the Policy Rules panel.

Filter Rules to Display Only a Subset

When a policy contains many rules, it can be useful to view a subset of the rules having common attributes. The Filter box in the Rules Definition panel can be used for this purpose. The process of defining a filter is similar to the process of defining a rule. See Specify Values and/or Groups of Values in Rules, above.

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy to be viewed or modified.

  3. Click the Edit Rules button.

  4. In the Filter box (upper right corner of panel):



    Do one of the following:

Once the filtered set of rules displays, you can perform any of the actions described in this section on the displayed rules.

Copy Rules

Use this procedure to copy selected rules from one policy to another, or to a different location in the same policy.

All of the rules copied will be copied to a single location - after rule 3, for example. To copy rules to different locations in the receiving policy, either perform multiple copy operations, or copy all of the rules in one operation, and then edit the receiving policy to move the rules as necessary.

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy from which you want to copy one or more rules.

  3. Click the Edit Rules button.

  4. Mark the checkbox for each rule to be copied.

  5. Click the Copy Rules button.

  6. From the Copy selected rules to policy list, select the policy to receive the copied rules.

  7. From the Insert after rule list, select the rule after which the copied rules should be inserted, or select Top to insert the copied rules at the top of the policy.

  8. Click the Copy button. You will be informed of the success of the operation.

  9. You should now edit the policy to which you copied the rules, to verify that you have copied the correct rules to the correct location.

Use Rules Suggested from the Baseline

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy to work with. (It must include a baseline.)

  3. Click the Edit Rules button.

  4. Set the Rule minimum count value. This is the minimum number of like commands that the system should find in order to suggest a rule. The default is zero. The smaller the number entered, the more suggested rules the system will generate. (Be aware that the Count that displays in the suggested rules panel does not reflect this value.)

  5. Set the Object Group minimum count value, to determine how many instances of an object group the system should find to generate a suggested object group. The default is one. The smaller the number entered here, the greater the number of suggested object groups.

  6. Click the Suggest Rules button. The suggested rules display in a separate window, in the Suggested Rules panel.

  7. The suggested rules are sorted in descending order by the count of occurrences in the baseline period, which is listed on the right side of the title bar for each suggested rule. If you select one or more of the suggested rules and click Accept, they are inserted in the same order, just above the BASELINE rule in the Policy Rules panel. You can then change the order of the suggested rules or edit them as necessary, from the Policy Rules panel.

  8. Expand the rules and check the membership of the suggested object groups. In the Object column of the Suggested Rules panel, if any suggested object groups have been created, these begin with the name Suggested Object Group and display as hypertext links (in blue and underlined). For information about how to view, accept, or reject suggested object groups, see Using Suggested Object Groups, below.

  9. Mark the Select box for each suggested rule to include in the policy.

  10. Click the Accept button to accept the selected rules.

  11. You can now edit or modify the suggested rules as you would any rules that you added manually.

Using Suggested Object Groups

The Policy Builder can suggest rules from both the baseline included in the policy and the database security policy (internal to the DBMS) defined for a server. In either case, it attempts to generate the minimal set of rules by grouping database objects (tables, procedures, or views) into suggested object groups. You can accept or reject the suggested object groups, as described below.

Before accepting a suggested object group, you can edit the generated Group Description field (Suggested Object Group603-25 11:54, for example) to provide a more meaningful name. After accepting a suggested object group, you can view its membership. You can reject the use of that group within any suggested rule, but you cannot edit the membership of that group.

If you reject a suggested object group, the suggested rule for that group is replaced with a separate suggested rule for each member of the rejected group. You can accept or reject each of those suggested rules separately. After accepting a suggested rule, you can edit that rule.

Viewing Suggested Object Groups

Suggested object groups display in the Object column of the Suggested Rules panel as hypertext links beginning with the words Suggested Object Group.

To view a suggested object group’s membership, click the hypertext link for that group. If the group has not yet been accepted, the group membership displays in the Edit Group panel. If the group has already been accepted, it displays in the View Group panel.

Accepting Suggested Object Groups

To accept a suggest object group:

  1. Enter a meaningful name in the Group Description field in the Edit Group panel. (Not required, but strongly recommended). Do not include apostrophe characters in the name. This is the only opportunity you have to name this group. Otherwise, the group gets a name beginning with Suggested Object Group and followed by a number, as described previously.

  2. Click the Accept button to accept the edited group for the suggested rule, or click the Accept for All button to accept the edited group for all suggested rules in which it appears. The new object name will replace the old one in the rule.

Rejecting Suggested Object Groups

When you reject a suggested object group, the use of that group is replaced by one or more suggested rules. To reject a suggested object group, do one of the following:

Note: If you accept a suggested object group in one rule, open that same suggested object group again from another rule, and then click the Reject for All button, that group will be retained in any rule where it was explicitly accepted, but rejected in the remaining rules in which it was used.

Use Rules Suggested from the Database ACL

For a specified database server, the Policy Builder can suggest access rules using the security policy defined internally by the DBMS. The Policy Builder does this by examining the permissions granted to user groups and database objects (tables, procedures, and views) within the DBMS, then grouping the database objects into suggested object groups so that the total number of suggested rules can be minimized. You can accept or reject any suggested object group (as described above - see Using Suggested Object Groups). You can also accept or reject any suggested rule.

To have the Policy Builder suggest rules from the database ACL:

Note: When suggesting rules from the database ACL, the system does not use the Rule minimum count or the Object Group minimum count. fields. Those fields are used only when suggesting rules from the baseline.

  1. Click the Suggest from DB ACL button to open the Database Definition panel in a separate browser window

  2. Click the Add Datasource button to select the database from which you want to access the DB ACL.

  3. Click the Suggest Rules button to generate the rules. The Suggested Rules panel opens in a separate window (as described previously, for the Rules Suggested from Baseline). If you select one or more of the suggested rules and click Accept, they will be inserted in the same order into the list of rules in the Policy Rules panel, just above the BASELINE rule. If there is no BASELINE rule, they will be inserted at the top of the list. Once the suggested rules have been inserted into the Policy Rules panel, you can change the order of the rules or edit them, as necessary.

  4. Check the membership of the suggested object groups. In the Object column, any suggested object groups that have been created begin with the name Suggested Object Group and display as hypertext links (in blue and underlined). For information about how to view, edit, accept, or reject suggested object groups, see Using Suggested Object Groups), above.

  5. Mark the Select box for each suggested rule you want included in the policy.

  6. Click the Accept button to accept the selected rules.

Use the Policy Simulator

Use the Policy Simulator to test access rules without installing the policy. It does not test exception rules or extrusion rules. The simulator replays logged network traffic and applies all access rules in the policy. It produces a special report in a separate window, listing the SQL that triggered alert or log only actions. The report includes the following columns: Timestamp, Category Name, Access Rule Description, Client IP, Server IP, DB User Name, Full SQL String, Severity Description, and Count of Policy Rule Violations.

The Policy Simulator can be used to test only the following types of access rule actions:

The Policy Simulator will not produce any results if the policy includes logging actions other than Log Only. To use the simulator for such a policy, temporarily change all logging actions to Log Only.

To use the Policy Simulator:

  1. Navigate to the Policy Finder:

  2. From the Policy Description list, select the policy to work with.

  3. Click the Edit Rules button.

  4. Click the Policy Simulator button to open the Policy Simulator panel.

  5. Supply both From and To dates to define the time period to use for the simulation.  

  6. Click the Test button. When the test starts and while it is running, the message * is running displays in the Policy Simulator panel. When the test completes, a special report opens in a separate window listing all rule matches that were logged. If no alert or log only rules were triggered, you will receive a "No Drill Down Report Available" message. In the latter case, you may not have included enough data in the test period.

Rule Definition Reference

Field

Description

Action

Indicates the action to be taken when the rule is true. For a comprehensive description of all rule actions, see Rule Actions, above.

App Event Exists

Match for an application event only. See the App Event Note, below.

App Event Values

Match the specified application event Text, Numeric, or Date values. See the App Event Note, below.

(App) Event Type

Match the specified application event. See the App Event Note, below.

(App) Event User Name

Match the specified application event user name only. See the App Event Note, below.

App Event Note

The above App Event fields cannot be used when the Flat Log box (see above) is marked.

App. User

Application User. See Specify Values and/or Groups of Values in Rules.

Audit Plan

For an IBM DB2 Z/OS DB Type only, mark this checkbox to indicate that the transaction information, including the Plan Name (see below), should be monitored.

Category

An arbitrary label that can be used to group policy violations for reporting purposes. A default category can be specified in the policy definition, but the default can be overridden for each rule.

Classification

An arbitrary label that can be used to group policy violations for reporting purposes. A default classification can be specified in the policy definition, but the default can be overridden for each rule.

Client IP

Clear the Not box to include, or mark the Not box to exclude:

  • Any client: Leave all client fields blank. The count will be incremented every time any client satisfies the rule. (You cannot leave all fields blank if the Not box is marked.)

  • All clients selected by an IP address and mask: Enter a client IP address in the first box and network mask in the second box. The count will be incremented each time that any of the specified clients satisfies the rule. For example, to select all clients in subnet 192.168.9.x, enter 192.168.9.1 in the first box and 255.255.255.0 in the second box. For more information selecting IP addresses, see Selecting IP Addresses Using a Mask.

  • A group of clients: Select a group of client IP addresses from the Group drop-down list, or click the (Groups) button to define a new group and then select that group. The count will be incremented each time that any member of the selected group satisfies the rule.

  • All clients selected by an IP address and mask AND a group of clients: Use both the Client IP and Group fields, as described above. The count will be incremented each time that any client specified using either method satisfies the rule.

Client MAC

To make the rule sensitive to a single client MAC address, enter the address in nn:nn:nn:nn:nn:nn format, where each n is a hexadecimal digit (0-F).

    OR

Enter a dot (.) in the Client MAC box to indicate that a separate count should be maintained for each client MAC address.

    OR

Leave the Client MAC box empty to ignore client MAC addresses.

Command

The command. See Specify Values and/or Groups of Values in Rules, except for an IBM DB2 Z/OS DB Type, in which case a commands group cannot be edited, and the "and/or Group" label changes to "Collect Only," indicating that commands from only the selected group are to be selected.

Continue to next Rule

If marked, rule testing will continue with the next rule, regardless of whether or not this rule is satisfied. This means that multiple rules may be satisfied (and multiple actions taken) by a single SQL statement or exception. If not marked (the default), no additional rules will be tested for the current transaction when this rule is satisfied.

Creator.Object

For an IBM DB2 Z/OS DB Type only, the creator of the object.

Data Pattern

A regular expression to be matched, in the Pattern box. You can enter a regular expression manually, or click the (Regex) button to open the Build Regular Expression tool, which allows you to enter and test regular expressions.

DB Name

The database name. See Specify Values and/or Groups of Values in Rules.

DB Type

The database type: CIFS, DB2, FTP IBM DB2 Z/OS, IMS, Informix, MS SQL SERVER, MYSQL, Oracle, Sybase, or TERADATA. Depending on the selection made here, other fields may appear (or become hidden) on the panel.

DB User

The database user. See Specify Values and/or Groups of Values in Rules.

DBRM/Package Pattern

A regular expression to be matched, in the Pattern box. You can enter a regular expression manually, or click the (Regex) button to open the Build Regular Expression tool, which allows you to enter and test regular expressions.

Error Code

The error code (for an exception). See Specify Values and/or Groups of Values in Rules.

Exception Type

The type of exception (selected from the list).

Field Name

The field name. See Specify Values and/or Groups of Values in Rules.

Job Name

For an IBM DB2 Z/OS DB Type only, the job name.

Masking Pattern

A regular expression to be matched, in the Pattern box. You can enter a regular expression manually, or click the (Regex) button to open the Build Regular Expression tool, which allows you to enter and test regular expressions.

Min. Ct.

The minimum number of times the condition contained in the rule must be matched before the rule will be satisfied (subject to the Reset interval, below).

MVS System

For an IBM DB2 Z/OS DB Type only, identifies the MVS system.

Net. Protocol

The network protocol. See Specify Values and/or Groups of Values in Rules.

Object

The object name. See Specify Values and/or Groups of Values in Rules.

Object/Command Group

Match a member of the selected Object/Command group.

Object/Field Group

Match a member of the selected Object/Field group.

OS User

Operating system user. See Specify Values and/or Groups of Values in Rules.

Pattern

A regular expression to be matched, in the Pattern box. You can enter a regular expression manually, or click the (Regex) button to open the Build Regular Expression tool, which allows you to enter and test regular expressions.

Period

To make the rule sensitive to a single time period, select a pre-defined time period from the Period list or click the (Period) button to define a new time period.

Plan Name

For an IBM DB2 Z/OS DB Type only, the plan name that should be matched.  It can only be matched if Audit Plan (above) is marked.

Rec. Vals.

When marked, the actual construct causing the rule to be satisfied will be logged, and available in reports, in the SQL String attribute. If not marked, no SQL statements will be logged.

Reset Interval

Used only if the Min. Ct. field (above) is greater than zero. This value is the number of minutes after which the condition met counter will be reset to zero.

Revoke

This checkbox appears on extrusion rules only. It allows you to exclude from logging a response that has already been selected for logging by a previous rule in the policy. In most cases you can accomplish the same result more simply by defining a single rule with one or more "not" conditions to exclude the responses you do not want, while logging the remaining ones that satisfy the rule. (The Revoke checkbox pre-dates "not" conditions, and is provided mainly for backward compatibility to support existing policies.)

Rule n Description

The name of the rule. To use a special pattern test in the rule, enter the special pattern test name followed by a space and one or more additional characters to make the rule name unique, for example: guardium://SSEC_NUMBER employee. (See Special Pattern Tests, above, for more information.)

When displayed, the name will be prefaced with the rule number and the label Access Rule, Exception Rule, or Extrusion Rule, to identify the rule type. If the rule was generated using the Suggest Rules (from a baseline) function or the Suggest From DB ACL function, the generated name is in the form: Suggested Rule<n>_mm-dd hh:mm, consisting of the following components:

n A sequence number for the generated rule

mm-dd The month and day the rule was generated

hh:mm The time the rule was generated

Server IP

Clear the Not box to include, or mark the Not box to exclude:

  • Any server: Leave all server fields blank. The count will be incremented every time any server satisfies the rule. (You cannot leave all fields blank if the Not box is marked.)

  • All servers selected by an IP address and mask: Enter a server IP address in the first box, and network mask in the second box. The count will be incremented each time that any of the specified servers satisfies the rule. For example, to select all servers in subnet 192.168.3.x, enter 192.168.3.1 in the first box, and 255.255.255.0 in the second box.

  • A group of servers: Select a group of server IP addresses from the Group drop-down list or click the (Groups) button to define a new group and then select that group. The count will be incremented each time that any member of the specified group satisfies the rule.

  • All servers selected by an IP address and mask AND a group of servers: Use both the Server IP and Group fields, as described above. The count will be incremented each time that any server specified using either method satisfies the rule.

Service Name

The service name. See Specify Values and/or Groups of Values in Rules.

Severity

Select a severity code from the list: INFO, LOW, MED or HIGH. If HIGH is selected and email alerts are sent by this rule, the email will be flagged Urgent.

SQL Pattern

A regular expression to be matched, in the Pattern box. You can enter a regular expression manually, or click the (Regex) button to open the Build Regular Expression tool, which allows you to enter and test regular expressions.

Src App.

Application source program. See Specify Values and/or Groups of Values in Rules.

SSID/Group Name

For an IBM DB2 Z/OS DB Type only, the SSID or group for which constructs are to be logged. Sessions of other instances will be logged (including access and session information), but the constructs for all other instances will be ignored.

User ID/SQL ID

For an IBM DB2 Z/OS DB Type only, the User ID or SQL ID.

XML Pattern

A regular expression to be matched, in the Pattern box. You can enter a regular expression manually, or click the (Regex) button to open the Build Regular Expression tool, which allows you to enter and test regular expressions.