Introduction

Your IBM Guardium Exposure Manager instance is continuously flagging open data exposure issues workforce (endpoints) and workload (datasources, saas applications, ETL jobs, cloud workflows). Largely where data is being accessed by Agents or possibly being used in RAG pipelines which in turn feeds context to chat bots.

 
Your audit team needs a trail of every administrative action taken inside IBM Guardium Exposure Manager. Both of these data streams are available through IBM Guardium Exposure Manager’s REST API — but they don’t automatically land in QRadar, where your analysts live.

This is a gap many organisations encounter when they deploy IBM Guardium Exposure Manager alongside an existing QRadar SIEM. IBM Guardium Exposure Manager does not natively push events to QRadar, and building a custom integration from scratch typically means writing and maintaining a separate data pipeline. There is, however, a cleaner path: QRadar’s Universal Cloud REST API (UCC) protocol, a built-in capability that lets you define a REST-based log source entirely in XML — no middleware, no custom application server, nothing to patch.

This post walks through a set of open-source Universal Cloud Connectors that bridge IBM Guardium Exposure Manager and QRadar. They are available on GitHub at https://github.com/ncee-dp-tech-sme/gem_qradar_ucc and cover two IBM Guardium Exposure Manager data streams: security issues and the activity audit log. We’ll focus on the Combined connector — the recommended option for most deployments — but cover all three so you can choose the right fit for your environment.

Architecture Overview

Before diving into configuration steps, it helps to understand the moving parts.

IBM Guardium Exposure Manager is IBM’s SaaS-based data exposure management platform. It exposes two REST API surfaces relevant here:

• GET /api/v1/issues and GET /api/v1/issues/{id}/details — the security issues API, returning open exposure issues with enriched detail records including asset, policy, sensitivity category, and scope metadata.
• POST /api/v3/reports/run — the reports API, used to run the built-in Activity Log report that captures an audit trail of all user and system actions within GEM.

QRadar’s Universal Cloud REST API protocol allows a QRadar log source to be driven entirely by an XML workflow definition. The workflow specifies how to authenticate, how to paginate, which API endpoints to call, and how to post each record as a QRadar event. No external agent or middleware is required — QRadar itself executes the workflow on its managed host on a configurable schedule.

Log Source Extensions (LSX) are QRadar’s field-mapping layer. They parse the raw JSON payloads from the workflow into standard QRadar fields (such as UserName, EventName, StartTime) and into Custom Event Properties (CEPs) that capture GEM-specific fields like GEM Issue Name, GEM Asset Type, or GEM Activity ActionTaken.

The end-to-end data flow looks like this:

GEM SaaS REST API
        ↓
QRadar UCC Workflow (XML)  ←  WorkflowParameterValues.xml (credentials + config)
        ↓
QRadar Log Source
        ↓
Log Source Extension (LSX)  →  Standard fields + Custom Event Properties (CEPs)
        ↓
Log Activity / Rules / Offences

The Three Connectors

The repository provides three connectors. They share the same authentication mechanism and credential format but differ in what they collect and how they are packaged.

Connector 1 — Open Issues + Details

Runs on a configurable schedule (minimum once per day). Each run computes a 24-hour window covering the previous UTC calendar day, retrieves all open issues detected in that window via paginated calls to GET /api/v1/issues (20 issues per page), and then fetches the enriched detail record for each issue via GET /api/v1/issues/{id}/details. Each detail record is posted as an individual QRadar event.

Best suited for: Daily security issue tracking and offence creation.

Connector 2 — Activity Log

Runs on a configurable recurring schedule (default: every 10 minutes). Each run computes a rolling time window of [now − recurrence_minutes, now], queries the GEM Activity Log report via POST /api/v3/reports/run with pagination (500 records per page), and posts each activity record as an individual event.

The rolling window design guarantees contiguous, gap-free ingestion: as long as the workflow’s recurrence_minutes parameter matches the QRadar log source recurrence schedule, every activity record will be collected exactly once.

Best suited for: Near-real-time audit and compliance monitoring.

Connector 3 — Combined Issues + Activity Log (Recommended)

Combines both connectors into a single QRadar log source. One set of credentials, one recurrence schedule, one Log Source Extension. Each workflow execution runs the Issues section (Section A) followed by the Activity Log section (Section B) in sequence.

A single LSX with two <match-group> elements handles both event shapes. The two JSON structures are mutually exclusive — issue detail records always contain an issue_id field; activity log records always contain a numeric string key “1” (the CreationTimeUTC field). The groups are therefore guaranteed never to conflict.

For most deployments, the Combined connector is the right choice. The rest of this guide focuses on it.

Prerequisites and Authentication

Before you begin, confirm the following:

