Three Basic Reports in Guardium That Always Seem to Be Reused

by John Haldeman, Security Practice Lead

Guardium has extensive reporting capabilities. You can build a variety of reports to view the data in a lot of different ways. That being said, after working with Guardium for some time you may notice that there are a few reports that get reused over and over again as the basis for other reports. The columns in these reports hardly change. Instead the criteria are refined after they are cloned.

I contend that there are really three report definitions in Guardium that can provide the basis for 80% of the reports that customers require. As such, I tend to create those base reports first so that I can reuse their definitions over and over again. If you are starting out in Guardium you might find these useful. If you have three base reports that you know work, you won't have to struggle building them from scratch which includes picking the correct main entity for the report and only including fields that make sense.



All of these reports are for the "Access Tracking" domain. That is the set of tables in Guardium that track SQL statement execution. Guardium has lots of other domains as well (eg: the Exceptions Tracking domain which tracks database errors), but most of the reports customers care about are from Access Tracking.

Basis Report 1: The Session Level Report

This is the first report I end up building is a report on session data. It normally comes first because this report can be very helpful in confirming you are receiving traffic from the STAPs. Here is what it looks like:

Definition for Session Level Report

Output of the Session Level Report

If you think about it, you can tie this back to logging levels. Guardium always logs session data no matter what policy you define. Session data logging ties to the "Sessions" main entity. That's the main entity for this first basis report. The rest of the basis reports are going to relate directly to a logging level and a main entity as well. It is no coincidence that I define three basis reports and that there are three levels of logging in Guardium. From here you would clone and define parameters on session level information. For example, you could create a report of all logins using application users that are not from application servers.

Basis Report 2: The Full SQL Report

The next basis report displays data at one of the finest grained levels of detail that Guardium provides. An example of where this could be used is for reporting on DBA activities.

Definition for Full SQL Report

Output for the Full SQL Report

The logging level that this report ties to is "Log Full Details". That is it will only be able to display data where you have a rule in your policy with the action of Log Full Details. The main entity that this report relates to is the Full SQL main entity. From here you would clone and define parameters on any information to do with the activity. For example, you could create a report of all DML performed by administrators on financial objects.

Basis Report  3: Object/Command Report

The final report that I reuse over and over again is that which shows the SQL Verb (or the command) executed against a specific database object (like a table). I use this quite often if Full SQL reports generate too much information to be useful or consumable, or if the requirement is to track application sessions (where logging Full SQL would be very expensive).

Definition for Object/Command Report

Output for Object/Command report

The logging level that this report ties to is construct logging. That is you would only be able to display data with this report where you have a rule in your policy with the action of AUDIT ONLY for selective audit trails, or ALLOW/No Rule for non-selective audit trails.  This logging level ties to a lot of possible main entities, but if you're going to build this particular report, the main entity would have to be OBJECT. From here you would again clone and define appropriate filtering parameters.

Other Notable Reports

As mentioned earlier, I find that these reports, or ones very similar to them, account for about 80% of the reports that get used in Guardium. So, the question then becomes what about the other 20%? Here are a couple notable examples of reports that often get used but don't fit the three definitions outlined above:

1. Reports on other domains: All of the reports above use the "Data Access" domain. Normally there is at least one report on database errors which applies to the Exceptions domain. Additionally, if you're using Guardium for other functions (entitlement reports, vulnerability assessments, CAS, etc.) you will probably build reports on the domains of those other functions
2. One User - One IP reports. This is often created to try and determine if there is widespread abuse of a particular database account. It shows how many IP addresses are associated with a particular database account. This is an example of a report that relates to the Data Access domain but does not fit the format of the three reports defined above