Rule actions

Blocking Actions (S-TAP/S-GATE)

This section describes S-TAP® Terminate and S-GATE actions.

S-TAP Terminate Action

The S-TAP TERMINATE action will terminate a database connection (a session) and prevent additional requests on that session. This action is available in S-TAP, regardless of whether S-GATE is used or not.

S-GATE Actions

S-GATE provides database protection via S-TAP for both network and local connections.

When S-GATE is available, all database connections (sessions) are evaluated and tagged to be monitored in one of the following S-GATE modes:

• Attached (S-GATE is "on") – S-TAP is in firewalling mode for that session, it holds the database requests and waits for a verdict on each request before releasing its responses. In this mode, latency is expected. However, it assures that rogue requests will be blocked.
• Detached (S-GATE is "off") - S-TAP is in normal monitoring mode for that session, it passes requests to the database server without any delay. In this mode latency is not expected.

S-GATE configuration in the S-TAP defines the default S-GATE mode for all sessions, as well as other defaults related to S-GATE verdicts when the collector is not responding. (See Linux and UNIX systems S-TAP firewall parameters and Windows S-TAP firewall parameters.) Other than the default S-GATE configuration, S-GATE is controlled through the real-time policy mechanism using the following S-GATE Policy Rule Actions:

• S-GATE ATTACH: sets S-GATE mode to "Attached" for a specific session.
  Intended for use when a certain criteria is met that raises the need to closely watch (and if needed block) the traffic on that session.
• S-GATE DETACH: sets S-GATE mode to "Detached" for a specific session.
  Intended for use on sessions that are considered as "safe" or sessions that cannot tolerate any latency.
• 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. The S-GATE TERMINATE policy rule will cause a previously watched session to terminate.

• S-GATE/ S-TAP termination does not work on a client IP group whose members have wild-card characters. S-GATE/S-TAP termination only works with a single IP address. Wild-card should be handled by groups if the customer wants to use multiple IP entries. Customer can create groups of trusted or untrusted users/clients to handle their business needs in the policies.
• For ATAP and S-GATE, there are limitations for lower Linux kernels. Basically, for S-TAP 10.1.2 and higher, S-GATE is supported everywhere except Linux with ATAP and kernels less than 2.6.36.
• For MySQL databases, It should be noted that MySQL's default command line connection is 'mysql -u<user> -p<pass> <dbname>’

  In this mode, MySQL will first map all the objects and fields in this database to support auto completion (with TAB). When a terminate rule on any object or field that is involved in this mapping, it will immediately disable the connection session. To avoid this, connect to MySQL with the "-A" flag, which will disable the"'auto-complete" feature, and will not trigger the "terminate" rule. Another option is to fine tune the rule and not terminate on ANY access to these objects/field and instead find a criteria that is more narrow and will not trigger the rule on the login sequence.

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:

• Email messages, which must be addressed to Guardium® users, and will be sent via the SMTP server configured for Guardium. Additional receivers for real-time email notification are Invoker (the user that initiated the actual SQL command that caused the trigger of the policy) and Owner (the owner/s of the database). The Invoker and Owner are identified by retrieving user IDs (IP-based) configured via Guardium APIs. The choice Data Security User - Database Associations (available from accessmgr) displays the mapping (this is similar to what is displayed if running the Guardium API command "list_db_user_mapping").
• 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.

Message templates are used to generate alerts. Multiple Named Message Templates are created and modified from Global Profile. There are several types of alert actions, each of which may be appropriate for a different type of situation.

• Alert Daily sends notifications only the first time the rule is matched each day.
• 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 Only - For Alert Only, with type syslog, the message goes directly to /var/log/messages. For other types of Alert Only, the message will get sent to MESSAGE table. Alert Only does not notify of policy violations.

• 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 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.)

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. Access rules, exception rules and extrusion rules differ in what actions are permitted. Click on the Add Action button for offerings.

• 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 selection 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).
• Allow: When matched, do not log a policy violation. If "Allow" action is selected, no other actions can be added to the rule. Constructs are logged.
• FAM Alert and Audit - two rule actions - Alert, on a matching event, trigger an alert (using receiver and template) and Audit, log the construct that triggered the rule.
• FAM Audit only - log the construct that triggered the rule.
• FAM Ignore - Do not log this event.
• FAM Log Only Access Violations - log FAM access violations.
• 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 and extrusion rules.
• Log full details: Log the full SQL string and exact timestamp for this request. See notes in Further Discussion and Examples.
• Log full details with values: Like Log full details, but in addition, each value is stored as a separate element (parse and log the values into a separate table in the database). This log action uses more system resources as it logs the specific values of the relevant commands. Use this log action only when you need to generate reports with specific conditions on these values. Activation of this log action choice is not available without consulting Technical Services (admin user/Tools/Support Maintenance).
• Log full details per session: Log the full SQL string and exact timestamp for this request and for the remainder of the session.
• Log full details with values per session:  See the descriptions of Log full details with values and Log full details per session. Activation of this log action choice is not available without consulting Technical Services (admin user/Tools/Support Maintenance).
• 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. GDM_CONSTRUCT will be logged in some cases, because parse/log of construct occurs before the rule is applied. However, the construct will not be included in the session. This feature also applies for exception rules concerning database error code only, allowing users to not log errors when an application generates large amounts of errors and there is nothing that the user can do to stop the application errors.  
• Ignore responses per session: Responses for the remainder of the session will be ignored. This action does not log 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. This action works when sniffing data from an S-TAP. This action does not work when sniffing data from a SPAN port.
  Note: For ignore responses per session, since the sniffer does not receive any response for the query or it is ignored, then the values for COUNT_FAILED and SUCCESS are whatever the default for the table says they are, in this case COUNT_FAILED=0 and SUCCESS=1.
