IBM QRadar Response Integration via API

Purpose

This guide explains how to connect IBM QRadar SIEM to Logsign as a Response integration, so an analyst (or an action rule triggered by a correlation) can search QRadar event data and close QRadar offenses directly from a Logsign Incident. This is a query/action integration, not a log collection poller: it does not pull QRadar logs or offenses into Logsign on a schedule. It only runs when something calls one of its methods from Settings > Integrations > Responses.

This is a different integration from two other things also named "QRadar" in Logsign, and it is important not to mix them up:

• "IBM - QRadar" (Data Collection / poller). Logsign already has a separate, existing integration under Settings > Data Collection that pulls QRadar offense/event data into Logsign on a schedule using an Authorized Service token. That is a log ingestion path. This guide's integration is the opposite direction: it lets an analyst working an Incident in Logsign reach out and query or act on a live QRadar deployment on demand. If you only want QRadar's own logs and offenses inside Logsign's event store, use the existing "IBM - QRadar" Data Collection documentation instead; this guide does not cover that.
• IBM QRadar EDR (formerly ReaQta / ReaQta-Hive). This is a completely different IBM product: an endpoint detection and response tool with its own "Hive Server" console, its own API ("Hive API" under /rqt-api), and its own separate Logsign integration and documentation ("IBM QRadar EDR Integration via API"). It has no relationship to QRadar SIEM's API, authentication, or the methods described in this guide. If you are integrating endpoint alerts from QRadar EDR, use that documentation instead.

This guide covers only the Response/Action integration: search_offense, close_offense, get_search_status, and get_search_result, configured under Settings > Integrations > Responses > +Device against your own QRadar Console's REST API.

Prerequisites

You need network reachability from your Logsign instance to your QRadar Console (or Event Collector/App Host configured to accept API calls) on its HTTPS management port, typically 443. You also need a QRadar Authorized Service token generated from a scoped, non-Admin user role; Step 1 below covers how to create one instead of reusing an existing Admin-level token.

QRadar SIEM is deployed on-premises or as QRadar on Cloud, and in both cases the Console address is specific to your own deployment; there is no shared multi-tenant API host. The Host field in Step 2 always points at your organization's own QRadar Console.

The exact minimum Logsign version that ships this integration was not confirmed against release notes for this guide. Release note history shows an "IBM - QRadar integration added" entry for Responses in a 6.3.x build and further updates in later 6.4.x releases, so any reasonably current Logsign 6.3+/6.4+ build should include it; confirm with Logsign support if you do not see IBM QRadar listed under Settings > Integrations > Responses.

Step 1: Create a least-privilege Authorized Service token in QRadar

Do not point this integration at an existing Admin-role Authorized Service token that is also used for other purposes. Create a dedicated token instead, scoped to only the capabilities this integration actually calls.

1. Sign in to the QRadar Console as a user with Admin access, and open Admin > Authorized Services.
2. Before creating the token, create a dedicated custom user role first (Admin > User Roles > add a new role, for example logsign-response-svc) rather than reusing the built-in Admin role. QRadar's Authorized Service token is issued against a user role and a security profile, and whatever permissions that role has become the token's permissions.

