Question & Answer
Question
We've seen symptoms that Guardium takes some time to detect DB user name on MS SQL Server traffic. Why does it happen?
Answer
In general, Guardium captures traffic between DB client-server as configured in the inspection engine at the S-TAP side and the installed policy at the collector side. If Guardium is not able to retrieve the DB user name from the login packet ( which possible reason is that it's not included or it can't be decrypted by Guardium ), Guardium can't show the real DB user name in the report.
In the case of MS SQL server traffic the DB user name is not provided with the login packet. Rather than leaving the DB user name as blank Guardium finds a way to overcome this lack of detail by carefully parsing the captured traffic and, based on the information within the traffic, determines the DB user name by correlating it with the login packet. This can take some time to correlate leading to potential delays in detecting the DB user name.
As a result you may see the following symptoms:
- DB user name may not be resolved yet when installed policy is applied to some parsed constructs. In this case, installed policy rule may not be fired by the expected DB user name.
- It may take some time to see the real DB user name in Guardium report.
These are expected behavior in the current version of Guardium.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21700680