Authentication uses HTTP Basic Auth. The connector assembles the credential string api_key:api_secret at workflow runtime and base64-encodes it inline. No pre-encoded value is stored anywhere in the XML files. This means credential rotation is straightforward: update the two parameter values on the log source and redeploy — no file editing, no reloading the workflow definition.

Step-by-Step Installation

Step 1 — Download the Files

Clone or download the repository from https://github.com/ncee-dp-tech-sme/gem_qradar_ucc. The files for the Combined connector are in the GEM_QRadar_issue_activity_logs/ folder:

GEM_QRadar_issue_activity_logs/
├── GEM-Combined-Workflow.xml
├── GEM-Combined-WorkflowParameterValues.xml
└── GEM-Combined-LogSourceExtension.xml

Step 2 — Configure Parameter Values

Open GEM-Combined-WorkflowParameterValues.xml and fill in the required parameters before importing:

⚠ Important: recurrence_minutes must stay in sync with the Recurrence field configured on the QRadar log source. The workflow uses this value to calculate the Activity Log time window. If they diverge, records will be missed or duplicated.

Step 3 — Import the Workflow

1. In QRadar, navigate to Admin → Universal Cloud REST API Sources.
2. Click Add and select Workflow.
3. Upload GEM-Combined-Workflow.xml.

Step 4 — Create the Log Source

1. Navigate to Admin → Log Sources → Add.
2. Set Log Source Type to Universal Cloud REST API.
3. Set Protocol to Universal Cloud REST API.
4. Select the imported workflow.
5. Upload your filled-in GEM-Combined-WorkflowParameterValues.xml as the Workflow Parameter Values.
6. Set Recurrence to 10 minutes (or your chosen interval — update recurrence_minutes to match).
7. Save and deploy.

Step 5 — Import the Log Source Extension

1. Navigate to Admin → Log Source Extensions.
2. Click Add and upload GEM-Combined-LogSourceExtension.xml.
3. Enable it and associate it with the newly created log source.
4. Update the device-type-id: The LSX ships with a default device-type-id of 4015. After creating your log source, update the LSX to use your actual log source’s device type ID.

Step 6 — Create Custom Event Properties (CEPs)

Navigate to Admin → Custom Event Properties → Add and create the following properties. Alternatively, right-click an event in Log Activity → Extract Property once events are flowing.

Issue CEPs:

Activity Log CEPs:

Understanding the Data — Event Shapes and Field Mapping

The Combined connector produces two structurally distinct event types, and the LSX routes each through the correct match group automatically.

Issue events are identified by the presence of the issue_id field. The LSX maps the enriched issue detail payload to standard QRadar fields and the Issue CEPs listed above. The issue_id field maps to the standard QRadar field, and fields such as asset name, policy name, sensitivity category, and scope provide the rich context needed for rule-based offence creation.

Activity log events are identified by the presence of numeric string key “1” — the GEM API’s internal representation of the CreationTimeUTC column. The mapping is:

Because an issue detail object never contains a key “1”, and an activity results object never contains issue_id, the two match groups are guaranteed to be mutually exclusive.

Lessons Learned — Gotchas Worth Knowing

These issues were encountered and fixed during development. They are worth knowing upfront to save you the troubleshooting time.

1. Double-encoding of the date filter parameter (Connector 1, fixed in v1.2)
The date_filter query parameter sent to GET /api/v1/issues is a JSON string containing ISO timestamps. An early version of the workflow manually percent-encoded this string. QRadar then percent-encoded it again when constructing the HTTP request, producing a double-encoded URL that GEM rejected with an HTTP 500 error. The fix was to use plain XML-escaped JSON and let QRadar handle the URL encoding.

2. Scheme prefix in gem_host (Connector 2, fixed in v1.1)
The gem_host parameter for the Activity Log connector requires the hostname only — no https:// prefix, no trailing slash. Including the scheme caused a Client Protocol Exception in QRadar’s pre-flight connectivity test. The Combined connector documents this explicitly: gem_host is eu.guardium.security.ibm.com, not https://eu.guardium.security.ibm.com.

3. Recurrence minutes drift
After initial setup, it is easy to modify the QRadar log source’s Recurrence schedule without updating the recurrence_minutes workflow parameter — or vice versa. When these diverge, the Activity Log time window no longer aligns with the actual collection interval, leading to gaps or duplicate records. If you change one, change the other at the same time.

4. device-type-id in the LSX
The LSX XML ships with device-type-id=“4015” as a placeholder. Once the log source is created, QRadar assigns it a real device type ID. Update the LSX accordingly — otherwise event parsing may not work as expected.

Resources

• GitHub repository: https://github.com/ncee-dp-tech-sme/gem_qradar_ucc
• Documentation site: https://ncee-dp-tech-sme.github.io/gem_qradar_ucc/

The repository includes sample API responses in the examples/ folder and full XML schema references for the UCC workflow format in workflows/. Issues, feedback, and contributions are welcome via the GitHub issue tracker.