3. In the custom role, enable only the two capability groups this integration needs:

   • Offenses, specifically the ability to view and close offenses (QRadar's role editor exposes this as offense management permissions such as assigning/closing offenses and managing closing reasons). This is required for close_offense.
   • Log Activity (the Event Viewer capability group), which is required to run Ariel searches through the API. This is required for search_offense, get_search_status, and get_search_result, since all three operate against the /ariel/searches endpoints that back the Log Activity tab.

   Do not enable Admin, System Administrator, or other capability groups unrelated to these two; a broader role than this is not needed for the four methods this integration exposes.

4. Assign a Security Profile to the role that covers the networks, log sources, and domains whose offenses and events you want this integration to be able to search and close. A role with no security profile access will authenticate successfully but return empty results or fail to find offenses that exist.
5. Back in Admin > Authorized Services, click Add Authorized Service. Give it an identifiable name (for example, "Logsign Response Integration"), select the custom user role and security profile created above, and optionally set an expiration date for the token.
6. Click Create Service, then copy the generated Authentication Token immediately. QRadar shows this value only once; if you navigate away without copying it, you must regenerate a new token.

The exact wording of role capability checkboxes (for example, whether offense closing appears under a single "Offenses" group or is broken into finer sub-permissions) can vary slightly between QRadar versions; this guide's permission names are based on IBM's published user role documentation and were not confirmed against a live QRadar console for this guide. If the exact checkboxes described above are not present in your version, look for the closest equivalent under Offenses and Log Activity rather than falling back to Admin.

Step 2: Configure the integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for IBM QRadar, click Configure, then +Device.

Format warning: the Url field is a plain base address, not a URL with the API path baked in. Correct: https://qradar.yourcompany.com. Incorrect: https://qradar.yourcompany.com/api or a value ending in a trailing slash; the integration builds request paths by concatenating this value directly with /api/..., so an extra path segment or slash produces a broken URL.

This is the complete configuration form; the current manifest for this integration exposes only the fields above. (The integration's underlying configuration structure also defines an optional outbound proxy URL, but it is not present in the configuration schema/form, so it does not appear as a field here; this was not independently verified by testing the live form.)

Save the device. There is a registered test method in the integration (_test, exposed as a connection test in the manifest), but based on source-code review its current implementation does not actually call QRadar; it returns success without making a request. Do not rely on a green "test" result as proof the token or Url are correct. Verify instead by running search_offense against a known offense ID after saving.

Available Methods

Every method below is invoked from within an Incident's Responses panel by selecting the configured IBM QRadar device and the method name.

search_offense

Starts an asynchronous Ariel search for all events tied to a given offense ID, within a specified lookback window. This is typically the first call an analyst makes when pivoting from a triggered offense into its underlying event data. The query issued is an AQL expression of the form select * from events where INOFFENSE(offense_id) last since_hours hours, run against the POST /api/ariel/searches endpoint. Because the search is asynchronous, this call returns a search_id; use get_search_status and then get_search_result to retrieve the actual events.

get_search_status

Polls the status of a search created by search_offense (progress, record count, and completion status), calling GET /api/ariel/searches/{search_id}.

get_search_result

Retrieves the results of a completed search and summarizes them into deduplicated lists (usernames, source/destination IPs, source/destination ports, event counts, magnitudes) rather than the raw per-event array, calling GET /api/ariel/searches/{search_id}/results. Call this only after get_search_status reports the search as completed; QRadar's results endpoint can return partial or empty data for a search that is still running.

close_offense

Closes an open QRadar offense with a specified closing reason, calling POST /api/siem/offenses/{offense_id} with status=CLOSED.

Notes and Limits

• This is a query/action integration, not a log collector. It does not ingest QRadar offense or event data into Logsign's event store on its own; each method call returns data only for the specific request an analyst or action rule makes at that moment. For continuous ingestion of QRadar data into Logsign, use the separate "IBM - QRadar" Data Collection integration.
• The integration does not expose any reference set (IP/domain blocklist) methods. Based on a full review of the current source code (ibmqradar.go, ibmqradar_impl.go), the only four registered methods are search_offense, close_offense, get_search_status, and get_search_result; there is no add_reference_set_element, remove_reference_set_element, or equivalent, even though QRadar's own REST API supports reference set operations. If your use case depends on pushing an IP or domain into a QRadar reference set for blocklisting from Logsign, that capability does not currently exist in this integration and would need to be requested as a product enhancement.
• Authentication is a single static Authorized Service token sent as the SEC header on every request. There is no OAuth flow and no token refresh; if the token expires (if you set an expiration date in Step 1) or is revoked in QRadar, every call fails until you generate a new token in QRadar and update the device configuration in Logsign.
• The registered connection test (_test) does not call QRadar as of this source review; a successful test result is not proof of a working token or Url. Verify with a real search_offense call instead.
• QRadar's REST API is versioned via a Version request header (for example Version: 21.0). Based on source-code review, this integration does not set a Version header on its requests, so QRadar falls back to its own configured default API version. This is generally fine for the stable endpoints used here (/siem/offenses, /ariel/searches), but it means behavior could shift if IBM changes the default version's response shape in a future QRadar upgrade. Not confirmed against a live console for this guide.
• IBM's published QRadar API documentation does not describe a numeric rate limit or a 429 response for these endpoints; Ariel searches are, however, resource-intensive on the QRadar side, so avoid triggering large numbers of concurrent search_offense calls against a single Console.
• The TLS verification setting (Insecure Skip Verify) defaults to true, which skips certificate validation. This is a sensible default for a self-signed on-premises Console but is worth revisiting if your Console has a certificate from a CA your organization already trusts.

Troubleshooting