Logging or ignoring rule actions

Logging actions control the level of logging based on the observed traffic.

Access rules, exception rules, and extrusion rules differ in which actions are available. For example, Log and Ignore actions are available for most policies, but the Audit Only action is only available for policies that use the Selective Audit Trail setting.

Audit Only

This action is only available for policies that use the Selective Audit Trail setting.

Audit Only logs the construct that triggered the rule. For a Selective Audit Trail policy, no constructs are logged by default, so use this selection to indicate which constructs you want to log. For example, for the Application Events API, if you want to log database usernames for reporting, use this action (otherwise, in this example, the username is blank).

Allow

When matched, log the matching construct but do not log a policy violation. If the Allow action is selected, no other actions can be added to the rule.

Log Only

Log the policy violation. Except for the Allow action, a policy violation is logged each time that a rule is triggered unless the rule action suppresses logging.

Log Masked Details

This action is available for access rules and extrusion rules.

Log the full SQL for the request, replacing values with question marks (?).

Log Full Details

Log the full SQL string and exact timestamp for the request.

Log Full Details with Values

Like Log Full Details, but each value is stored as a separate element such that the values are parsed and logged in to 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.

Attention: This log action is unavailable without consulting Technical Services.

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 for Log Full Details with Values and Log Full Details per Session.

Attention: This log action is unavailable without consulting Technical Services.

Skip Logging

When matched, do not log a policy violation and stop logging constructs. This is similar to the Allow action, but it also 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. This feature also applies for exception rules that concern database error codes only, allowing users to not log errors when an application generates a large and unavoidable quantity of errors.

Note: GDM_CONSTRUCT is logged in some cases because parsing and logging of the construct occurs before the rule is applied, but the construct is included in the session.

Ignore Responses per Session

Responses for the remainder of the session are ignored. This action does not log a policy violation, but it stops analyzing responses for the remainder of the session. This behavior is useful in cases where you know that the database response is of no interest. This action works when sniffing data from an S-TAP, but it 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, the values for COUNT_FAILED and SUCCESS are the default. In this case, the values are COUNT_FAILED=0 and SUCCESS=1.

Ignore Session

The current request and the remainder of the session are ignored. This action does not log a policy violation, but it stops the logging of constructs and does not test for policy violations of any type for the remainder of the session. This action might be useful if the database includes a test region and you do not need to apply policy rules against that region of the database. An ignore session rule action causes activity from individual sessions to be dropped by the S-TAP or completely ignored by the sniffer.  

Important: Connection (login and 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 are ignored. This action is done in combination with specifying specific 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 is of no interest.

• If no SQL is recorded for a session, then the "Ignore S-TAP Session" NEVER fires - and hence the "Session:Session Ignored" flag is recorded as No.
• If a session has 1 or more SQL statements, then the "Session:Session Ignored" flag recorded as Yes.

Use Ignore S-TAP Session as follows:

• IGNORE S-TAP SESSION: A "hard" ignore that cannot be revoked.
• IGNORE STAP SESSION (REVOCABLE): A"soft" ignore; this rule action can enable the session traffic to be sent again without requiring a new connection to the database.
• REVOKE Ignore - Sessions that were ignored by the action IGNORE_S-TAP_SESSION (REVOCABLE) are resumed, meaning that traffic is sent to the Guardium system after the REVOKE Ignore command is received by the S-TAP. This command is sent from the S-TAP Control page using the Revoke All Ignored Sessions button.
  Note: The Revoke Ignore command persists for the S-TAP host in one sniffer process. New sessions opened after the S-TAP is in the revoked ignore state are not ignored even if the rule IGNORE_STAP_SESSION (REVOCABLE) is triggered.

Ignore SQL per Session

Do not log SQL for the remainder of the session. Exceptions are still logged, but the system might not capture the SQL strings that correspond to the exceptions.

Log Extrusion Counter

This action is only available for extrusion rules.

Update the counter but do not log any of the returned data. This action saves disk space when the counter value is more important than the returned values.

Log Masked Extrusion Counter

This action is only available for extrusion rules.

Update the counter and log the SQL request, replacing values with question marks (?). This action does not log the returned values.

Quarantine

This action is available for access, exception, and extrusion rules.

Prevent the same user from logging into the same server for a specified time period. To use the Quarantine rule action, you must also specify a duration for the quarantine with the Quarantine for (minutes) setting. If the session is watched (S-GATE), the action sends a drop verdict. If the session is not watched (S-TAP Terminate), the action has the S-TAP stop the session.

Quarantine timestamps are calculated by taking the current time and adding the number of minutes from the reset interval field. The new timestamp is kept in a structure (sorted by timestamp) along with server IP, server type, DB user name, service name, and a flag that indicates whether the session is watched.

No Parse

Do not parse the SQL statement.

Quick Parse

This action is for access rules.

Do not parse the SQL statement for the remainder of the session. This action reduces parsing time. In this mode, all objects that are accessed can be determined (since objects appear before the WHERE clause), but the exact object instances are unknown (since that is determined by the WHERE clause).

Note:

If you are using the universal connector, this action is only available for plug-ins that delegate the language syntax parsing to Guardium Data Protection. These cases usually occur when Guardium Data Protection supports that language natively. This action is not available if you are using a plug-in that parsed the language syntax by itself and does not delegate the syntax parsing to Guardium Data Protection.

Quick Parse No Fields

Do not parse fields in the SQL statement. Quick parse rules are only applied if SQL string is greater than 100 characters.

Quick Parse Native

This action is used only for Guardium S-TAP for DB2 on z/OS.

Use this rule action to improve performance in an environment where heavy traffic is overloading the Guardium sniffer.

Redact

This action is for extrusion rules.

Mask portions of database query output in reports for certain users, for example credit card numbers. The masking character is defined by the Replacement character of the Data pattern parameter of the extrusion rule. If output produced by the extrusion rule matches the regular expression of the Data pattern, the portions that match subexpressions between parenthesis ( and ) are replaced by the masking character. Predefined regular expressions can also be used. For more information, see Data Pattern in Rule definition fields.

Restriction:

• Redaction does not work on open sessions after an S-TAP live upgrade.
• Redaction does not work on tables that are created with field and number type.
• Redaction is available only with unencrypted traffic.
• Redaction is supported only with ANSI character sets.
• The following restrictions apply only to regular (non-session-level) policies:
  • SQL Pattern is not supported for redaction rules.
  • Set redaction rules on the session level (attributes like IP addresses or users) and not on the SQL level (attributes like OBJECT_NAME or VERB). If you set redaction rules on the SQL that needs to be scrubbed, it can take a few milliseconds for the scrub instructions to reach the S-TAP. In this case, some results might go though unmasked.

    To guarantee that all SQL is redacted, set the S-TAP's default S-GATE mode to "attach" for all sessions that use the guard_tap.ini file. This step guarantees that no command goes through without being inspected by the rules engine, which holds each request and wait for the policy's verdict on the request. This deployment introduces some latency but ensures 100% scrubbed data.

    For the Informix database, when char is used as a data type, there is no null termination at the end of each column. All four columns are captured in the sendmsg system call as one piece, and K-TAP always tries to redact whatever data it captures. This behavior is a limitation when you use redaction with Informix.

• For more information about issues with redact, see the troubleshooting tips under Policies.

Record Values Separately

Do Not Record Values Separately

This action is a session-based access rule. Used in replay functions 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

This action is used only for data sets, Db2, and IMS collection profile policy rules that specify which traffic to collect on a z/OS server.

Traffic that meets the filtering criteria is sent to the collector. It is the only action that can be specified on a collection profile rule.