Guardium V10 - Micro Tips #1 - RHEL 6

by John Haldeman, Practice Lead

Everyone by now knows that Guardium V10 has been released. It's an exciting release with a lot of features. I expect to see a lot presented and written on the big features like the new UI, file activity monitoring, query rewrite, and new vulnerability assessment data sources, etc. in the next few months. What I want to take some time to do on this blog is talk about the little features that might not get a lot of attention but can make a difference in the everyday lives of Guardium administrators and practitioners like me. I'll be calling those Micro Tips, and this is the first one.

Since I have just finished deploying a virtual machine in my lab environment for V10, let's talk about the operating system and virtualization (btw, if you want a step by step guide for the installation of Guardium V10 and some things that have changed since V9, this blog post is a great resource. One particularly nice thing is that the imaging process is now completely unattended - no waiting to enter passwords half way through the install process. That is a great decision.)

Guardium V10 got an upgrade in it's OS from RHEL 5 to RHEL 6 (RHEL 6.5 to be exact). Since you never really get to touch the underlying operating system, this might be transparent and not matter to you. That being said, it does actually make a difference for some using VMWare deployments using newer types of virtual adapters. If you want to use paravirtual SCSI adapaters (as described here) and VMXNET3 type virtual network adapters (as described here), you should now be able to do that a lot more easily. Those drivers were included in RHEL6, but not RHEL5 by default.

Note, in the case of VMXNET3 adapters, you could enable them in the past with some awkward additional steps, but now since it is running on RHEL6, it *should* come packaged with a VMXNET3 driver and work out the gate.

Note that I have not confirmed this - my current lab environment doesn't have those options. Theoretically the Guradium organization could have taken the drivers out, but I don't see why they would. I will try and confirm they are in there and update this post.

Querying Live Guardium Data with Cognos (Without the CSV Exports)

by John Haldeman, Security Practice Lead

This post is all about how to configure Cognos to query Guardium DAM data directly on the appliance. That is without exporting the data to CSV first and then loading it into a database that Cognos can access. How it works is by using a web service that accesses the Guardium REST API and then exposes the resulting Guardium data in an XML format that Cognos accepts. Cognos queries the web service and displays the data.

Architecture for Querying Guardium Data Directly from Cognos

Adding ISPIM Session Recording Information to Guardium DAM to Gain Additional Information on Local Sessions

by John Haldeman, Security Practice Lead

One of the things that Guardium Database Activity Monitoring does best is monitor privileged users such as a DBA accessing a database. That being said, there are some situations where additional information can be brought in from other sources to provide even more information on the nature of the access. This post is about pulling in additional identity and session recording information from IBM Security Privileged Identity Manager to provide additional context for a database administrator's session.

Sending Data in Guardium to an External Database Using the External Feed

by John Haldeman, Security Practice Lead

Guardium has the capabilities to send data to external databases. Traditionally this is done through CSV exports of the data where an audit process are set up to create CSV files which are moved off the appliance using the results export functionality of the Administration Console.

There was another method of exporting data that, until recently, was not available for most customers to use directly. This method is where Guardium creates a connection to an external database and inserts the results from a report directly into that database. External feeds work by mapping column names from the Guardium database to another database. This used to be a manual process of accessing the Guardium MySQL database directly and creating that mapping. That process required root access, which means you needed support to help you do it.

Installing Optim Manager on CentOS

by Matt Simons, Practice Lead

I was setting up a new CentOS machine the other day in our lab to use as an Optim 9.1 Server (now, CentOS is not an officially supported operating system for running the Optim Server components - its true - but we use it in our lab environments since its the closest thing to Red Hat Enterprise Linux) and I hit upon an issue.  See, all of the components (Runtime Services, WebSphere, Optim Manager, Optim Connection Manager) work fine except for the process of installing the WAS-CE instance as a daemon (I hate having to remember to start things every time).

Type 1 Guardium STAP for Guardium/Vormetric Data Encryption

by John Haldeman, Security Practice Lead

Today we open sourced a custom STAP for integrating Guardium Database Activity Monitoring and Guardium/Vormetric Data Encryption. This custom STAP can be found at the following GitHub repository:
https://github.com/johnhaldeman/GuardDETap

Guardium Database Activity Monitoring (Guardium DAM) and Guardium/Vormetric Data Encryption (Guardium/Vormetric DE) do a great job of working together to help audit and control the access to sensitive data in databases. This custom STAP receives syslog events sent from Guardium/Vormetric DE agents, translates those messages into the Guardium Universal Feed protocol, and transmits the data to a Guardium DAM collector for reporting and alerting.

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.