How to Resolve S-TAP Verification Failure with 0 Failed Checks

Resolving The Problem

Standard Verification:

Checks the S-TAP and inspection engine by submitting an invalid login request to verify that the appropriate error message is returned. Upon receiving the S-TAP Verification Results pop-up, click the "Run Diagnostics" link under the Action column to confirm the basic checks have been made. If there are any errors in the checks, address the issue. By default, the system waits five seconds before displaying the verification results. High network latency can cause slow response from database server. The CLI command "store network_latency" can be issued if more time is needed to wait for response from the database server.

Network address translation between network locations where S-TAP and collector are installed will result in 0 failed checks.

Otherwise, if the result comes back with 0 Failed checks, yet the S-TAP verification still fails, the security policy configured might be the culprit behind such a failure.

During Standard S-TAP verification, the Guardium appliance issues an invalid login request with user 'resutlfd' against the database as seen in the following SLON trace:

The request is sure to fail, so the database server should send an exception of type 'LOGIN_FAILED' back to the Guardium appliance as follows:

The response of error type LOGIN_FAILED is an exception. Therefore, an entry is made in the TURBINE.GDM_EXCEPTION MySQL table. If this entry cannot be made, the standard S-TAP verification will fail. Querying this table will confirm if an entry has been made. If an entry has not been made for the standard S-TAP verification test, this is likely due to the security policy rules configured on the appliance. Check if any policy rules ignore exceptions and errors returned by the database server or skip logging such information. Editing the policy with appropriate filters or testing with an "ALLOW-ALL" policy can confirm if this is the problem.

Advanced Verification:

For this type, a datasource definition associated with the target database needs to be created. The datasource definition includes credentials, which the verification process uses to log into the database. Then it submits a request to retrieve data from a non-existent table in order to generate an error message. Upon receiving the S-TAP Verification Results pop-up, click the "Run Diagnostics" link under the Action column to confirm the basic checks have been made. If there are any errors in the checks, address the issue. By default, the system waits five seconds before displaying the verification results. High network latency can cause slow response from database server. The CLI command "store network_latency" can be issued if more time is needed to wait for response from the database server.

Network address translation between network locations where S-TAP and collector are installed will result in 0 failed checks.

Otherwise, if the result comes back with 0 Failed checks (see screenshot above), yet the S-TAP verification still fails, the security policy configured is the likely culprit behind such a failure.

During Advanced S-TAP verification, the Guardium appliance issues the following SQL statement against the database, "SELECT * FROM NON_EXISTENT_TABLE" as seen in this SLON trace: