Saturday, April 25, 2015

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

Friday, March 20, 2015

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.

Thursday, April 17, 2014

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.

Friday, February 28, 2014

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).

Thursday, January 2, 2014

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.

Sunday, November 17, 2013

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.

Tuesday, April 16, 2013

Optim for Legacy (Non-Relational) Application Retirement Middleware Options

by Matthew Simons, ILMG Practice Lead

When you’re helping your customer archive or retire data from mainframe data sources, you’ll need to make some informed choices during the sales process to determine which mix of products will address their needs properly.  This isn’t always as straightforward as it seems, especially when Optim and the Mainframe are involved.
 
When accessing non-relational data on a z/OS platform using Optim Distributed (LUW), you must use a middleware layer on the mainframe to present this "legacy" (VSAM, IMS, SEQ) and non-relational (CA IDMS, CA Datacom) data as a relational data source.  This relational translation is what can be linked to natively supported Optim DBMSs (Oracle and DB2 LUW are the most common).  
 
When selling and implementing Optim, there are two options for this middleware component of the solution: