QRadar and Guardium integration

QRadar and Guardium can work together in a two-way information flow to have the Guardium data protection policies updated automatically and nearly in real-time in response to security intelligence events from QRadar.

IBM QRadar is a security intelligence tool that provides threat protection by monitoring security information and events, using customizable rules to detect anomalies, as well as providing tools for incident forensics and vulnerability management.

IBM Guardium is a solution for data security and data privacy that helps ensure the integrity of data stored in servers. Guardium uses policies and inclusion/exclusion lists (called Guardium groups) to control access to data.

The QRadar and Guardium solution leverages the QRTrigger framework for triggering actions in response to QRadar security events. Based on configuration settings, QRadar events will cause new members to be added to Guardium groups based on information carried in the event itself. Furthermore the Guardium policy associated with the group is automatically reinstalled so that membership change takes effect immediately.

Note that the QRadar and Guardium solution can be used to update a single Guardium collector, or a group of them being controlled by a Guardium Central Manager (CM).

QRadar and Guardium together

Traditional QRadar and Guardium integration is a one-way information flow where Guardium sends alerts and Vulnerability Assessment (VA) reports to QRadar.

Common alerting use cases for databases:

  • Failed logins

  • Unauthorized access

  • SQL Error codes (for example, SQL injection attacks)

  • Users trying to escalate their privileges

  • Users creating triggers and views to indirectly access sensitive data

Now QRadar and Guardium can work together in a two-way information flow.

Additional use cases:

  • Block access from a machine that became compromised

  • Increase audit levels for access by a user ID that became suspicious

  • Increase audit levels for access by a privileged shared user ID that was on-boarded in a Privileged Identity Management (PIM) system

Updating Guardium policies based on QRadar events

The steps to deploying the QRadar and Guardium solution are:

  1. Install the solution files.

  2. Set up a client ID and secret in Guardium.

  3. Configure a Forwarding Destination in QRadar.

  4. Configure Rules to dispatch QRadar Events to the solution.

  5. If necessary, define Guardium Groups and Policies for integration.

Note that Guardium version 10.1 and later has three predefined groups designed to support this integration:

  • QRadarBlockingConnection

  • QRadarAlertingConnection

  • QRadarLogConnection

Each of these groups has the following tuple structure:

<Client IP>,<Src App>,<DB User>,<Server IP>,<Svc. Name>,<OS User>,<DB Name>

There is a predefined Guardium policy called "QRadarPolicy" with three rules: A blocking rule, an alerting rule, and a logging rule. Each rule is tied to its respective group from the list above.

Setting up Guardium

In order for the QRadar and Guardium solution to be able to authenticate to the Guardium REST API, a client ID must be registered in Guardium and the associated client secret retrieved.

Registering a client ID is done using the grdapi command line utility of Guardium. This operation is performed only once. The result of the client ID registration is a JSON entry containing details for the new client, including the client secret.

> grdapi register_oauth_client client_id=qrguardium
ID=0
{"client_id":"qrguardium","client_secret":"3ac89782-ce55-
4f24-b795-b6c76ecc4045",
"grant_types":"password","scope":"read,write","redirect_uri"
:"https://joeApp"}
ok

Troubleshooting logs

The QRadar and Guardium solution provides a number of log files to assist in managing and troubleshooting operations. These log files include:

Table 1. Log files
Pzrameter name Description

guardiumEvents_audit.log

This an audit log of all changes made to Guardium based on QRadar events. Each line is a JSON object that includes identifiers, timestamp and details of the Event handled.

QRListener.log

Log output from the Listener process that receives forwarded event data from QRadar.

HANDLER_<event name>.log

Log output from the dedicated handler AL for a specific Event.

RESPONSE_<event name>.log

Log output from a custom response AL if this AL implements logging based on its AssemblyLine name. For example this can be done by setting the Log Appender File Path parameter to be computed using this Javascript:

return “logs/”

+ task.getShortName()

+ “.log”;