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.
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 below) 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 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.
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 – 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.
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.
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.
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.
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:
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.
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 above).
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, to 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, to 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.
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
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.
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:
Block the request - see Blocking Actions.
Log or ignore, the violation or the traffic - see Log or Ignore Actions.
Alert - see Alerting Actions.
These actions can be used to block or stop access.
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 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:
Open - S-TAP passes requests to the database server without any delay. In this mode latency is not expected. However, if a terminate action is triggered, the triggering request usually will not be blocked, but additional requests from that session will be.
Closed (stap-firewalling mode) - S-TAP holds the database responses and waits for a verdict on each request before releasing its response. In this mode, latency is expected. However, it assures that rogue requests will be blocked.
S-GATE Policy Rule Actions are:
S-GATE ATTACH: Intended for use in open mode, this action starts inspecting and firewalling for this connection.
S-GATE DETACH: Intended for use in closed mode, this action stops firewalling for this connection. This allows traffic to pass with no delay when a connection is known to be safe.
S-GATE TERMINATE: Has effect only when the session is attached. It drops the reply of the firewalled request, which will terminate the session on some databases.
S-TAP TERMINATE: Regardless of the mode, and regardless of whether or not S-GATE is used, instructs S-TAP to terminate the database connection. The triggering request will not be blocked (except under closed mode, as described above), but this prevents additional requests from that session.
Note: For version 7.0, S-GATE actions do not support Oracle ASO encrypted traffic, or shared memory sessions for DB2 or Informix, under Linux.
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.)
Note: The Reset action cannot guarantee the prevention of any commands from executing.The command that triggers the Reset action will likely already have been executed by the database server before it receives the IP reset message from Guardium.
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:
Email messages, which must be addressed to Guardium users, and will be sent via the SMTP server configured for Guardium
SNMP traps, which will be sent to the trap community configured for the Guardium appliance
Syslog messages, which will be written to syslog.
Custom notifications, which are user-written notification handlers, implemented as Java classes.
There are several types of alert actions, each of which may be appropriate for a different type of situation.
Alert Per Match sends notifications each time the rule is satisfied. This would be appropriate for a condition requiring attention each and every time it occurs.
Alert Once Per Session sends notifications only once for each session in which the rule is matched. This action might be appropriate in situations where you want to know that a certain event has occurred, but not for every instance of that event during a single session. For example, you may want a notification sent when a certain sensitive object is updated, but if a program updates thousands of instances of that object in a single session, you almost certainly would not want thousands of notifications sent to the receivers of the alert.
Alert Per Time Granularity sends notifications once per logging granularity period. For example, if the logging granularity is set to one hour, notifications will be sent for only the first match for the rule during each hour. (The Guardium administrator sets the logging granularity on the Inspection Engine Configuration panel.)
Alert Daily sends notifications only the first time the rule is matched each day.
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.
Audit Only: Available for a Selective Audit Trail policy only. Log the construct that triggered the rule. For a Selective Audit Trail policy, no constructs are logged by default, so use this command to indicate what does get logged. When using the Application Events API, you must use this action to force the logging of database user names, if you want that information available for reporting (otherwise, in this case, the user name will be blank).
Log only: Log the policy violation only. We refer to the fact that the rule was triggered as a policy violation. Except for the Allow action, a policy violation is logged each time a rule is triggered (unless that action suppresses logging).
Log masked details: Log the full SQL for this request, replacing values with question marks (???). This action is available for access rules only.
Log full details: Log the full SQL, including values, for this request.
Log Full Details With Values: Like the above, but in addition, each value will stored as a separate element. This takes more time and space, but speeds searching and reporting tasks later.
Log Full Details Per Session: Log the full SQL (including values) for this request and for the remainder of the session
Log Full Details Per Session With Values: Like the above, but in addition, each value will stored as a separate element. This takes more time and space, but speeds searching and reporting tasks later.
Skip Logging: When matched, do not log a policy violation, and stop logging constructs. This is similar to the Allow action, but it additionally stops the logging of constructs. This action is used to eliminate the logging of constructs for requests that are known to be of no interest.
Ignore Responses Per Session: Responses for the remainder of the session will be ignored. This action logs a policy violation, but it stops analyzing responses for the remainder of the session. This action is useful in cases where you know the database response will be of no interest.
Ignore Session: The current request and the remainder of the session will be ignored. This action does log a policy violation, but it stops the logging of constructs and will not test for policy violations of any type for the remainder of the session. This action might be useful if, for example, the database includes a test region, and there is no need to apply policy rules against that region of the database.
Ignore SQL Per Session: No SQL will be logged for the remainder of the session, except when an exception occurs, in which case all exception data (including the SQL causing the exception) will be logged.
Quick Parse: For access rules only, for the remainder of the session, WHERE clauses will not be parsed. This reduces parsing time. In this mode all objects accessed can be determined (since objects appear before the WHERE clause), but the exact object instances affected will be unknown, since that is determined by the WHERE clause.
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:
No reports can be produced until the log has been processed and merged to the internal database.
By default, policy rules will not be applied until the flat log is processed and merged to the internal database. There is an option to apply policy rules to the flat log (in real time), but the types of tests that can be applied, and the types of actions that can be taken are both limited, because the message has not yet been parsed (see the Rules on Flat description, below).
To use the Log Flat option:
Mark the Log Flat box in the Policy Definition panel.
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:
Any rule that tests for a specific component of a SQL request (i.e. a command, object, field, any type of application event, object-command, object-field, or a pattern) cannot be tested until the flat log is processed.
Any rule action that logs values cannot be tested until the flat log is processed (since the values to be logged are not available until after the SQL is parsed). This includes all log full details and log masked details actions.
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:
By specifying a string that can be used to identify the traffic of interest, in the Audit Pattern box of the Policy Definition panel. This might identify a database or a group of database tables, for example.
Or by specifying Audit Only or any of the Log actions (Log Only, Log Full Details, etc.) for one or more policy rules in a Rule Definition panel. With policy rules you can be extremely precise, specifying exact values, groups or patterns to match for every conceivable type of attribute (DB Type, DB Name, User Name, etc.).
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.
When a selective audit trail policy is used, an Application User Translation is also being used:
The policy will ignore all of the traffic that does not fit the application user translation rule (for example, not from the application server).
Only the SQL that matches the pattern for that policy will be available for the special application user translation reports.
Open the Policy Finder:
Users: Protect > Security Policies > Policy builder.
Administrators: Tools > Config & Control > Policy Builder.
Click the New button to open the Policy Definition panel.
Enter a unique name for the policy in the Policy Description box. Do not include apostrophe characters in the description.
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).
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.)
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.)
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).
Optionally mark Selective Audit Trail to restrict what will be logged when this policy is installed:
When marked, only traffic requested by this policy will be logged. This is appropriate when the traffic of interest is a relatively small percentage of the traffic being seen by the inspection engines. When marked, there are two ways to signal what traffic to log: by specifying a string that can be used to identify the traffic of interest, in the Audit Pattern box; or by specifying Audit Only or any of the Log actions for one or more policy rules (rule actions are described later).
When not marked (the default situation), the Guardium appliance logs all traffic that is seen by the inspection engines. This provides comprehensive audit trail capabilities, but may result in capturing and analyzing much more information than is needed.
For more information, see Using Selective Audit Trail.
Click the Save button to save the policy definition.
Optionally click the Roles button to assign roles for the policy. See Assign Security Roles.
Optionally click the Comments button to add comments to the definition. See Commenting.
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:
Create policy rules manually. See Add or Edit Rules.
If the policy includes a baseline, have the Policy Builder suggest rules from the baseline. You can optionally accept or tailor the generated rules as necessary. See Use Suggested Rules from the Baseline.
Have the Policy Builder suggest rules from the database access control (ACL) defined for that database. You can reject, or accept and optionally tailor each rule as necessary. See Use Rules Suggested from the Database ACL.
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.
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy to be modified.
Do one of the following:
To edit overall policy settings (Category, Log Flat option, etc.) click the Modify button. To change any of these settings, see Create a Policy, above.
To edit the rules only, click the Edit Rules button. To modify and components of the rule definitions, see Add or Edit Rules, above.
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.
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy to be cloned.
Click the Clone button to open the Clone Policy panel.
Enter a unique name for the new policy in the New Name box. Do not include apostrophe characters in the name.
To clone the baseline constructs (the commands, basically) that have been generated for the baseline being cloned, mark the Clone Constructs checkbox.
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.
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy to be cloned.
Click the Remove button. You will be prompted to confirm the action.
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy to be edited.
Click the Edit Rules button to open the Policy Rules panel.
Do one of the following:
To edit a rule, click the 
Edit this
rule individually button.
To add a new rule, click one of the following buttons:
Add Access Rule
Add Exception Rule
Add Extrusion Rule (will only be available if the administrator has configured the inspection engine to examine returned data)
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:
Rule Description - Enter a short, descriptive name for the rule. To use a special pattern test, 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.
Category - The category will be logged with violations, and is used for grouping and reporting purposes. If nothing is entered, the default for the policy will be used.
Classification - Optionally enter a classification in the Classification box. Like the category (above), these are logged with exceptions and can be used for grouping and reporting purposes
Severity - Select a severity code: Info, Low, Med, or High (the default is Info).
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.
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.
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.
Login Failed A login attempt failed.
When a rule action other than Allow or S-TAP Terminate is selected, the following two fields are enabled:
Min. Ct. - Enter the minimum number of times the rule must be matched before the rule action (described below) will be triggered. The count of times the rule has been met will be reset each time the action is triggered or when the reset interval (also described below) expires. The default of zero is identical to 1, meaning that every time the rule is matched the action will be triggered.
Reset Interval (minutes) - Used only when the minimum count (Min. Ct. above) is greater than zero, and required in that case. Enter the number of minutes after which the rule counter will be reset to zero. The counter is also reset to zero each time that the rule action is triggered.
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.
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.
Select the action to take when the rule is satisfied. See Rule Actions, above.
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.
Click the Accept button to save the rule. This closes the Rule Definition panel and returns to the Policy Rules panel.
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.
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy to be viewed or modified.
Click the Edit Rules button.
In the Filter
box (upper right corner of panel):
Do one of the following:
Select a filter from the Filter list.
Click the Edit button to modify a filter definition.
Click the New button to define a new filter.
Once the filtered set of rules displays, you can perform any of the actions described in this section on the displayed 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.
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy from which you want to copy one or more rules.
Click the Edit Rules button.
Mark the checkbox for each rule to be copied.
Click the Copy Rules button.
From the Copy selected rules to policy list, select the policy to receive the copied rules.
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.
Click the Copy button. You will be informed of the success of the operation.
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.
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy to work with. (It must include a baseline.)
Click the Edit Rules button.
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.)
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.
Click the Suggest Rules button. The suggested rules display in a separate window, in the Suggested Rules panel.
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.
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.
Mark the Select box for each suggested rule to include in the policy.
Click the Accept button to accept the selected rules.
You can now edit or modify the suggested rules as you would any rules that you added manually.
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.
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.
To accept a suggest object group:
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.
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.
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:
To reject the group for this suggested rule only: Click the Reject button.
To reject the group for all suggested rules: Click the Reject for All button.
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.
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.
Click the Suggest from DB ACL button to open the Database Definition panel in a separate browser window
Click the Add Datasource button to select the database from which you want to access the DB ACL.
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.
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.
Mark the Select box for each suggested rule you want included in the policy.
Click the Accept button to accept the selected rules.
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:
Log Only
Any Alert action: Alert Daily, Alert Once Per Session, Alert Per Match, Alert Per Time Granularity
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:
Navigate to the Policy Finder:
Users, select: Protect > Security Policies > Policy Builder.
Administrators, select: Tools > Config & Control > Policy Builder.
From the Policy Description list, select the policy to work with.
Click the Edit Rules button.
Click the Policy Simulator button to open the Policy Simulator panel.
Supply both From and To dates to define the time period to use for the simulation.
Note: Historical data can be archived and purged from your Guardium appliance on a schedule defined by your Guardium administrator. Be sure that data from the time period you specify is available (and has not been purged).
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.
|
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:
|
|
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 |
|
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 |
|
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 |
|
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 |
|
Period |
To make the rule sensitive to a single time period, select a pre-defined
time period from the Period list or click the |
|
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:
|
|
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 |
|
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 |
(Period) button to define a new time period.