Log full details

With log full details, Guardium logs data for each separate request and with unmasked values. Log full details also provides exact timestamps.

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).
Important: When using log full details, if the inspection engine is not configured with inspect returned data enabled, the success or failure of SQL statement is not updated correctly. For more information about configuring inspection engines to inspect returned data, see Inspection Engine Configuration.

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

There is a limitation where 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. However, 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.

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