• Ignore session: The current request and the remainder of the session will be ignored. This action does not 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 Session rules provide the most effective method of filtering traffic. An ignore session rule will cause activity from individual sessions to be dropped by the S-TAP or completely ignored by the sniffer.  Note: connection (login/logout) information is always logged, even if the session is ignored.
• Ignore S-TAP session: The current request and the remainder of the S-TAP session will be ignored. This action is done in combination with specifying in the policy builder menu screen of certain systems, users or applications that are producing a high volume of network traffic. This action is useful in cases where you know the database response from the S-TAP session will be of no interest. Two options for Ignore S-TAP session: IGNORE_ENTIRE_STAP_SESSION - This is a "hard" ignore and can not be revoked, and IGNORE_STAP_SESSION (REVOCABLE) - This is a "soft" ignore, and this rule action can enable the session traffic to be sent again without requiring a new connection to the database. Note for ignore_stap_session (revocable) - Revoke STAP Ignore command is persistent for the S-TAP host in one sniffer process. New sessions opened after the S-TAP is in the revoked ignore state will NOT be ignored (even if the rule IGNORE STAP SESSION (REVOCABLE) is triggered. REVOKE Ignore - Sessions that were ignored by the action "IGNORE S-TAP SESSION (REVOCABLE)" will be resumed, meaning the traffic will be sent to Guardium system after "REVOKE Ignore" command received by the S-TAP. (This command can be sent from S-TAP control-->send command).
• Ignore SQL per session: No SQL will be logged for the remainder of the session. Exceptions will continue to be logged, but the system may not capture the SQL strings that correspond to the exceptions.
• Log Extrusion Counter: Available only for extrusion rules, this action updates the counter, but does not log any of the returned data. This action saves disk space when the counter value is most important and returned values are the least important.
• Log Masked Extrusion Counter: Available only for extrusion rules, this action updates the counter; logs the SQL request, replacing values with question marks; does not log the returned data (response).
• Quarantine: Available for access, exception and extrusion rules, the purpose of this action is to prevent the same user from logging into the same server for a certain period of time. There is one validation item: you cannot have a rule with a QUARANTINE action without having filled in a value for amount of time that the user is quarantined. See Quarantine for (minutes) to set this quarantine time. If the session is watched (S-GATE scenario), send a drop verdict. If the session is not watched (S-TAP TERMINATE scenario), have the S-TAP stop the session. Take the current time and add to that the number of minutes from the reset interval field. You get a new timestamp. In a new structure you keep a sorted list (sorted by this timestamp). Each element has in addition to the timestamp, a server IP, server type, a DB user name, a service name and a flag saying whether this was a watched session or not.
• No Parse - Do not parse the SQL statement.
• Quick Parse No Fields - Do not parse fields in the SQL statement. All quick parse rules are only applied if SQL string is greater than 100 characters.
• Quick Parse Native - This is used only for Guardium S-TAP for DB2 on z/OS. Use this rule action in an environment where heavy traffic is overloading the Sniffer. Use of this rule action should improve performance in the S-TAP for DB2 on z/OS.
• Quick Parse: For access rules only, for the remainder of the session, Do not parse the SQL statement. 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.
• Redact: For extrusion rules only, this feature allows a customer to mask portions of database query output (for example, credit card numbers) in reports for certain users. The selection Replacement Character in the Data Pattern section of the extrusion rule menu choices defines the masking character. Should the output produced by the extrusion rule match the regular expression of the Data Pattern, the portions that match sub-expressions between parenthesis "(" and ")" will be replaced by the masking character. Predefined regular expressions (fast regexp) can also be used. See Data Pattern in Rule definition fields for more information.
  Restriction:

  • Redaction does not work on open sessions after an S-TAP live upgrade.
  • Redaction does not work on tables created with field and number type.
  • SQL Pattern is not supported for redaction rules.
• Record Values Separately/ Do Not Record Values Separately: This action is a session-based access rule. Used in Replay function to distinguish between transactions.
• Mark as Auto-Commit ON/ Mark as Auto-Commit OFF: This action is a session-based access rule. Used in Replay function due to various auto-commit models for different databases.
• z/OS Audit: Used specifically for z/OS Collection Profile policy rules (IMS, Data Sets, and DB2), which are used to specify which traffic to collect on the z/OS server. This action specifies that traffic that meets the filtering criteria is sent to the collector, and it is the only action that can be specified on a Collection Profile rule.

For HTTP support, there are Policy action limitations. The following policy actions are not supported for HTTP: S-TAP terminate and Skip logging.

For policy conditions - these conditions are not supported for HTTP:

Client MAC; DB Name; DB User; App User; OS User; Src App; Masking Pattern; Replacement Character; Quarantine for minutes; Records Affected Threshold; XML Pattern; Event Type; Event User Name; App Event Values Text; App Event Values Text Group; App Evert Values Text and Group; Numeric; Date.

Further discussion and examples

Log Full Details

By default the Guardium collector masks all values when logging an SQL string. For example

insert into tableA (name,ssn,ccn) values ('Bob Jones', '429-29-2921','29249449494949494')

is logged as insert into tableA (name,ssn,ccn) values (?, ?,?). This is the default behavior for two reasons:

1. Values should not be logged by default because they may contain sensitive information.
2. Logging without values can provide for increased system performance and longer data retention within the appliance. Very often, database traffic consists of many SQL requests, identical in everything except for their values, repeated hundreds, thousands, or even millions of times per hour. By masking the values, Guardium is able to aggregate these repeated SQL requests into a single request, called a "construct". When constructs are logged, instead of each individual SQL request/construct being logged separately, it is only logged once per hour (per session) with a counter of how many times the construct was executed. This can save a tremendous amount of disk space because, instead of creating a hundreds (or millions) of lines in the database, only one new line is added.

With Log Full Details, Guardium logs the data with the values unmasked and each separate request. Log Full Details also provides the exact timestamp whereas logging without details provides the most recent timestamp of a construct within the logging granularity time period (usually 1-hour).

Ignore S-TAP Session - Ignore S-TAP Session causes the collector to send a signal to the S-TAP instructing it to stop sending all traffic, except for the logout notification, for specific sessions. For example, if you have a rule that says where DBUserName?=scott, Ignore S-TAP Session:

• When Scott logs into the database server, S-TAP sends the connection information to the collector.
• The collector logs the connection. Session information (log in/log outs) are always logged.
• The collector sends a signal to S-TAP to stop sending any more traffic from this specific session. This means that any commands run by Scott against the database server and any responses (result sets, SQL errors, etc.) sent by the Database server to Scott will be discarded by S-TAP and will never reach the collector.
• When Scott logs out of the database server, S-TAP will send this information to the collector (log in/log out information is always tracked even if the session is ignored).
• When Scott logs in again, these steps are repeated. The logic on which sessions should be ignored is maintained by the collector, not the S-TAP.

It is important to note that Ignore Session rules are still very important to include in the policy even if using a Selective Audit Trail. Ignore Session rules decrease the load on a collector considerably because by filtering the information at the S-TAP level, the collector never receives it and does not have to consume resources analyzing traffic that will not ultimately be logged. A Selective Audit Trail policy with no Ignore Session rules would mean that all traffic would be sent from the database server to the collector, causing the collector to analyze every command and result set generated by the database server.

Using MS-SQL or Sybase batch statements in Guardium application

Limitation

The success or failure of SQL commands in MS-SQL or Sybase batch statements may not show correctly.

MS-SQL or Sybase SQL batch statements are primarily used when creating complex procedures.

When executing SQL statements separately, the status of each statement is tracked separately and will have the correct success or failure value.

When a batch of SQL statements (used in MS-SQL or Sybase) are executed together, the status returned is the single status of the last transaction in the batch.

Guardium example

[Start of SQL batch]

SQL 1 statement - failed

SQL 2 statement - failed

SQL 3 statement - success

[End of SQL batch]

In the Guardium application, only the success or failure of the last SQL statement is reported in a MS-SQL or Sybase batch statement. In this case, success is reported for the MS-SQL or Sybase batch statement, even though SQL 1 and SQL 2 failed.

Set character set

You can use an action under a policy extrusion rule in order to attach alternative character sets to the session.

Special Pattern Rules with character sets

Example of extrusion rule (with hint):

Character set EUC-JP (code 274).

Extrusion rule pattern: guardium://char_set?hint=274

As a result an extrusion rule is attached to the session and Analyzer will use EUC-JP in the session, if there is no other character set.

Example of extrusion rule (with force) :

Character set EUC-JP (code 274).

Extrusion rule pattern: guardium://char_set?force=274

As a result an extrusion rule us attached to the session and Analyzer will use EUC-JP character set in the session in any case. Character set used before will be substituted by EUC-JP.

Keep in mind that extrusion rules usually attach to the session with some delay. Therefore short sessions or the beginning of the session are not immediately changed by a character set change. The schema works for: Oracle, Sybase, MY SQL, and MS SQL.

Analyzer rules

Certain rules can be applied at the analyzer level. Examples of analyzer rules are: user-defined character sets, source program changes, and issuing watch verdicts for firewall mode. In previous releases, policies and rules were applied at the end of request processing on the logging state. In some cases, this meant a delay in decisions based on these rules. Rules applied at the analyzer level means decisions can be made at an earlier stage.

Log Flat

The Log Flat option listed in Policy Definition of Policy Builder 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 merging of that data to Guardium's internal database can be done later, either on a collector or an aggregator unit.

There are two Guardium features involving the Flat Log Process - Flat Log by policy definition and Flat Log by throttling mechanism.

Flat Log by throttling mechanism - This is the feature implemented by running the CLI command, store alp_throttle 1. The same policy that is applicable to real-time S-TAP traffic is used to process traffic that was logged into the GDM_FLAT_LOG table.

For Flat Log by throttling mechanism, the Flat Log checkbox should NOT be checked in Policy Builder.

Flat Log by policy definition - Selection of this feature involves the Policy Builder menu in Setup >Tools and Views and Flat Log Process menu in Manage > Activity Monitoring.

The following actions do not work with rules on flat policies: LOG FULL DETAILS; LOG FULL DETAILS PER SESSION; LOG FULL DETAILS VALUES; LOG FULL DETAILS VALUES PER SESSION; LOG MASKED DETAILS.

Rules on Flat

This section describes the differences on uses of Rules on Flat.

When Rules on flat is checked:

• Session-Level rules will be examined in real-time.
• No rules will be evaluated when the offline processing does takes place.

When Rules on flat is NOT checked:

• Policy rules will fire at processing time using the current installed policy.

The following actions do not work with rules on flat policies: LOG_FULL_DETAILS; LOG_FULL_DETAILS_PER_SESSION; LOG_FULL_DETAILS_VALUES; LOG_FULL_DETAILS_VALUES_PER_SESSION; LOG_MASKED_DETAILS.

Using Selective Audit Trail

Use the Selective Audit Trail option, in the Policy Definition section of Policy Builder, 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. Note that an audit pattern is a pattern that is applied (via regular expression matching) to EACH SQL that the logger processes to see if it matches. This pattern match is strictly a string match. It does NOT match against the session variables (DB name, etc) the way the policy rules do.
• 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.).

If the Guardium security policy has Selective Audit Trail enabled, and a rule has been created on a group of objects, the string on each element in the group is checked. If there is a match, a decision is made to log the information and continue. If the Guardium security policy has Selective Audit Trail enabled, and a rule has been created on a group of objects using a NOT designation on the object group, there is still a need to check the string on each element in the group, and decide to log and continue only if none of the elements match. NOT designated rules behave the same as normal rules when used with Selective Audit Trail.

This includes:

• OR situations such as rules based on multiple objects or commands;
• Situations with two NOT conditions (for example, NOT part of a group of objects and NOT part of a group of commands); and,
• Situations with one NOT condition and one YES condition (for example, a NOT part of a group of objects and a YES part of a group of commands).

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 Identify Users via API 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:

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

Selective Audit Trail and specifying an empty group

An empty tuple group attached to a rule will NOT cause a rule action to match.