Question & Answer
Question
What is the meaning of the most common timestamp attributes used in Guardium reports? What timestamp attribute is used in the runtime parameters of my report? What steps should I take if I think there is something wrong with the timestamp in my report?
Cause
Different timestamps with different meanings are used widely in reporting and sometimes cause confusion. Use this technote as a guide to understand:
- The meaning of commonly used timestamps
- What timestamp is used in the run time parameters for commonly used main entities
- What steps to go through if you see an unexpected timestamp in a report
Answer
Recommended viewing
Review the video in this course on the Security Learning Academy:
1. Meaning of commonly used Timestamps
| Domain* - Entity | Attribute(s) | Meaning |
| Access - Client/Server | Timestamp | The time on the collector when the client first connected to the server. For example, if a client is connecting to the server in the same way many days in a row this timestamp will be the time of the first connection. This may even be before the purge days of the appliance. |
| Access - Session | Session Start, Session End | The time on the DB server when the session started and ended. |
| Access - Session | Timestamp | The time on the collector when the session information was most recently updated. If the session is closed it will be the same time as the Session End. |
| Access - Access Period | Period Start, Period End | The time on the collector when the period, as defined by the logging granularity on the appliance (default 1 hour), started and ended. |
| Access - Access Period | Timestamp | The time on the collector when an SQL construct was executed most recently within a session and within a time period. If the same SQL construct is run 10 times within the same session and time period, it will show the time of the most recent run for all 10 SQLs. This timestamp is the most appropriate to use along with the SQL attribute in reports. |
| Access - Full SQL | Timestamp | The time on the DB server that the SQL was executed. Traffic must be captured with log full details policy action to see this timestamp. |
| Policy Violations - Policy Rule Violation | Timestamp | The time on the DB Server that the SQL triggering a policy violation was executed. Traffic must be captured with an alerting policy action to see this timestamp. |
| Exceptions - Exception | Exception Timestamp | The time on the DB Server (if exception is from monitored traffic e.g. an SQL exception on the database) or Collector (if exception is related to the collector e.g. parser error) |
2. Timestamps used in the run time parameters of reports for common main entities.
The run time parameters of a report (Start date, End Date) do not always mean the same thing. The timestamp used depends on the main entity of the report.
| Main Entity(s) of the report | Entity - Timestamp(s) used in the run time parameters |
| Client/Server | Client/Server - Timestamp |
| Session | Session - Timestamp |
| SQL | Access Period - Period Start before End Date and Access Period - Period End after Start date. Result is that any SQL in the same time period as the run time parameters will be shown in the report. |
| Command, Object, Join, Field | Access Period - Period Start before End Date and Access Period - Period End after Start date. Result is that any SQL in the same time period as the run time parameters will be shown in the report. |
| Full SQL | Full SQL - Timestamp |
| Policy Rule Violation | Policy Rule Violation - Timestamp |
| Exception | Exception - Timestamp |
3. Steps to confirm if a timestamp seen in a report is expected or not
Follow these steps if you find yourself confused about a timestamp seen in a report. For example if you see a timestamp in the report that is outside of the run time parameters.
If points 1 and 2 above do not contain details for the specific timestamp you are interested in, ask a question on the technote and it can be added to the list.
i) Find the main entity of the report. Check in the query builder if you are unsure e.g.
ii) Use point 2 in this technote to find what timestamps are used in the run time parameters for a report with that main entity.
iii) Check what timestamp attribute you are looking at in the report. If you are unsure, check in the query builder for the entity. e.g.
iv) Use point 1 in this technote to understand the meaning of the timestamps found in ii) and iii).
v) To make the situation more clear you could add the timestamp found in ii) to the report and compare that against the run time parameters. It now should match.
Following these steps should allow you to understand if there is a genuine problem with timestamps or just a misunderstanding with their definitions. If you need to open a PMR with Guardium support for a problem with timestamps in reports please attach:
- Support must_gather system_db_info
- ".sql" Export of the query with the problem (from definitions export page in the CM GUI)
- Screenshot or copy of the report highlighting the timestamps in question
Related Information
[{"Product":{"code":"SSMPHH","label":"IBM Security Guardium"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Guardium Appliances","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"10.0;10.0.1;10.1;8.2;9.0;9.1;9.5","Edition":"All Editions","Line of Business":{"code":"LOB24","label":"Security Software"}}]
Was this topic helpful?
Document Information
Modified date:
03 February 2021
UID
swg21989895